Getting Started with WinDbg

Recently one of my applications started freezing up on our Production servers. It was impossible to figure out what was going on from the logs and reviewing the code seemed to only show that such behavior should be impossible. So I took a crash dump and used WinDbg to analyze. Turned out it seemed to be caused by one of the libraries our origen used and that was recently upgraded. Simple, right?

...Not quite, I skipped the part where it took me more than 2 days to figure out how to properly take the dump and get it running inside WinDbg.

So to save other people the trouble, here what you need to now and how to get started.

First, you'll need to get the program which comes in two versions, 32 and 64-bit. The one you need depends on the version of the program you are debugging, not the operating system it is on.

On a 64-bit Windows, you can tell this at by looking at the process in Task Manager. A 32-bit application with have *32 next to the process name in the Details tab.

The WinDbg installers though are part of the Windows SDK package which is downloadable on the Microsoft site.

However, the web installer wants to install the entire SDK but really you just need WinDbg. So...

http://www.microsoft.com/en-us/download/details.aspx?id=8442

You can download the ISO here and after mounting it, there should be a folder with the WinDbg installers, thus avoiding the need to install the SDK.

This is for the Windows 7 SDK but for other versions there should be something similar; just search around for it.

OK, so let's say you need to debug a 32-bit process running on 64-bit Windows 7. However, you will doing the analysis on another machine (running a different version of .NET).

So first, you need to take the process dump. To do this, I recommend you use SysInternal's Process Explorer (procexp.exe). If you Google it, you will easily find it (will put a link up eventually)

This avoids the issue of having to run the 32-bit version of Task Manager because it's too stupid figure the correct format of the dump file in the 64-bit program. ProcExp avoids the whole issue because it's smart :) Just right-click on the process and select Dump --> Full Dump

I've never tried mini dumps, but more is probably better.

No once you have this file, you need to copy it somehow to your debugging machine. Also you need to copy 2 files from the machine:

• SOS.dll
• mscordacwks.dll

Again, depending on the bit-ness of the application and the .NET version they are in either:

• C:\Windows\Microsoft.NET\Framework64\{version}
• C:\Windows\Microsoft.NET\Framework\{version}

Copy the correct files your machine.

Now start the version of WinDbg based on the application's bit-ness, in our case 32-bit.

Then, drag the dump file into the program. This will load it.

Now configure the Symbols Path using File->Symbols Path, and enter:

SRV*{local path}*http://msdl.microsoft.com/download/symbols

The {local path} should be a folder; it does not have to exist.

Now you need to load the process PC's .NET environment, specifically the two DLL files.

Execute .load {full path to file} to load the two DLLs.

Then type !analyze which will begin analyzing the dump.

If you get an error saying something like the CLR version does not match, most likely it is because it automatically loaded this machine's environment which overrides the custom set ones.

If you run .chain it should show the first entry as something related to .NET. Also make sure the two DLLs you loaded are under it.

Type .unload to remove the entry and analyze again. This should not have any issues now.

And now you're all set up!

Here's a few cheat sheets to get you started:

http://windbg.info/doc/1-common-cmds.html

http://theartofdev.com/windbg-cheat-sheet/

Also here's the link to the SOSEX extension which adds some pretty useful features, in my opinion.

http://www.stevestechspot.com/

You can load it in a similar manner as the other DLLs.

Pictures to come at a later date... or never.