ntdll.dll!_KiFastSystemCallRet@0()
ntdll.dll!_ZwWaitForSingleObject@12() + 0xc bytes
ntdll.dll!_RtlpWaitForCriticalSection@4() + 0x8c bytes
ntdll.dll!_RtlEnterCriticalSection@4() + 0x46 bytes
ntdll.dll!_RtlAcquirePebLock@0() + 0x28 bytes
ntdll.dll!_RtlDosPathNameToNtPathName_Ustr@16() + 0xa6 bytes
ntdll.dll!_RtlDosPathNameToNtPathName_U@16() + 0x49 bytes
kernel32.dll!_FindFirstFileExW@24() + 0x8b bytes
kernel32.dll!_FindFirstFileW@8() + 0x16 bytes
dbghelp.dll!CheckDirForPdbs() + 0xd9 bytes
dbghelp.dll!diaLocatePdb() + 0x3e2 bytes
dbghelp.dll!diaGetPdb() + 0x207 bytes
dbghelp.dll!GetDebugData() + 0x2be bytes
dbghelp.dll!modload() + 0x305 bytes
dbghelp.dll!LoadSymbols() + 0x9a bytes
dbghelp.dll!_SymGetLineFromAddrW64@20() + 0x102 bytes
It may not be deadlock, have you waited long enough? It may be loading PDB
files (where is your PDB store, are you getting them from internet or network
location, if yes, are they accessible?)
Jigar Mehta
Then it gets more complicated: the memory functions that dbghelp is using
were hooked back into my application which basically deadlocked on a
critical_section in my application....
Paul
Dbghelp functionality does not work in multithreaded applications unless
the calls to it are protected by critical sections or the like. You can
see this in the MSDN documentation.
.pat styles [microsoft]