Why is my MFC DLL deadlocking on a single thread near startup?

Question

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.

Answer 1

You'll want to put Visual Studio's integrated debugger aside for this one and use windbg, which knows about wait objects and has commands for finding out what object is being waited on and (for mutexes and critical sections) what thread currently owns the object.

Some additional resources can be found here:

http://www.debuginfo.com/articles/easywindbg.html#debugdeadlocks

http://blogs.msdn.com/greggm/archive/2004/02/05/68232.aspx

http://msdn.microsoft.com/en-us/magazine/cc164040.aspx

http://dalelane.co.uk/blog/?p=19

Answer 2

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.