MS maintains two separate debugger product lines – one (supposedly owned by the smaller team) being WinDbg and the other shipped with Visual Studio. There’s an ever-going online flame for superiority between fans of both debuggers (sample 1, sample 2).
By and far WinDbg is considered the ‘serious’ brother, and partially for a good reason. There are important domains where WinDbg is the only option – notably kernel mode debugging. It is also said to be easier on remote debugging (which I’ve tried only with VS, and admittedly had some trouble). However, I’ve too often seen claims for WinDbg superiority that are just based on poor VS skills – I’ll try and dedicate some posts to show VS parallels of common WinDbg capabilities. I currently believe if you do user mode debugging with source code (even in production builds), there’s no real reason for you to step back to the command-line UI of WinDbg. I’d be happy to hear if anyone has different experience.
So, starting off with memory search. This is a relatively known capability of WinDbg, but it’s apparently much less known it is in fact available in VS.
You can search through a memory range for a particular pattern (e.g., a string) or one of several patterns. You do this by typing at the Immediate window (Ctrl+Alt+I while debugging), and the complete syntax is here.
A notable shortcoming of VS is that it does not implement the ‘L?’ address-range WinDbg syntax, so a single search is limited to a memory range of 256M. On the few occasions where I needed this functionality, this wasn’t a major issue.
Ofek's Visual C++ stuff 
Ofek, I’ll be the first to admit Visual Studio 2008’s Debugger is the premier debugging solution for a variety of native and mixed managed/native debugging scenarios. It now provides great support for Remote Debugging, with the host-side tool appropriately configuring Windows Firewall, etc. However, I have a few comments in defense of Windbg.
The characterization of using Windbg as “stepping back into command-line UI” is exaggerated. I can scarcely think of any feature Windbg shares with the Visual Studio debugger that is not accessible from the Windbg GUI, without issuing a typed command. The GUI provides full support for memory browsing, source-level debugging, call stack examination and variable watches. The stepping-back part is true to the extent that the Windbg team has failed to update the early 1990’s style GUI and it is way outmatched by Visual Studio’s 3D controls and other eye candy. Visual Studio’s nicer GUI has more than aesthetic implications – expanding structure variables in the Watch window offers an outright superior experience in Visual Studio, for instance.
However, when comparing the relative utility of the Visual Studio Debugger and Windbg in production user-mode debugging scenarios, several differences which you did not address ought to be considered. One in particular is Windbg’s extensibility.
Windbg provides an API and SDK for extending the debugger engine directly. Indeed, the potential of the debugger engine’s extensibility via this facility is so great that Microsoft implemented the entire managed debugging functionality of Son of Strike (SOS) as such a DbgEng extension, and then retrofitted the Visual Studio Debugger to support enough of the same interfaces to allow the SOS binary to be hosted in the Visual Studio Debugger environment, as well. However, SOS notwithstanding, Visual Studio Debugger does not support generic DbgEng extensions.
C++ projects that define specialized classes and are used in complex deployments may benefit greatly from custom extensions targeting them. The Visual Studio Debugger has the poorly documented Visualizers facility (autoexp.dat) that allows extending variable watches for complex custom types, but doesn’t offer similar code-based extensibility. It is extensible in the sense you can add support for debugging your own programming language or platform… but such things are not on the agenda of most Visual Studio end users.
I think Windbg’s command-line UI shouldn’t be so quickly judged as not worth the trouble. I claim that the novice debugger user can use the Windbg GUI, like she would have used the VS Debugger GUI. On the other hand, the lack of a powerful command interface in the VS Debugger is a significant disadvantage. If you do the occasional memory search, a GUI is fine. If you find yourself doing frequent memory searches and facing complex scenarios, the utility of having a powerful command line becomes evident. As debugging scenarios in production become increasingly complicated, appreciation for the ability to script the debugger increases. On the other hand, the VS Debugger does not lend itself that well to such automation.
I’d also like to note that the lines between user-mode debugging and kernel-mode debugging are not as clear cut as they may appear. The kernel debugger can be useful in a surprising number of seemingly user-mode only debugging scenarios. The vast majority of user-mode developers are unfamiliar with Windows kernel mode programming and therefore shy away from the unfamiliar kernel debugger. However, it provides functionality useful for user-mode multi-threaded and multi-process interactions. For example, it can be used to analyze wait chains on kernel objects – determining which other thread in which other process is holding a resource (e.g, a mutex) a thread you are debugging is stuck waiting for.
To conclude, I’d like to state that my own opinion is that merging Windbg features missing from Visual Studio’s Debugger in future versions of Visual Studio is the probably the best course of action on Microsoft’s part for the production debugging community. The VS Debugger has the backing of the formidable Developer Division and not just some small, presumably under-resourced team. Support for kernel debugging, DbgEng-style extensibility and adding a powerful command-line and scripting facility would bring up the VS Debugger to the big league of production debugging.
Koby, I’m flattered and humbled by the investment in your comment…
You did bring up important points that I did not mention, and while I hope not to re-ignite a full fledged VS-WinDbg flame – I’ll take the chance to at least mention two more points.
Regarding scripting:
In scripting tasks, ease of use is the dominant factor. It would be hard to compete with VB in that field, given that all the VS functionality is accessible to it through a reasonable object model.
http://msdn.microsoft.com/en-us/library/8h31zbch(VS.80).aspx
Regarding debugger extensibility:
Admittedly I know little of the WinDbg extensibility hooks. VS extensibility does seem focused on code-interaction, rather than binaries-interaction. However, I vividly remember reading that the entire C# debugger was implemented internally in MS as a VsPackage – i.e, entirely using publicly* available interfaces (can’t find the quote now, it’s 1:15AM here…).
In principle, if you’re dissatisfied with a particular aspect of, say, C++ debugging, you could pin-ooint and modify the specific interface that requires modification, and delegate the rest to the standard implementation.
_______
* ‘public’ here is of course inaccurate. Does extending WinDbg requires similar ‘Partner Programs’, or is it truly public?
Thank you for your kind words, Ofek. Since you originally referenced my post, I felt compelled to weigh in :-)
It’s hard to beat VBA as far as ease of use goes. Another important advantage is that powerful debugging facilities are available for VBA macros, which becomes important as your automation scales to complicated scenarios. By contrast, Windbg has cryptic, custom syntax that is not shared by anything else, with scarce documentation and parsing oddities.
However, it is important to realize that the Visual Studio automation model, in the context of the Debugger, and Windbg extensions attempt to solve different problems. Windbg extensions interface with the debugger engine and are able to read and write to arbitrary locations in the debugee’s address space, iterate over the loaded module list and such. On the other hand, Visual Studio’s automation interfaces are useful for things like automatically adding an expression to the Watch list, performing Step Into, Continue and other debugger commands. In other words, Visual Studio’s automation is for controlling what the debugger can already do, while Windbg’s extensions are for making it do new things. How suitable is VS automation for doing something like printing the values of all environment variables in the debugee process by examining the PEB? Even if it can theoretically be done, Windbg’s extension interfaces are oriented for that sort of thing.
References to partner programs like VSIP for Visual Studio extensibility are more a relic of the past than anything else, since the Visual Studio SDK has been openly and freely downloadable without registration for a while. At any rate, everything required for programming Windbg extensions is included in the sdk subdirectory of Windbg itself – headers, import libraries for dbgeng and dbghelp and several samples. There’s even a C++ framework, EngExtCpp, to make developing extensions easier by implementing common boilerplate such as parsing of extension command arguments, etc.
Koby, thanks again for the thoughtful comment. what can i say? you’re obviously a native in universes that I only read about. I still firmly believe that too often claims in favour of WinDbg are based on just VS-misconceptions (see the link in the post to the discussion in StackOverflow, no less) – but it’s probably true that even in user mode, with source code, WinDbg does have it’s edge.
Cheers,
Ofek
Pingback: Viewing Debugee Environment ariablesV « Ofek’s Visual C++ stuff