Judging the Book by its Cover
The major change in the latest version of WinDBG is kind of hard to miss. If you’ve already tried out the latest version you know exactly what I’m talking about: the new UI. WinDBG has moved from its old, one window workspace interface to a multi-dock, floating window, tabbed interface. It sounds scary, and it is until you’ve recited your prayer, dealt with it as something that you cannot change, and embraced it. Once you’ve done that, it actually turns out to be kind of useful.

UI Change: Docks
Docks are basically containers for other windows (i.e. source windows, locals windows, etc.) and are created by selecting Window->Open Dock from the WinDBG menu. In the old UI there was the one dock, but now you can have as many as you’d like. I never thought I’d actually want to use this, but it turns out to be extremely handy, especially if you’re running on dual monitors. Right now, for example, my WinDBG workspace has three open docks: one for the command window and call stack, one for the source window and locals, and one for disassembly and registers.

UI Change: Windows
In the new UI, any window can either be floating or docked. You can dock and undock windows either by clicking and dragging them around individually or by using the Window->Dock All and Window->Undock All menu items. Manually docking the windows can be wonky at best and the only advice that I can give is to take it slow. It generally takes a couple of tries to get things docked exactly how you want them, but once you get everything just the way you like it, you can save your workspace and, theoretically, never have to deal with it again. I say "theoretically" because I occasionally have issues where the windows appear to take on a life of their own and it takes me a few minutes to get them back to the way they were. But, it just wouldn’t be WinDBG if it didn’t push back at your attempts to make it do what you want every once in a while.

Debugger Command Programs
The coolest feature in the new WinDBG is the addition of debugger command programs. These can best be described as "ghetto debugger extensions," because they let you write small, relatively easy scripts to automate tasks that would normally require a full debugger extension. They support flow control operations such as if, then, while, and for - pretty much every command that you can do in WinDBG you can do from the extensions (for a list of the exceptions check the WinDBG documentation). The documentation in the debugger even provides a small sample script that will walk the active process list and print out the module names.

Source Server
WinDBG has supported having a symbol server for a while, but it now supports the ability to have a source server. The way this works is you add a few steps to your build process and the resulting PDBs will contain information about the location of the source files in your source control system. When a breakpoint is hit within a source module, WinDBG can use the information in the PDB to pull down a copy of the source file that matches the one used to build the currently running version of the driver. This means that if you have a local symbol server setup on which the symbols have been source indexed, WinDBG will just "do the right thing" when analyzing, say, a crash dump, and grab not only the proper symbols, but also the proper source code.

To get more information on how to setup a source server you need to do a custom installation of WinDBG, select the SDK option and read srcsrv.doc in the \sdk\srcsrv directory.

Actual Debugger Extension Documentation
If you’ve been hesitant to write debugger extensions because the documentation was, well, pretty much useless, you might want to give it another look. Over the past couple of releases of WinDBG the documentation has been improved vastly and is definitely worth checking out.

And the Wisdom to Know the Difference…
Found a bug in the ‘Bag? A new version of WinDBG is not released until all known issues are resolved, so it behooves you to actually report your bug instead of just whining about it. If you find a bug or if you have a feature request, you can submit it to the WinDBG team at Windbgfb@microsoft.com.