Lately, I have been doing a fair amount of debugging, and helped other people set up their debuggers.
It can be very painful to make this work. To assist up and coming debuggers, I put my notes together in this blog. Here is how to get things going.
Downloading and Installing the Tools
First, you need the full tool package. Fortunately, all you need is now packaged in the Windows SDK to ease the pain:
- Download and install Windows SDK for .NET 4.0 from here: http://msdn.microsoft.com/en-us/windows/hardware/gg463009/.
Do the full install of all packages. They will take several GB. Please make sure you have a large drive (more than 100GB of space), you will need it.
This is the tricky part. In order to debug properly, you need symbols. Getting those set up requires a few tricks.
First, create directories to hold symbols and symbol caches. It is generally a good idea to stick to the naming convention that Microsoft uses in their examples:
- Create C:Symbols
- Create C:SymCache
- The next step is to configure symbol environment variables. While you CAN debug without them, setting them up is really worth the effort. First, locate you environment variables in
My Computer –> Properties –> Advanced System Settings –> Advanced
- (why is all the good stuff always located in “Advanced”?). Here you will find:
- You need to set up two environment variables. I prefer to set them as system variables, since I am the only one using my machine.
Assuming you use the directories above, set your symbol paths like this:
- Note that the paths are separated with stars, not semi-colon.
Main tools overview
There are some key command line tools that you will need to get familiar with:
- SqlDumper.exe – Used to generate dumps and minidumps. There are other tools that do the same, but I prefer this one. The usage is described here: KB 917825
- WinDbg.exe – A lightweight debugger for analysing dumps. Leaves a lot to be desired in usability, but it is really fast once you memorise the arcane commands required.
- SymChk – Used to check if symbols can be resolved. Gives verbose information with the /v command line, which is useful to validate symbol paths. See: SymChk Command-Line Options.
- SymStore.exe – Allows you to create your own symbol stores (under C:symbols for example). This is useful if you are debugging your own code or code which has symbols that dont originate from Microsoft. See: SymStore Command-Line Options.
- xperf.exe – The mother of all code profilers. This tool comes with an enormous amount of command line parameters. It would require an entire blog entry just to list my favourites (Hint: I may do one). Documentation is hard to come by, but here is a good intro: All Your Base are Belong to Us – Xperf.
- xperfview.exe – Used to view the traces generated by xperf
WinDbg Cheat Sheet
There are some commands that I use frequently in WinDbg. I would recommend you minidump a process you know while it is working in a test system (sqlservr.exe for example) and try them out. It is really quite amazing what you can see.
|!uniqstack||Shows all unique stacks. This is generally the first command I run to get an overview of the dump|
|∼||Show threads in the dump|
|∼<thread>s||Switch to <thread>. Useful for digging into the thread stack and data structures|
|k||Shows the thread stack. You can use ∼*kn to show all thread stacks|
|d<x>||There are different version of this command. But all are used to dig into data types that reside in a memory address or address range.|
|.frame <x>||Look at a stack frame|
|.reload||Retries symbol loading. Useful if you locate a missing symbol and want to see if it matches the dump|
|.cls||Clears the screen (which tends to get crowded)|