Those of us who practice production debugging are certainly familiar with Microsoft’s Windbg. As John Robbins eloquently describes in this Bugslayer column from MSDN Magazine: “WinDBG is a hardcore debugger that handles everything from kernel mode to user-mode debugging all in a circa-1990 user interface.”
Various hosting environments are basically unsuitable for debugging with Visual Studio’s otherwise respectable Debugger. In its 2003 and 2005 releases, it has been catching up to Windbg (it can now even load dbgeng extensions like the CLR’s almighty Son of Strike) but still has its limitations and still lacks a powerful and flexible command-line interface.
With Windbg being the exclusive tool for a variety of production debugging scenarios, you’d expect Microsoft to treat it as an upper class product. Instead, its users have to put up with embarrassing bugs like this. Sure, the latest release, 184.108.40.206, is labeled as a “beta”, not minding that the previous 220.127.116.11 release was not marked as such, but is now gone off of the face of the Web. You’d figure the posted What’s New notes would at least make the decision on whether upgrading and risking new bugs like the one mentioned above would be worth it, but these contain all the changes included in 18.104.22.168 and don’t seem to document the contents of the latest beta revision. Add that to basic commands that have been a part of the debugger for ages and are referred to in any .NET debugging with Windbg tutorial (“.loadby”) still not being mentioned or fully documented in the debugger help file, debugger.chm. This help file also serves as the primary documentation for Microsoft’s debugging engine, dbgeng.dll. It’s sufficiently incomplete and problematic that the Eclipse IDE’s C++ development environment, attempting to support targeting the Windows SDK (and its bundled Visual C++ 2005-based compiler) and using DbgEng as a debugging engine, had to abandon the effort (though one can hardly blame Microsoft for under-documenting its debugging engine to prevent a competing IDE from utilizing it…).
Add to that the fact that the presumably tiny Windbg team doesn’t seem to have any presence (blogging or otherwise) on the Web. There’s no rough time table for new releases and no modern mechanism for feedback. Is this how Microsoft sees its flagship production debugging product? This wouldn’t be so bad if the Visual Studio Debugger had been brought up to par with Windbg. I hope that given Microsoft’s announced renewed commitment to the native development experience beyond Visual Studio 2008, we’ll get to see some advances in this area.
But even if we remain optimistic about production user-space debugging in future Visual C++ releases, those of us who are debugging kernel-mode code with Virtual Machines and serial cables are still left behind. Perhaps we can hope for the future Windows Driver Kit to finally integrate with Visual Studio and retire the antiquated BUILD utility and even dream of a Visual Studio Kernel Debugger… After all, it supports
Windows CE Embedded Windows as a whole platform, supporting the whole Windows platform doesn’t seem like too much to ask.