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?

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.