Why use windbg vs the Visual Studio (VS) debugger ?

Question

What are the major reasons for using Windbg vs the Visual Studio debugger?

Edit: and is it commonly used as a complete replacement for the VS debugger, or more for when the need arises.

Answer 1

I have used it when I've been sent .dmp files from an NT4.0 server - MSVC won't load these old format files.

Answer 2

Lightweight, can be run without installing it on a client's machine, fast, can debug kernel mode.

Answer 3

If you are wondering why you should use windbg over Visual Studio, then you need to read Advanced Windows Debugging. Any time you need to debug a truly ugly problem windbg has better technology to do it with than Visual Studio. Windbg has a more powerful scripting language and allows you to write DLLs to automate difficult problems. It will install gflags.exe, which gives you better control over the heap for debugging memory overwrites.

You don't actually need to run the install, you can just copy the files over and be ready to go. Also it installs adsplus.vb, so you can take mini-dumps of running processes. It is also very easy to setup to perform remote debugging. There is nothing better than being able to debug a problem from your own desk instead of fighting the 15" monitor that flickers on a test PC.

For day to day code writing I use Visual Studio, but once you need to start debugging problems from other computers or find yourself in a very ugly situation, windbg is the only way to go. Spending some time learning windbg is a great investment. Also if you look at crash dumps there are two great resources, http://www.dumpanalysis.org/blog and http://blogs.msdn.com/ntdebugging/default.aspx that do all their debugging using windbg.

Answer 4

You don't specify whether you're debugging native or managed code. It doesn't affect the answer, WinDbg is extremely useful for both, but many people believe that WinDbg is somehow less relevant when debugging .NET apps. Not so. As a bonus, you can learn a lot about how the .NET platform works by debugging your .NET app in WinDbg with the SOS extension. Run up (or attach to) your .NET app in WinDbg and type...

.loadby sos mscorwks

...to be sure that you load the right extension for the version of the CLR in use. Then type...

!help

... to see what commands are available in the SOS extension.

I've heard it joked that Microsoft only has one developer tool, and it's WinDbg. Everything you could possibly want for debugging is in there, or in an extension. Sure, a subset of those things are also available in VS with a friendlier UI... :-)

Answer 5

Here are some further links to help with using WinDbg, most are .NET specific.

• John Robbins talks about using cmdtree to create a command window.
• Here is a quick WinDbg/SOS cheat sheet.
• If broken it is, fix it you should has a bunch of WinDbg/Sos related articles, mainly around debugging ASP.NET.
• Here is an old overview of SOS from MSDN mag. It is about .NET 1.1 so its age is showing.

Answer 6

Mixing kernel-debugging plus remote-user-mode-debugging.

AFAIK, visual studio still cannot do remote debugging in the mode I describe as "solution". That's a darn good reason to use windbg.

Problem:

• Set up windbg across 1394. Your app runs on the "target". Windbg runs on the "host".
• Run visual studio on the host
• Have visual studio launch your app on the target using the remote tools.
• Break into the kernel mode windbg to halt the target
• Wait long enough for visual studio's TCP connection to timeout
• "g" in windbg to un-halt the target
• observe your app "pop" when the remote monitor realizes the network connection is gone
• restart your app :(

Solution:

• Don't use visual studio.
• Run a user mode windbg on the target with "-server"
• Have the target's windbg launch your app.
• On the host, start a 2nd windbg that connects to target with "-remote".
• If the TCP connection dies just start another windbg instance on the host and nothing is lost. Your app didn't die because the controlling user mode windbg process is running on the target.

Also, I find it easier to use the same debugger for both kernel mode and user mode, windbg is very powerful even in user mode, and I can leverage my own windbg extensions in both kernel mode and user mode instances.

Answer 7

Is the latest visual studio still missing an equivalent to windbg's "-o" that makes the debugger automatically attach to child processes? Very useful for apps that must be run from a complicated .bat file, or apps that fork and exit the parent process.

Answer 8

I always liked the watch and trace feature: 'wt' -> It prints to the output window all the function calls as they happen. That was pretty cool stuff!