Take control over Windbg

If you're like me and most of my colleagues in Customer Service and Support, you'll probably spend a good deal of time in your debugger, which for me is WinDbg. So, since I'm in love with keyboard shortcuts (a colleague of mine likes kidding me stealing my mouse since I hardly use it, and every now and then uses me as his personal "shortcut reference" smile_regular) and always searching for "productivity tips" to optimize my workflow. Windbg has a few of them, here is what I use.

Automate WinDbg startup

I first discovered this in this post from Tess and then customized it to match my needs, especially on my Vista x64 machine; basically this is a .reg file set WinDbg as the default application for .dmp files, and adds a few entries to the right click menu to chose different options. I also have to say that on my x64 machine I actually have two separate folders for WinDbg 32bit and 64bit, so that depending on the dump I'm debugging I can use the right tool:

Windows Registry Editor Version 5.00

@="c:\\debuggers x86\\cdb.exe"
@="Debug This Dump for .NET 1.1 x86"
@="\"C:\\debuggers x86\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x86\\commands_1.txt\""

@="c:\\debuggers x86\\cdb.exe"
@="Debug This Dump for .NET 2.0 x86"
@="\"C:\\debuggers x86\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x86\\commands_2.txt\""

@="c:\\debuggers x64\\cdb.exe"
@="Debug This Dump for .NET 2.0 x64"
@="\"C:\\debuggers x64\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x64\\commands_2.txt\""

right click menu 

With every "block" we are associating the .dmp extension to the cdb.exe icon, creating a description to add a new command to the right click menu and linking it to Windbg. Note that we're using some command line switches to tell Windbg which is the file to open (-z) and a script file to execute at startup (-c).

This script file is actually just a text file with some commands you would normally run at the beginning of your debugging session; for instance I use it to set my symbol path, load some Windbg extensions I use quite often, and open a log file to have the debugger output automatically saved for later reference, just in case I need to quickly find some information without having to reopen Windbg and go through the various commands:

.sympath SRV*c:\symbols*\\internalshare\symbols*http://msdl.microsoft.com/download/symbols
.load extension1
.load extension2
.load extension3
.logopen /d /t

The /d switch causes the log file name to be chosen based on the target process along with its state, while the /t switch appends the process ID with the current date and time (so if I open multiple times the same dump I have a record for all of my debugging sessions). By the way, you can use the .chain command to list all loaded debugger extensions and their search order, i.e. if you type a command which is contained in more that one extension, the one executed is the one contained in the most recently loaded extension.

Help online

If you need help about a particular extension, you can type !<extensionname>.help and a list of all available commands for that extension will be printed in the output window, while if you need help on a specific command you can use !<extensionname>.help <commandname>:

0:000> !sos.help dumpobj
!DumpObj [-v] [-short] [-r 2] <object address>

This command allows you to examine the fields of an object, as well as learn 
important properties of the object such as the EEClass, the MethodTable, and 
the size.

Typing commands

As I said, I really hate when I have to continuously move my hand from the keyboard to the mouse (maybe for just one click) and vice-versa, so I'm always looking for keyboard shortcuts; so within Windbg I like a couple of small details: if you have some text selected within the command output, a simple right-click will copy it into the clipboard and another right-click will paste it to the command textbox. As an alternative, if you have the mouse cursor within the command output (say after you selected a memory address) you can start typing right away without bothering clicking into the command textbox, because the cursor will automatically move there without losing a letter of what you are typing smile_regular. Small thing I know, but that's how it always begin; very small (from "Big trouble in little China" smile_wink).

Create or connect to a remote debug session

Sometimes could happen that you need assistance analyzing a dump (or someone asks your help), but what if you're in a team like mine spread across all over Europe and having a colleague walk down to your desk is simply not an option? Luckily Windbg allows to share your debugging session using the .server command: .server tcp:port=<portnumber> for instance if run on your Windbg (the one with the dump you want to share) will create a server session using TCP as the communication protocol, on port <portnumber>; the string highlighted in red below is the connection string you can send to your peer.

0:000> .server tcp:port=1234
Server started.  Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=1234,Server=<computername>

Now, on the "client" Windbg you can go to File > Connect to remote session (or hit CTRL+R) and either browse the network to find the Windbg server you're looking for, or type tcp:port=<portnumber>,server=<machinename> and your remote colleague and you will see the same command output and will be able to run commands on the shared dump smile_nerd

connect to remote debugging session

While connected you can use the .clients command to list of clients connected to the server, and the .echo command to send messages from one Windbg to the other(s).

Increase output readability

Going through a long list of commands and outputs in the debugger window may be not that easy, so it's possible to customize the font and text colors through Edit > Options...

windbg workspace options



Quote of the day:

If life is a waste of time, and time is a waste of life, why don't we all get wasted and have the time of our lives?


Comments (4)

  1. Jigar Mehta says:

    Once again awesome article.. Keep them coming..

    I had been using "Debug Profile Manager"

  2. This error message was reported by a customer last week; every day, randomly, his application pools (on

  3. I’ve just finished writing up an e-mail for some new people in my team about starting Debugging and the

Skip to main content