Have any other mod developers been experiencing hung hl2.exe processes after closing their mods? I've got 3 completely different Source SDK Base 2007 mods on my machine and none of them seem to ever actually stop the hl2.exe process after closing the launcher. This happens in release and debug builds alike, including a vanilla 'Create a Mod' build with absolutely no changes to the code.
As far as I can tell, this appears to be rooted outside of the SDK code itself and somewhere in the Steam API. Since I was able to reproduce this in a debug build, I attached the VS debugger and checked the module list to see if any SDK code was still churning. No mod sdk code was in in memory on any running thread during the hang; client and server dlls shutdown and unloaded without issue. The debug output window gave a few hints as to where the problem might be. Once the mod shuts down and the launcher window closes, the last message in the output window is: The thread 'CIPCServer::Thread_MainLoop()' (0x1a00) has exited with code 0 (0x0), which of course expected during normal operation. However the main loop exit message is followed several seconds later by 8 repeats of "Thread "CNet Encrypt:0" (ID 3228) failed to shut down". So could "CNet Encrypt:0" be the hung thread? Keeping that question in mind, I opened the thread list in Visual Studio, found the "CNet Encrypt:0" thread and opened its call stack. It appears to be getting stuck in crashhandler.dll. The call stack is below: > ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes ntdll.dll!_NtWaitForSingleObject@12() + 0x15 bytes crashhandler.dll!6a779f78() [Frames below may be incorrect and/or missing, no symbols loaded for crashhandler.dll] crashhandler.dll!6a77c9a4() ntdll.dll!_NtQueryInformationThread@20() + 0x12 bytes kernel32.dll!@BaseThreadInitThunk@12() + 0x19 bytes Also noting the apparent (by its name) networking-related nature of this thread, I took a look at which IP ports the hl2.exe process was still bound to. The only one in the list of ports still open by hl2.exe was UDP 26901 (Steam master server?? can't find reliable documentation on it). So as far as I can tell it appears that the thread dealing with master server updates is crashing sometime during execution--presumably at shutdown. This ends up triggering a signal hook (maybe?) in crashhandler.dll to capture whatever is left on the stack and write it to a dump before it goes completely belly-up. But something inside the dump-writing process is waiting on a mutex or condition that never ends up getting released or triggered respectively? IE: thread deadlock? Can anybody else confirm/deny the reproducibility and possibly offer any other insight? I haven't yet confirmed if this occurs for other app id's. All three of the ones I tested are based on 218. Thanks, Cale
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
