Best IT Recipes

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

What are the main reasons for using WinDbg against the Visual Studio debugger?

And whether it is usually used as a complete replacement for the Visual Studio debugger or more, when the need arises.

+49
visual-studio windbg
Sep 19 '08 at 20:11
source share
8 answers

If you're wondering why you should use windbg over Visual Studio, you need to read Advanced Windows Debugging . Every time you need to debug a truly ugly problem, Windbg has a better technology for this than Visual Studio. Windbg has a more powerful scripting language and allows you to write DLLs to automate complex problems. It will install gflags.exe, which will give you better heap control for debugging memory.

You really do not need to run the installation, you can just copy the files and be ready to go. He also installs adsplus.vb, so you can perform mini-dumps of running processes. It is also very easy to configure remote debugging. There is nothing better than being able to debug a problem from your own desk instead of fighting a 15-inch monitor that flickers on a test PC.

For everyday code writing, I use Visual Studio, but as soon as you need to start debugging problems from other computers or in a very ugly situation, windbg is the only way to go. Spending some time training 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 , which do all their debugging with windbg .

+60
Sep 19 '08 at 20:35
source share

Here are some additional links that will help with WinDbg , most of them relate to .NET.

+11
Sep 24 '08 at 13:04
source share

You do not indicate whether you are debugging your own or managed code. This does not affect the answer, WinDbg is extremely useful for both, but many people find that WinDbg is somehow less relevant when debugging .NET applications. Not this way. As a bonus, you can learn a lot about how the .NET platform works by debugging your .NET application in WinDbg with the SOS extension. Launch (or attach) your .NET application in WinDbg and type ...

.loadby sos mscorwks

... to make sure you download the correct extension for your version of the CLR. Then enter ...

 !help

... to find out what commands are available in the SOS extension.

I heard that he was joking that Microsoft has only one tool for developers, and that is WinDbg. Everything you might want for debugging is there or in the extension. Of course, a subset of these things are also available in VS with a more friendly interface ... :-)

+6
Sep 23 '08 at 9:11
source share

I used it when they sent me .dmp files from an NT4.0 server. MSVC will not download these old format files.

+3
Sep 19 '08 at 20:13
source share

Mixing kernel debugging and remote user debugging.

AFAIK, visual studio still cannot perform remote debugging in the mode that I describe as a "solution." This is a damn good reason to use windbg.

Problem:

  • Configure windbg through 1394. Your application runs on the "target". Windbg runs on the host.
  • Run visual studio on the host
  • Ask the visual studio to launch the application on the target using remote tools.
  • Break into windbg kernel mode to stop the target.
  • Wait enough time to connect the TCP connection for visual studio to a timeout
  • "g" in windbg to stop the target stop
  • Watch your pop app when the remote monitor realizes that the network connection has passed.
  • restart the application: (

Decision:

  • Do not use visual studio.
  • Run custom windbg mode for the target using "-server"
  • You have a target windbg application to run your application.
  • On the host, run the second windbg, which connects to the target using "-remote".
  • If the TCP connection dies, just run another instance of windbg on the host and nothing is lost. Your application has not died because the managed user mode windbg is working on target.

In addition, it’s easier for me to use the same debugger for both kernel mode and user mode, windbg is very efficient even in user mode, and I can use my own windbg extensions in both kernel mode and user mode.

+3
Feb 11 '09 at 7:21
source share

Lightweight, can be launched without installing it on the client machine, quickly, can debug kernel mode.

+2
Sep 19 '08 at 20:16
source share

Does the last visual studio still have no windbg "-o" equivalent, which makes the debugger automatically bound to child processes? Very useful for applications that need to run from a complex .bat file or applications that use fork and exit the parent process.

+2
Feb 11 '09 at 7:24
source share

I always liked the clock and trace function: 'wt' -> It prints all function calls in the output window as they arise. It was great stuff!

+1
Jul 17 '10 at 5:18
source share


More articles:


All Articles