Question

I’ve got a crash-dump file (my 32-bit windows application has crashed on a customer computer). Exception code is 0xE06D7363. So, I found this article from MSDN blogs about decoding the exception params. But a recipe from the article doesn’t work for me:

0:000> .exr -1 
ExceptionAddress: 753ad36f (KERNELBASE!RaiseException+0x00000058)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 19930520
   Parameter[1]: 0052ccd8
   Parameter[2]: 564099d8
0:000> dd 564099d8 l4
564099d8  00000000 00000000 00000000 564099d0
0:000> dd 564099d0 l2
564099d0  00000001 564099b4
0:000> dd 564099b4 l2
564099b4  00000001 56454aec
0:000> da 56454aec+8
56454af4  "????????????????????????????????"
56454b14  "????????????????????????????????"
56454b34  "????????????????????????????????"
56454b54  "????????????????????????????????"
56454b74  "????????????????????????????????"
56454b94  "????????????????????????????????"
56454bb4  "????????????????????????????????"
56454bd4  "????????????????????????????????"
56454bf4  "????????????????????????????????"
56454c14  "????????????????????????????????"
56454c34  "????????????????????????????????"
56454c54  "????????????????????????????????"

How can I make this method work? Or maybe there are other ways to analyze crash-dump with this exception?

Below is some info from !analyze -v:

PROCESS_NAME:  ArcMap.exe
MODULE_NAME: arcmap
FAULTING_MODULE: 76fa0000 ntdll
DEBUG_FLR_IMAGE_TIMESTAMP:  4e793643
ERROR_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_PARAMETER1:  19930520
EXCEPTION_PARAMETER2:  0052ccd8
EXCEPTION_PARAMETER3:  564099d8

Answer 1

There’re many technical details involved. I can give you the direction.

The 2nd exception parameter (0052ccd8) is a pointer to a _s__ThrowInfo structure, which describes the thrown type. The 3rd parameter (564099d8) is a pointer to the thrown object.

First let’s discuss the thrown object type. The _s__ThrowInfo points to a constant structure (generated at the compile-time), which resides within your executable (EXE or DLL), which is mapped into the process address space.

If the global memory is included in your crash dump – then you can find it there. Otherwise you may deduce it from the executable. Subtract the “base” address from your executable (assuming it was loaded at its preferred address), and you’ll get the offset of this structure within your executable.

Decoding the actual type from this structure is kind tricky. It includes the information about types it may be cast to (C++ polymorphism), plus the d’tor (destructor) in case it’s a non-trivial type (with non-trivial d’tor) and it was thrown by-value.
The table of types it may be cast to contain pointers to the appropriate structures describing those types. Among other things there are textual “encodings” of those types.

Information about layout of those structures may be found here:

Next, the thrown object. Its address usually belongs to the stack memory (strictly speaking this is not mandatory, one may throw either global or dynamically-allocated(on-heap) object. But this is usually not the case). If you have the stack included in your crash dump – you’ll see the object layout. Coupled with the type you’ll (hopefully) realize what it means.

If you don’t have the stack memory included in your crash dump – you’ll not be able to recover the object.

In addition your object may contain members that are pointer to other things (like strings or other objects) which may not necessarily be allocated on the stack. Most probably you’ll fail to realize those members, unless you have the full-memory dump.