What can WinDbg tell me that Visual Studio can't?

Question

I'm still a relative novice with C++, and I've run into a problem with at third-party DLL that I'm statically linking to from my native C++ DLL. I'm using Visual Studio 2012 to debug my DLL.

(FWIW, the third-party DLL is Sybase Open Client, and I'm debugging my DLL via a C# executable I've written, which loads my C++ DLL dynamically.)

I've used Visual Studio to step into the disassembly and look at the registers and memory usage for the third-party DLL. Visual Studio has given me a lot of good information about what's going on inside my process but I feel like there may be more there than what I'm seeing, and maybe an easier or more efficient way to get to it.

I've read that WinDbg is a very powerful tool, but that it takes considerable time and effort to learn to use it well. My question is: is it worth the effort to learn to use WinDbg, or will the debugging tools in Visual Studio give me pretty much the same information?

Shaftesbury

Try walking the Windows heaps in the Visual Studio debugger sometime. Then actually succeed in doing so with WinDbg. – Tragicomedy

WinDbg script as arcane as its syntax is can be powerful compared to what VS allows, although perhaps with an addin or macro you can get similar functionality in VS. – Pella

Memory leak finding, automatic crash analysis, handle leak tracing, memory searching, ability to dump call stacks of all threads easily, set/unset breakpoints when breakpoints are hit, debugging on machines that don't have VS installed, .net debugging, logging, scriptable, supports loops.. etc.. Basically what you get is a lightweight, no BS debugger that has tons of tools that automate painful tasks that are either difficult or impossible using VS, the highest endorsement you will see is that MS use this to debug Windows, steep learning curve but ultimately very rewarding – Compliancy

You need Windbg as often to debug a C++ program as you need a fifty horsepower chainsaw to take care of the lawn. Handy to get the tough jobs done but you certainly don't want to need it too often. – Lomeli

One more thing: the stand-alone-installation capability (literally a file-copy) coupled with thumb-drive chock-full of release-pdbs and your sources (bit-lockered, of course) makes debugging in a real-world escalated customer environment actually feasible. No, it isn't pretty (in fact, it is down-right butt-ugly), but its usefulness seriously cannot be overstated. – Tragicomedy

Answer 1

My question is: is it worth the effort to learn to use WinDbg, or will the debugging tools in Visual Studio give me pretty much the same information?

That really depends on what kind of programming you are doing.

WinDBG does allow you to look at structures internal to the OS. It allows you to look at threads and processes throughout the entire system and debug code that runs in the OS kernel itself (such as drivers). There is substantial ability to write scripts to dig out certain information, or, I believe, even write plugins that run within WinDBG to perform certain tasks.

Most of this is either difficult or impossible with a VS type debugger.

It's almost impossible for me, or anyone else here, to tell you whether you should learn to use WinDBG. It certainly will do you no harm to know, but it's entirely possible to go a long time in your life without needing it.

Shaylyn