Actium

I've recently stumbled over two instances of this issue occurring entirely out of the blue without any prior connection issues (i.e., no session check errors/warnings) in dcs.log [1, 2]. In both cases, the session simply expired within 15 minutes of starting the game.

No connection issues in the log. Master server just opted to terminate the session for no apparent reason: 2025-05-28 19:12:57.649 INFO ASYNCNET (4100): Login success. 2025-05-28 19:13:02.135 INFO ASYNCNET (4100): Got auth data. 2025-05-28 19:13:02.580 INFO ASYNCNET (Main): ProtocolVersion: 402 2025-05-28 19:13:02.580 INFO ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback" 2025-05-28 19:13:02.580 INFO ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast" 2025-05-28 19:24:59.022 ERROR ASYNCNET (4100): The session has expired (401). Exiting...

In a simple BVR scenario with a flight of 4 MiG-29 air-starting in a line abreast formation, the flight presumably attempts to switch to a grind formation. That typically results in some of the wingmen (usually trailing pair) stalling at 130 kts IAS and 21° AoA on full burn until they snap out of it minutes later when a plane finally gets hit. This is not limited to the Fulcrum, but also occurs with the Flanker. Starting with a trailing formation may result in fewer stalled planes. This has been previously reported for the F/A-18. I've attached a track and a tacview: AI_stall.trkAI_stall.acmi Screenshot of starting position: Screenshot of trailing element stalling after switching to grind:

Failure to resolve api.digitalcombatsimulator.com will be logged as ASYNCNET errors/warnings in dcs.log (likely sth. to the tune of error 6: Could not resolve hostname). If your dcs.log does not contain such messages, it's definitely not DNS.

@Roughneck Have you had a look at your dcs.log for sessions that got terminated? Here's a quick way to grep the relevant ASYNCNET messages from dcs.log via PowerShell: Get-Content "$env:USERPROFILE\Saved Games\DCS.openbeta\Logs\dcs.log" | Select-String ASYNCNET Wondering whether it includes any session check errors/warnings or the The session has expired (401). Exiting... message comes entirely out of the blue.

@Hempstead Thanks for sharing. I've had a look. These are all occurrences of ASYNCNET within the log file: 2025-07-03 18:48:27.090 INFO ASYNCNET (34508): Login success. 2025-07-03 18:48:29.799 INFO ASYNCNET (34508): Got auth data. 2025-07-03 18:48:29.854 INFO ASYNCNET (Main): ProtocolVersion: 404 2025-07-03 18:48:29.854 INFO ASYNCNET (Main): Adding LAN search interface 0: 127.0.0.1 "IPv4 Loopback" 2025-07-03 18:48:29.854 INFO ASYNCNET (Main): Adding LAN search interface 0: 255.255.255.255 "IPv4 Broadcast" 2025-07-03 19:00:30.957 ERROR ASYNCNET (34508): The session has expired (401). Exiting... So far, I've only observed and been able to reproduce this issue when the client reconnects to the master server after a 30ish minute connection interruption as I've reported here. That would result in many more ASYNCNET error/warning messages like this: 0000-00-00 00:00:00.000 ERROR ASYNCNET (192): HTTP request dcs:checksession failed with error 7: Could not connect to server 0000-00-00 00:00:00.000 WARNING ASYNCNET (192): Session check failed: -7 However, your occurrence of this issue appears to have happened entirely out of the blue without any prior connection issues. Presumably, the master server decided to just expire your session. Based on a previous post from BN, I've had a hunch that changing your IP address while logged in may cause the master server to terminate your session: I've tried to reproduce this, but changing my public IP address (have the router reconnect) twice for 3 consecutive session checks from 3 different IPs didn't trigger the issue for me. Unfortunately, the master server does not give any reason why it expires your session. Is there anything else on your side that could have caused it? It'd probably be best to open a support ticket, hoping that ED have a server-side master server log with more debug information.

There have been issues with memory leaks in the past. Not necessarily related, but probably worth a read:

@Simpit While you're in singleplayer, using the offline mode is a workaround for this issue. Would you mind sharing a dcs.log of the session to help figure out what caused the termination?

Would you mind sharing a dcs.log for that session? If it kicked you out within 10 minutes of starting the game, there must be more ways this issue is caused than I described here. I doubt you started a second DCS instance while busy bombing those T-72s.

Background updates, i.e., running DCS while its being updated, would be another great feature (being worked on, unfortunately, as part to the launcher). Preferably, it should enable already running part of the new version (base DCS + user-selected terrains) while the rest is being updated in the background. Obviously, that requires download speed limits to enable simultaneous multiplayer.

Mind sharing one or more dcs.log file(s) of the expired sessions? Unfortunately, the error popup message is identical for a couple of different causes. If it happened that early after starting the game, I wonder what exactly occurred.

Now that requires offline-mode or whacky workarounds. In your case, this was caused by an interruption in the connection to the master server (or more likely your entire internet connection went out for a while). Search for ASYNCNET errors/warnings in your dcs.log: Unfortunately, the DCS client will terminate itself after the connection to the master server had been lost for 30+ minutes, but only when ultimately reconnecting to the master server. This appears to be what happened here. Nothing support can do about it. This needs to be fixed in the game as I've explained here: @BIGNEWY I understand you're afraid of accounts being used simultaneously, however, the current attempt at preventing that is frustrating legitimate customers.

Not necessarily, at least not for 2.9.17. The release announcement was at 2025-06-19T15:03Z. Have a look at the details tab of the virustotal links. According to the DLL (PE) header, the files were compiled between 2025-06-16T06:55Z and 2025-06-18T13:06Z. According to the timestamp in autoupdate.cfg, the release was presumably packaged at 20250618-234919. That still leaves about a day to (automatically) upload the final release binaries to Virustotal, Microsoft, etc. so AV vendors can have a go at them. If all goes well, the release will not be delayed. Only if Virustotal returns significant false positives, I'd delay the update for a day or two, hoping the AV vendors will have sorted out the false positives by then.

Here's a way to monkey patch it into the existing Unit singleton: -- monkey patch method into Unit singleton (needed only once) function Unit:setLifePercent(life) net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, %f)", self:getID(), life) ) end -- usage example Unit.getByName("Naval-1-1"):setLifePercent(42)

Here's a way to monkey patch it into the existing Unit singleton: -- monkey patch method into Unit singleton (needed only once) function Unit:setLifePercent(life) net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, %f)", self:getID(), life) ) end -- usage example Unit.getByName("Naval-1-1"):setLifePercent(42)

Happy to help. I only stumbled over this yesterday, toying around with my Lua WebConsole. Here's a way to monkey patch it into the existing Unit singleton: -- monkey patch method into Unit singleton (needed only once) function Unit:setLifePercent(life) net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, %f)", self:getID(), life) ) end -- usage example Unit.getByName("Naval-1-1"):setLifePercent(42)

Fortunately, the required command is available within the mission editor/triggers Lua environment, so I've found a way to access it from the mission scripting Lua environment: net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, 42)", Unit.getByName("Aerial-1-1"):getID() ) )

This has been acknowledged as "not currently planned" by BIGNEWY: Fortunately, the required command is available within the mission editor/triggers Lua environment, so I've found a way to access it from the mission scripting Lua environment: net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, 42)", Unit.getByName("Aerial-1-1"):getID() ) )

Turns out this has been on the core wish list for almost a year [1, 2], acknowledged by BIGNEWY, but not planned as of March '25. As the required command is available within the mission editor/triggers Lua environment, I've found a way to access it from the mission scripting Lua environment: net.dostring_in("mission", string.format("a_unit_set_life_percentage(%d, 42)", Unit.getByName("Aerial-1-1"):getID() ) )

I do understand both sides of the argument. Hardcore DCS fans like yourselves certainly don't mind bypassing well-established security measures. However, more casual players may be easily scared off by that necessity. DCS does not have a large player base. Haphazardly scaring potentially new customers away with malware warnings appears potentially harmful from a business perspective. It is not quite that simple. With encrypted and/or obfuscated binaries, malware detection engines will have a hard time analyzing the trustworthiness of a previously unknown file. There's nothing the AV vendors can do without a sample of these suspect binaries. That would amount to fighting the symptoms and not the cause. ED are in a unique position to submit these files to AV vendors prior to release. Consider the files that initially got flagged by Microsoft Defender, but that now pass all major AV solutions: WorldGeneral.dll, Flight.dll, Scripting.dll, and edterrain4.dll. I'd assume (just spitballing) those AV programs first came into contact with the files after the release (at least as far as virustotal is concerned; check the details tab). Had these files been uploaded sooner, the false positives could possibly have been sorted out before affecting players. Virustotal shares the uploaded samples with AV vendors. Files can be uploaded for free and automatically through their API. That would imply minimal effort for ED for a chance to resolve this issue. IMHO, it's worth a shot. I also noticed that the DLLs are not code-signed. I develop software on Linux, not Windows, so I'm just spitballing again: Signing the DCS binaries with a Microsoft-issued certificate may improve the rating given by AV engines to these encrypted/obfuscated binaries. @BIGNEWY That could be another measure to suggest to your team to improve user-experience and avoid such unpleasant false positives or even suggesting to exclude DCS from malware scans altogether. It's not just about trusting ED. Supply chain attacks are a serious IT security concern.

Certainly. I'm not pushing either. Just wanted to a) report to those not privy to the ED-internal bug tracker or todo list that the bug is still present and b) express my displeasure about the forum post reporting said bug being closed, which, unfortunately, prevents distributing up-to-date information, e.g., that a workaround is feasible for those who might need it. I fail to see the logic behind immediately closing forum posts that report game bugs.

Unsurprisingly, this hasn't been fixed, so I had to re-introduce the workaround. If you need return values from mission scripting, update WebConsole.lua and modify Scripts/MissionScripting.lua as instructed here. Note that the modification will likely be undone when updating DCS.

The return value pass-thru is still broken as of DCS 2.9.17.11733. I'd have liked to report that in the separate post I created for that issue, but, unfortunately, it was closed.

DCS apparently also terminates itself when the master server experiences server-side errors (500+ status codes). I haven't seen that myself, but it's been reported here. I've updated the first post accordingly.

Assuming your development team relies on a CI/CD pipeline, it should be fairly straightforward to utilize the virustotal API to check for false positives automatically. Use of their public API should be free of charge for your use case (I'm a software developer, not a lawyer, so take my interpretation with a grain of salt). Postpone the release of an update if there are too many false positives.