What can WinDbg tell me that Visual Studio cannot?

Question

I am still a relative newbie with C ++, and I had a problem with a third-party DLL, with which I statically link to my native C ++ DLL. I am using Visual Studio 2012 to debug my DLL.

(FWIW, a third-party DLL is Sybase Open Client, and I am debugging my DLL through the C # executable that I wrote, which dynamically loads my C ++ DLL.)

I used Visual Studio to disassemble and look at registers and memory usage for a third-party DLL. Visual Studio provided me with a lot of good information about what is going on inside my process, but I feel that there may be more than what I see, and perhaps a simpler or more efficient way to get to it.

I read that WinDbg is a very powerful tool, but it takes a lot of time and effort to learn how to use it well. My question is: is it worth learning to use WinDbg, or are the debugging tools in Visual Studio giving me almost the same information?

Answer 1

My question is: is it worth learning to use WinDbg or are the debugging tools in Visual Studio giving me almost the same information?

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

WinDBG allows you to view structures internal to the OS. It allows you to view threads and processes throughout the system and debug code that runs in the OS kernel itself (for example, drivers). There is a significant opportunity to write scripts to extract certain information or, in my opinion, even write plugins that run in WinDBG to perform certain tasks.

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

For me, or anyone else here, it's almost impossible to tell if you should learn to use WinDBG. Of course, you will not be harmed to know, but it is quite possible for a long time in your life, without requiring it.