Actium

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.

The error numbers are HTTP status codes. Error 502 (Bad Gateway) is a server-side error that indicates an issue within ED's network and should be entirely unrelated to your client or your internet connection. I have the launcher disabled and can still trigger the issue. The error is unrelated to the launcher. It also affects the dedicated server, which doesn't include the launcher. ED are aware. The issue has been reported to the devs, but so far hasn't been addressed.

This will definitely happen if your computer is properly suspended for at least 30 minutes, because the DCS client process will not be executing and thus unable to communicate with the DCS master server, which causes the master server to forget its session id. For details, see here (same thread as I posted above). Windows may however decide to do some suspension voodoo that'll cause periodic process execution, e.g., thru Connected Standby. Just hypothesizing. For me, a 30+ minute suspension always results in an expired session termination.

That's a bit like blaming the road if your car's engine stops every time you hit a pot hole. Not an ideal situation, but a proper car should be able to deal with it. The DCS client and master server should simply be more resilient to less than ideal internet connections. Even if a session check with the master server fails, the client should try to reauthenticate Instead of just terminating. That should be a relatively straightforward change that'll make a lot of paying customers less frustrated. I've litigated the issue in detail here (first post updated since you reported it to the team):

I've reported this issue in February. It's been wishlisted. Easy workaround would be to enter offline mode before starting the mission. If you forgot to do that, there's another use at your own risk workaround: Before suspending your computer, add a firewall rule or invalid network route that prevents further communication with the DCS master server. While this sounds counterintuitive, DCS will only terminate itself after it reconnects to the master server. It will happily live on without the master server, at least for a couple of hours. Haven't tried that overnight, yet. Update: Tested with the dedicated server, which runs for more than 3 days after losing connection to the master server. I'd assume the client will also.

This issue appears to have been bothering quite a few people, lately (1, 2, 3, 4). I've rewritten the OP with additional information and a workaround. I do hope ED will find the time to fix this.

Thanks. Glad to know this is of use to others. install_dcs.sh has been setting Windows 10 as the Windows version via wine winecfg -v win10 since the initial commit. I guess DCS is just getting a bit confused by your Wine version/installation. Curiously, I'm unable to reproduce the warnings. Line 5 of my server dcs.log correctly identifies the Windows version: 2025-06-12 15:20:31.344 INFO APP (Main): DCS/2.9.16.10523 (x86_64; MT; Windows NT 10.0.18362) Just ran install_dcs.sh on an empty WINEPREFIX (.wine directory). Couldn't reproduce your error, either. This is my output (full log install_dcs.sh.log) : ... + export WAYLAND_DISPLAY=wayland-1 + wine winecfg -v win10 0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0050:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0050:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0050:err:ole:start_rpcss Failed to open RpcSs service 0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002 wine: configuration in L"/home/dcs/.winetest" has been updated. + cat + wine reg import /home/dcs/.winetest/drive_c/wineconfig.reg + rm /home/dcs/.winetest/drive_c/wineconfig.reg ... Did you follow the installation instructions? Anything else relevant to reproducing your error? Your error message wine: could not load kernel32.dll, status c0000135 sounds like sth. is wrong with the wine prefix/installation.