Should !pe work from either an .mdmp or .hdmp dump file (from WER)
(too old to reply)
Omar Shafie
2010-06-14 09:46:09 UTC
Is a full dump required to get any useful CLR information from a dump?

Or is an .mdmp / .hdmp just an inferior type of minidump file?

From a queued Windows Error Reporting (WER) dialog (on Windows 2003), I have
collected a .mdmp (w/o heap) and .hdmp (w/ heap) dump file from a C++ / CLI
(.NET 2.0) application that is throwing a CLR exception.

I am trying to determine what the CLR exception is, and neither the .mdmp or
.hdmp seems to have enough information to do !pe (or !threads or !dumpstack
-EE / !clrstack).

For every thread in the process (including the thread raising the
exception), !pe reports the following:

The current thread is unmanaged

Similarly, if I do !clrstack, I get the following (again, for every thread
in the process):

Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process

If I do !threads, I get the following:

Failed to request ThreadStore

According to the SOS faq (!help faq), these minimal commands seem like
they're supposed to work from a partial dump:

I have a partial memory minidump, and !DumpObj doesn't work. Why?
In order to run SOS commands, many CLR data structures need to be traversed.
When creating a minidump without full memory, special functions are called at
dump creation time to bring those structures into the minidump, and allow a
minimum set of SOS debugging commands to work. At this time, those commands
that can provide full or partial output are:


For a minidump created with this minimal set of functionality in mind, you
will get an error message when running any other commands. A full memory dump
(obtained with ".dump /ma <filename>" in the Windows Debugger) is often the
best way to debug a managed program at this level.

The only commands that seem to work reliably are help and EEversion, but
neither of those can help me get the information I am looking for.

Some additional info:

0:015> .exr -1
ExceptionAddress: 77e4bee7 (kernel32!RaiseException+0x00000053)
ExceptionCode: e0434f4d (CLR exception)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 80131577

(Frame 11 -- piaflink!SetupAFAccess -- makes calls into managed code)

0:015> kvn40
# ChildEBP RetAddr Args to Child
00 0479a00c 7c827d0b 77e61d1e 00002550 00000000 ntdll!KiFastSystemCallRet
(FPO: [0,0,0])
01 0479a010 77e61d1e 00002550 00000000 0479a054
ntdll!NtWaitForSingleObject+0xc (FPO: [3,0,0])
02 0479a080 77e61c8d 00002550 0001d4c0 00000000
kernel32!WaitForSingleObjectEx+0xac (FPO: [SEH])
03 0479a094 6951163f 00002550 0001d4c0 0479c144
kernel32!WaitForSingleObject+0x12 (FPO: [2,0,0])
04 0479a0fc 69506136 0479e144 0479c144 00000092
faultrep!MyCallNamedPipe+0x15b (FPO: [SEH])
05 0479e558 69508b5c 0479f628 0479f180 00000001
faultrep!StartManifestReport+0x1d5 (FPO: [4,4362,4])
06 0479f3a4 77e7650f 0479f628 00000001 00000000 faultrep!ReportFault+0x3d2
(FPO: [SEH])
07 0479f600 77e792a3 0479f628 77e61ac1 0479f630
kernel32!UnhandledExceptionFilter+0x494 (FPO: [SEH])
08 0479f608 77e61ac1 0479f630 00000000 0479f630
kernel32!BaseThreadStart+0x4a (FPO: [SEH])
09 0479f630 7c828752 0479f9ec 0479ffdc 0479f70c
kernel32!_except_handler3+0x61 (FPO: [Uses EBP] [3,0,7])
0a 0479f654 7c828723 0479f9ec 0479ffdc 0479f70c ntdll!ExecuteHandler2+0x26
0b 0479f6fc 7c82863c 04799000 0479f70c 00010007 ntdll!ExecuteHandler+0x24
0c 0479f9dc 77e4bee7 0479f9ec 0479fa74 e0434f4d ntdll!RtlRaiseException+0x3d
0d 0479fa3c 79eda91c e0434f4d 00000001 00000001 kernel32!RaiseException+0x53
(FPO: [4,20,4])
0e 0479fa9c 79fb4868 018ff708 00000000 00000000
mscorwks!RaiseTheExceptionInternalOnly+0x2a8 (FPO: [SEH])
0f 0479fb60 060d2963 018ff630 018ff6e8 01507298 mscorwks!JIT_Throw+0xfc
(FPO: [0,40,4])
WARNING: Frame IP not in any known module. Following frames may be wrong.
10 0479fbe8 00408aa8 00000000 00000003 0479fc1c 0x60d2963
11 0479fd74 00418d5b 0479fda0 7ea550f8 01162c70 piaflink!SetupAFAccess+0x678
(FPO: [Non-Fpo]) (CONV: cdecl)
12 0479fe90 0040fa78 0479fec0 7ea553dc 00000001
piaflink!AssetSyncHelper::PeriodicTasks+0x3db (FPO: [1,64,4]) (CONV: thiscall)
13 0479ff28 004749b1 7ea55248 00000000 00000000
piaflink!AFLinkThreadPool::GetTask+0x188 (FPO: [0,31,4]) (CONV: thiscall)
14 0479ff74 78543433 01151228 786d1724 00000000 piaflink!fnThread+0xe1 (FPO:
[1,13,4]) (CONV: stdcall)
15 0479ffac 785434c7 00000000 0479ffec 77e64829
16 0479ffb8 77e64829 010c1790 00000000 00000000 msvcr90!_threadstartex+0x69
17 0479ffec 00000000 7854345e 010c1790 00000000
kernel32!BaseThreadStart+0x34 (FPO: [SEH])
2011-11-04 21:31:27 UTC
I'm running into the same issue and wondering if anyone has any suggestions? Does anyone know how to derive the managed call stack based on the native call stack and parameters (kb)? I have a feeling that .hdmp files don't contain the managed metadata to make this work. If I have an IP that i believe to be from a managed method, !ip2md does not work properly.

Any help would be appreciated.

Jeffrey LeCours