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

Question

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

And is it commonly used as a complete replacement for the Visual Studio debugger, or more

Answer 1

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.