Analyzing a crash dump file

Question

I have a crash dump file from a customer which I have to analyze. I am new to the world of crash dump analysis. (The source code is C++).

Here is what I have tried:-

• I opened the .dmp file with MS Visual Studio which indicated the following error - You cannot debug a 64-bit dump of a 32-bit process. So, I thought of giving WinDbg a try.

• When I opened the file in WinDbg after setting the symbol search path, I started the getting the following - Debuggee not connected.

Can anyone point me out in the right direction? Should I be asking the customer to provide a 32-bit dump from his point or can this dump file be debugged.

Also, provide the necessary documentation to get started.

Answer 1

To some extent, you can debug a 64-bit dump of a 32-bit process with Windbg, by use of the wow64exts. However if possible I think it’s best to have a 32 bits dump. If the customer can provide a 32-bit dump , get it.

Here is a sample of the wow64exts:

0:008> k
Child-SP          RetAddr           Call Site
00000000`0291f128 00000000`779d263a wow64cpu!CpupSyscallStub+0x2
00000000`0291f130 00000000`7792c4f6 wow64cpu!WaitForMultipleObjects32+0x1d
00000000`0291f1e0 00000000`7792b8f5 wow64!RunCpuSimulation+0xa
00000000`0291f230 000007fe`e51fd6af wow64!Wow64LdrpInitialize+0x435
00000000`0291f770 000007fe`e519c1ae ntdll!_LdrpInitialize+0xde
00000000`0291f7e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
0:008> .load wow64exts
0:008> !sw
Switched to 32bit mode
0:008:x86> k
ChildEBP RetAddr  
02a1f2dc 7783c752 ntdll_779e0000!NtWaitForMultipleObjects+0xc
02a1f460 75b956c0 KERNELBASE!WaitForMultipleObjectsEx+0x10b
02a1f4d4 75b9586a kernel32!WerpReportFaultInternal+0x1c4
02a1f4e8 75b67828 kernel32!WerpReportFault+0x6d
02a1f4f4 778c07c4 kernel32!BasepReportFault+0x19

Answer 2

The most useful tool for crash dump analysis is to load it into Windbg (File -> Open crash dump) and then use the

!analyze -v

command. This applies a number of heuristics to rewind slightly from the actual crash site to work out where the cause of the crash is likely to be, eg to where a null pointer dereference occurred. There's a good tutorial here. A really good site to bookmark is John Robbins' blog which has lots of great articles about Windbg.