Amerio.Stephane Posted October 17, 2025 Posted October 17, 2025 Hello, We've had this issue for awhile and now is the time to tackle it! Our 2.20 app is compiled with VS2022 on Win11, and almost every time when we close the app, the windows console gets stuck. There is no visible crash (nothing in the system event log neither), no error messages, the app.exe is not visible in the process explorer, but there is just a conhost.exe lingering there, that may never close or might close after some indeterminate times. This does not happen in debug builds, only in release builds. There is no visible side effects for a while, but in simulation stop-restart heavy situation, there is a bunch of conhost.exe and visible console that would accumulate on screen. Closing them manually is not always a viable option. And their accumulation sometimes leads to the PC itself hanging. Of course, as the app.exe process is no longer running, there is no way to attach a debugger. So my first guess is just that the conhost.exe created by the OS didn't get the 'message' that the app was closed. As a workaround, would it be possible to launch our app without this console (susbsytem windows)? How would you change the main.cpp to do that? Do you think it could solve the problem or is there something worse lurking beneath? Thanks!
silent Posted October 17, 2025 Posted October 17, 2025 Hi Stephane, Adding /ENTRY:"wmainCRTStartup" /SUBSYSTEM:WINDOWS linker options should do the trick with the release builds. Other than that we don't know any reliable way to hide the cmd window that left after the Visual Studio starts the process. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN
Amerio.Stephane Posted October 17, 2025 Author Posted October 17, 2025 Hi, indeed using subsytem:windows prevents the creation of the console, and so it 'hides' the console issue. But I think I found the culprit: Nvidia DLSS updater nvngx_update.exe. The apparition of this issue actually coincide with us trying DLSS in 2.19. Note that the issue is present even if DLSS is not used, but some of the its DLLs are loaded. The engine is creating a bunch of attached processes nvngx_update.exe, and on engine exit, they are not correctly closed, so they end up detached from the console process and they all just linger there for some indeterminate time (sometimes a few seconds, or hours or days!) I just check a PC here with more than 50 of them. To track them, I used sysinternals process explorer. During runtime: the nvngx are below the app (EVA) and below the conhost.exe When the app is closed: the conhost has no children left, the nvngx are detached and will never signal the conhost to close. In our specific case, these process are totally useless because the PCs are not connected to the internet. While it looks like a non-issue as they don't really consume any apparent ressource, the real problem is they WILL accumulate and clog the PC (to the point I have to physically unplug it sometimes). 1
silent Posted October 17, 2025 Posted October 17, 2025 This issue unfortunately out of our control: https://forums.developer.nvidia.com/t/how-to-disable-nvngx-update-exe-during-automated-test/312497 We hope that nVidia will fix it's drivers eventually :) How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN
Amerio.Stephane Posted October 20, 2025 Author Posted October 20, 2025 Indeed, and it looks like we are not alone with issues related to nvngx_update. To be noted, this issue arise only because nvngx_update can't actually do the update because we're not connected to the internet, and it keeps trying indefinitely. Anyway, as a workaround, I now just kill any lingering nvngx_update.exe after engine->main() returns. Thanks! 1
silent Posted December 17, 2025 Posted December 17, 2025 We also found a way to disalbe force OTA updates on DLSS init (they were enabled by default). Hope that it would prevent this process to spam. Changes are merged in the upcoming 2.21 update branch. 1 How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN
Recommended Posts