1
votes

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.

2
You don't actively "run" a dmp file. You analyze it. And though VS is pretty, WinDbg has some pretty amazing actions at your disposal if you take the time to learn them (and can put up with their continually-dreadful ui). Also, you can switch the effective machine architecture in the 64bit WinDbg to analyze 32bit dumps if needed (though it sounds like it isn't). – WhozCraig
Can you provide me some workaround for the errors I have mentioned? – Sankalp
Can you describe exactly which commands you are issuing in Windbg? – the_mandrill

2 Answers

2
votes

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
2
votes

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.