If you are dealing with a memory dump (unmanaged) a very fast way to get an initial look is to use DebugDiag Analysis. It will provide you a nice report and it might help you. Sometimes in DebugDiag reports you will see a rebuilt stack trace like the one below (COM+)
Thread 16 - System ID 2912
Entry point comsvcs!STAThread::STAThreadWorker
Create time 7/14/2008 5:22:49 AM
Time spent in user mode 0 Days 00:02:04.015
Time spent in kernel mode 0 Days 00:00:40.640
This thread is blocked by an unhandled exception which caused a COM+ FailFast to occur.
Function Source
NTDLL!NtWaitForSingleObject+b
NTDLL!RtlpWaitForCriticalSection+9e
NTDLL!RtlEnterCriticalSection+46
ADVAPI32!MapPredefinedHandle+39
ADVAPI32!RegOpenKeyExW+c5
ADVAPI32!RegOpenKeyW+73
comsvcs!FF_DumpProcess+3e
comsvcs!FailFast+40
comsvcs!ComSvcsExceptionFilter+9c
(…)
Recovered stack for thread 16
Function Arg 1 Arg 2 Arg 3 Source
NTDLL!RtlRaiseStatus+24 c0000024 00000360 77f87fdd
NTDLL!RtlpUnWaitCriticalSection+25 7c32d5a0 7c2f488e 7c32d5a0
NTDLL!RtlLeaveCriticalSection+1d 7c32d5a0 01fee8b4 80000000
ADVAPI32!MapPredefinedHandle+96 80000000 01fee888 091428e8
ADVAPI32!RegOpenKeyExW+c5 80000000 01fee8b4 00000000
oledb32!CError::CacheErrLookUpObject+99 01feec54 024d3098 027c2dd8
oledb32!CImpIErrorRecords::AddErrorRecord+cb 045da5b8 024d3070 10000000
sqloledb!CError::PostHResult+65 80040e21 027c2dc8 01feedd0
And you will see a recovered stack for this thread with a lot more useful information. Today I will show you how you can get this information using Windbg so that you could dig deep in this memory dump.
The first parameter in ComSvcsExceptionFilter it´s a pointer to EXCEPTION_POINTERS struct.
Below in yellow is the address of this first parameter
0:016> kb
ChildEBP RetAddr Args to Child
01fee0f8 77f8f295 000018f8 00000000 00000000 NTDLL!NtWaitForSingleObject+0xb
01fee16c 77f87f26 7c32d500 7c2f4854 7c32d5a0 NTDLL!RtlpWaitForCriticalSection+0x9e
01fee174 7c2f4854 7c32d5a0 78822ba0 80000002 NTDLL!RtlEnterCriticalSection+0x46
01fee188 7c2f4a4d 80000002 01fee1ac 01fee3fe ADVAPI32!MapPredefinedHandle+0x39
01fee1b0 7c2f4c36 80000002 78822ba0 00000000 ADVAPI32!RegOpenKeyExW+0xc5
01fee1c8 78822cc0 80000002 78822ba0 01fee1e4 ADVAPI32!RegOpenKeyW+0x73
01fee3fc 788231c6 7876041c 01feee40 00000000 comsvcs!FF_DumpProcess+0x3e
01fee400 7876041c 01feee40 00000000 78745548 comsvcs!FailFast+0x40
01fee410 7878f576 01fee440 7878f4c0 000ee008 comsvcs!ComSvcsExceptionFilter+0x9c
If you dump this address, the first two elements are pointers to EXCEPTION_RECORD and to CONTEXT
0:016> dc 01fee440
01fee440 01fee50c 01fee520
You can then use .exr and .cxr to dump respectively the exception and the context.
0:016> .cxr 01fee520
eax=01fee7ec ebx=00000000 ecx=01010101 edx=ffffffff esi=7c32d5a0 edi=00000000
eip=77fac57c esp=01fee7ec ebp=01fee83c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
NTDLL!RtlRaiseStatus+0x24:
77fac57c c9 leave
After switching to this context if you look at the stack you will see a more useful one and equal to the one that appears in DebugDiag. Then just keep digging until you find the root cause of your problem.
*** Stack trace for last set context - .thread/.cxr resets it
01fee83c 77f8f3a5 c0000024 00000360 77f87fdd NTDLL!RtlRaiseStatus+0x24
01fee848 77f87fdd 7c32d5a0 7c2f488e 7c32d5a0 NTDLL!RtlpUnWaitCriticalSection+0x25
01fee850 7c2f488e 7c32d5a0 01fee8b4 80000000 NTDLL!RtlLeaveCriticalSection+0x1d
01fee864 7c2f4a4d 80000000 01fee888 091428e8 ADVAPI32!MapPredefinedHandle+0x96
01fee88c 027544c0 80000000 01fee8b4 00000000 ADVAPI32!RegOpenKeyExW+0xc5
01feec3c 027545ec 01feec54 024d3098 027c2dd8 oledb32!CError::CacheErrLookUpObject+0x99
01feecd0 027c4a3b 045da5b8 024d3070 10000000 oledb32!CImpIErrorRecords::AddErrorRecord+0xcb
01feed14 027c4b44 80040e21 027c2dc8 01feedd0 sqloledb!CError::PostHResult+0x65
01feed64 02751c0f 026ef374 00000001 01feedb8 sqloledb!CImpIDBProperties::SetProperties+0x3e9
Bruno