Using Visual Studio 2005, the debugger tells me that a deadlock has occurred just after startup of the app I’m writing – I’m well in to WinMain() at this point. The callstack shows that we are in a critical section, while calling AFX_MANAGE_STATE2 (for the 666th time, spookily enough) from within an MFC DLL. This has just started happening: the code worked fine yesterday. Weirdly, rolling back the code, rebooting the PC and rebuilding still yields the deadlock.
When everything grinds to a halt, I hit pause on the debugger and this message (eventually) appears:
Microsoft Visual Studio
The process appears to be deadlocked (or is not running any user-mode code). All threads have been stopped.
OK
The call stack looks like this:
ntdll.dll!_KiFastSystemCallRet@0()
ntdll.dll!_ZwWaitForSingleObject@12() + 0xc bytes
ntdll.dll!_RtlpWaitForCriticalSection@4() + 0x8c bytes
ntdll.dll!_RtlEnterCriticalSection@4() + 0x46 bytes
mfc80ud.dll!CThreadSlotData::GetThreadValue(int nSlot=1) Line 247 C++
mfc80ud.dll!CThreadLocalObject::GetData(CNoTrackObject * (void)* pfnCreateObject=0x7832e030) Line 419 + 0x11 bytes C++
mfc80ud.dll!CThreadLocal<_AFX_THREAD_STATE>::GetData() Line 177 + 0xd bytes C++
mfc80ud.dll!AFX_MAINTAIN_STATE2::AFX_MAINTAIN_STATE2(AFX_MODULE_STATE * pNewState=0x029a80d8) Line 57 + 0xa bytes C++
EmpireConsole.UnityDebug.dll!WIN_CON::SPOOL::BUFFER::overflow(unsigned short c=65) Line 979 + 0x13 bytes C++
Empire.UnityDebug.exe!UTILITYLIB::UniCharStreamBuf::sputc(CA::UniChar ch={...}) Line 113 + 0x68 bytes C++
Empire.UnityDebug.exe!UTILITYLIB::operator<<(UTILITYLIB::UniCharOStream & ucos={...}, const char * val=0x0888019c) Line 868 + 0x2f bytes C++
Empire.UnityDebug.exe!EMPIRE::ENVIRONMENT::auto_analyse() Line 319 + 0x2b bytes C++
Empire.UnityDebug.exe!EMPIRE::EMPIRE_APP_MODULE::run_vars(CA::UniString CmdLine={UniString [...] ...) Line 2531 C++
Empire.UnityDebug.exe!`anonymous namespace'::winmain_inner(HINSTANCE__ * hInstance=0x08440000, HINSTANCE__ * __formal=0x00000000, wchar_t * lpCmdLine=0x00020a92) Line 1981 C++
Empire.UnityDebug.exe!wWinMain(HINSTANCE__ * hInstance=0x08440000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020a92, int __formal=1) Line 4808 + 0x11 bytes C++
Empire.UnityDebug.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C
Empire.UnityDebug.exe!wWinMainCRTStartup() Line 414 C
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
The threads tab looks like this:
1008|wWinMainCRTStartup|CThreadSlotData::GetThreadValue|Normal|0
Occasionally, this also appears in the thread tab:
1596|_MixerCallbackThread@4|_KiFastSystemCallRet@0|Time Critical|0
but in general, only one thread is active.
I discovered that another member of my team had called TerminateThread rather than CloseHandle in a function a few instructions earlier. Fixing that fixed the problem. I shall look in to WINDBG though. Thread problems do crop up now that we’re living in a multi-core world.