Brand New 'Bag -- The Latest on WinDBG
The NT Insider, Vol 11, Issue 3&4, May-August 2004 | Published: 18-Aug-04| Modified: 18-Aug-04
What good would an entire issue about testing be without a discussion of our favorite kernel debugger, WinDBG? As I’m sure most of you are aware, when you’re first starting out with WinDBG it’s a good idea to keep a copy of the Serenity Prayer handy. But, once you’ve worked the ‘Bag a bit and you’ve learned to accept the things that you cannot change about it, its real power and elegance come through. Hopefully you haven’t thrown that Serenity Prayer card away just yet though, because there’s a new ‘Bag in town and you just might need it for a little while longer.
Judging the Book by its CoverThe 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: DocksDocks 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: WindowsIn 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.
Probably the nicest thing about the new UI is the fact that it now supports tabbed windows. When you drag a window into a dock, if you drag it over an existing window it will create tabs to use to switch between the windows. This is fantastic for having multiple source windows open simultaneously.
Another quick tip for the new windows - you can access different options for the different types of windows by right clicking the window’s title bar or by clicking the bizarre little icon next to the X.
Debugger Command ProgramsThe 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.
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 DocumentationIf 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.
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment
"Finally closer to Visual C++"
Since I was coming from the Visual C++ world (including .NET), I was really looking for such features of WinDBG, and thanks to OSR, I heard about them. I'm downloading the new version and very impatient to remove the old one to come closer to Visual C++ dev environment, which is from far, the coolest of the world ;-).
16-Sep-04, Frederic Thomas
Is 'wonky' a technical term?
27-Aug-04, Samuel Peterson