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
[Frames below may be incorrect and/or missing, no symbols loaded for
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.