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” ?) 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 [HKEY_CLASSES_ROOT\.dmp] @="Debugger.Dump" [HKEY_CLASSES_ROOT\Debugger.Dump\DefaultIcon] @="c:\\debuggers x86\\cdb.exe" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_1_1_x86] @="Debug This Dump for .NET 1.1 x86" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_1_1_x86\Command] @="\"C:\\debuggers x86\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x86\\commands_1.txt\"" [HKEY_CLASSES_ROOT\.dmp] @="Debugger.Dump" [HKEY_CLASSES_ROOT\Debugger.Dump\DefaultIcon] @="c:\\debuggers x86\\cdb.exe" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_2_0_x86] @="Debug This Dump for .NET 2.0 x86" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_2_0_x86\Command] @="\"C:\\debuggers x86\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x86\\commands_2.txt\"" [HKEY_CLASSES_ROOT\.dmp] @="Debugger.Dump" [HKEY_CLASSES_ROOT\Debugger.Dump\DefaultIcon] @="c:\\debuggers x64\\cdb.exe" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_2_0_x64] @="Debug This Dump for .NET 2.0 x64" [HKEY_CLASSES_ROOT\Debugger.Dump\Shell\Debug_2_0_x64\Command] @="\"C:\\debuggers x64\\windbg\" -z \"%1\" -c \"$<c:\\debuggers x64\\commands_2.txt\""
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 .reload
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 ?. Small thing I know, but that’s how it always begin; very small (from “Big trouble in little China” ?).
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 ?
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…
Carlo
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?
–Unknown