Debugging a process dump with WinDbg, the very basics...
I had an issue this week where a client couldn't open our software because of a Native Heap corruption. I had a rough idea that a heap corruption must come from a non-.Net library as .Net has a managed heap with its own garbage collector. Surely enough our software has a C++ assembly within it.
Getting the process Dump file
I followed Tess Ferrandez's blog which has brilliant windbg tutorials. I realised that I had to retrieve the dump from the customer, which can be annoying if they're running a 32bit process on a 64bit machine and I need the 32-bit DMP file. This means you can't use process manager and just right click on the process. You have to use procdump from sysinternals.
procdump -ma "your32bitprocess.exe”
This will get a 32-bit dump by default, but you can also specify a 64 bit process dump with procdump.
Once you're in WinDbg (Windows Debug), you need to firstly open the .DMP file by choosing "Open crash dump" in the file menu.
Load in your symbols (if you haven't done so already):
.sympath+ SRV*c:\Symbols*http://referencesource.microsoft.com/symbols
Also if you have the Program Databases (.PDBs) from your own .dlls then you can add paths to them to retrieve useful function information, not just binary offsets.
I used the following selection of commands to leverage some really useful information, however the full suite of commands can be found here.
- !analyze -v
- Best command for getting an overview of issues that occurred at the moment you snapshotted the memory, windbg attempts to utillise many of its commands to string together a "What just happened" overview for you.
- !clrstack
- .Net (CLR compiler) stack trace
- kb 2000
- Full stack trace, including native, the number indicates the frames, this can be varied.
- !heap
- What is allocated to the heap
- In my specific scenario, it returned in massive letters "Heap Corruption", which I kind of knew already. But it did confirm.
- !pe
- Print exception, you can add the exception object reference id to the syntax to get a specific exception, otherwise it is just the most recent one.
Great Debugging References:
- WinDbg Glossary of Terms.
- Code Project on Debugging
- Tess Ferrandez's Blog - Top Microsoft Debugging Expert!
- Scott Hanselman interviews Tess Ferrandez on debugging in VS2010
- Full Hanselminutes interview with Tess Ferrandez
I'll try write up some more on debbuging stuff, as and when I learn more.