Is there any benefit to using Visual Studio as a debugger over WinDbg?
windbg is more powerful. It allows to enter much more commands to do stuff VS cannot. It is very useful if you want to debug generated native code from .NET code. It also has various plugins for ton of stuff VS cannot do. But for regular simple C/C++ code debugging VS is fine.
To be more clear, is the any advantage using Visual Studio for debugging C/C++ code compared to WinDbg? Is there anything Visual Studio can do for debugging that WinDbg cannot and vice versa?
Technically you can do in VS everything you can do in WinDbg. Because VS can read and write process memory, you can analyze and figure out everything just with memory window.
But some things could be much easier done in WinDbg because of custom plugins.
Nevertheless, basic source level debugging (breakpoints, stepping, variable watches) works just fine in VS. There is no reason to switch to WinDbg for that.
But some things could be much easier done in WinDbg because of custom plugins.
Nevertheless, basic source level debugging (breakpoints, stepping, variable watches) works just fine in VS. There is no reason to switch to WinDbg for that.
Edited by Mārtiņš Možeiko
on
Thank you.
I am only asking as all I use Visual Studio for is debugging and I was wondering if WinDbg could replace that entirely. WinDbg is extremely fast and does things instantly compared VS. I will try it out and see if it can replace what I need.
I am only asking as all I use Visual Studio for is debugging and I was wondering if WinDbg could replace that entirely. WinDbg is extremely fast and does things instantly compared VS. I will try it out and see if it can replace what I need.
Yes, it can replace VS.
By default the interface it may look a bit alien, because it is more like gdb - command prompt oriented . But you can adjust it to work like VS.
Here's how you do source code debugging. Here's how you view local variables.
By default the interface it may look a bit alien, because it is more like gdb - command prompt oriented . But you can adjust it to work like VS.
Here's how you do source code debugging. Here's how you view local variables.
Edited by Mārtiņš Možeiko
on
I would like to switch to WinDBG and have actually tried multiple times to move my workflow over to it, but I always find there are problems regarding restart or saving breakpoints across runs or various things that make it bad for workflow. I suppose it's time for me to try again (it's a bit of a ritual at this point), perhaps :)
In general, I agree with Martins, WinDBG is definitely a better _debugger_, so you definitely don't lose anything in terms of debugging features moving from Visual Studio to it. If anything it'd be the other way around. But I've always in the past found there to be workflow problems with it, as well as sometimes it being incompatible with PDBs in weird ways that are hard to decipher.
- Casey
In general, I agree with Martins, WinDBG is definitely a better _debugger_, so you definitely don't lose anything in terms of debugging features moving from Visual Studio to it. If anything it'd be the other way around. But I've always in the past found there to be workflow problems with it, as well as sometimes it being incompatible with PDBs in weird ways that are hard to decipher.
- Casey
Note that WinDBG can be integrated into Visual Studio (since VS2012). See http://blogs.msdn.com/b/mariohewa...-2012-and-windbg-integration.aspx
There is a ton of stuff that WinDBG can do that Visual Studio's debugger can't begin to touch. Searching memory, viewing the process' heaps, more sophisticated breakpoints, and so forth.
I also have a similar ritual for my New Year resolution: never launch Visual Studio. I go as far as to using cdb (command-line debugger that is part of the debugger tools) but, as was already said, there are always subtle issues that make it hard to stick with.
There is a ton of stuff that WinDBG can do that Visual Studio's debugger can't begin to touch. Searching memory, viewing the process' heaps, more sophisticated breakpoints, and so forth.
I also have a similar ritual for my New Year resolution: never launch Visual Studio. I go as far as to using cdb (command-line debugger that is part of the debugger tools) but, as was already said, there are always subtle issues that make it hard to stick with.
I am trialling it out now. It's workflow is a little annoying; I can already see the benefits but the need to start from scratch every time is really annoying.
You can write scripts for windbg (or even C/C++ plugins). Not sure of how much is possible with it, but for sure you could automate something with it.
Edited by Mārtiņš Možeiko
on
Yeah basically if the state of your debugging could be saved, and if the fails-to-load-symbols bugginess has been resolved, then Visual Studio could go in the trash heap. If someone does do the work to figure out how to not "start from scratch every time" as gingerBill mentioned, please post about it here... I'd check it out again.
- Casey
- Casey