- Forum
- Windows Programming
- What debugger can you recommend?
What debugger can you recommend?
Hi! What debugger can you recommend?
For Visual Studio 2017 and Windows 10
I would be grateful for any helpful advice.
For Visual Studio 2017 and Windows 10
I would be grateful for any helpful advice.
Obviously visual studios is the best for debugging on windows simply because of the forced PDB format that you must use for debug info for capturing crash dump postmortems, the closest alternative you could also get is clang-cl (which is pretty much just VS + some gcc options from what I can see), but that doesn't offer too many significant advantages over VS (I think lldb could be considered a cool debugger but it is only for linux and mac), if you have absolutely no interest of cross platform support, or if you are already familiar with VS or you have a registration that you don't want to waste, sadly most of this post is gonna talk about mingw/linux, but I have some pointers that also connect to VS.
I actually forgot this was posted on the windows board, rip. But you shouldn't really expect any other answer to your question because the only debugger for VS 2017 is VS 2017 (specifically cdb).
I should first get off my chest that the nice thing about VS is that if it crashed without a debugger hooked, you can technically debug it from the "not responding" popup, or dumping the core from task manager, and this wont work on the Mingw/Mingw+Clang based compiler.
So it really does make sense for VS to be the better choice, so at the end of the day it really is a choice of aesthetics since some people don't like VS because it creates a ton of garbage files (which with some work can be cleaned up obviously), and other minor points like utf-8 source code, cross platform code, and you have to pay to use the the "better" build tools (but that may have changed, I haven't checked). Meanwhile mingw does require you to throw a bunch of DLL's with the executable (unless you do a
Continuing on, one neat thing you can do if you switched to mingw / mingw+clang, is use something called DrMingw, and put exchndl on it, and now you can get stack traces to errors without being forced to hook to a debugger or dumping and reading a core dump (which requires nasty win api setup if you want to do it automatically), and you can do this with minimal setup, and this doesn't create multiple files. Only problem of course is the fact that the result is a plain text file with a stack trace, and you don't have an exact line number to your error, but honestly, just a simple stack trace + log is all that you need when something breaks once in a blue moon, and if you need more info, hooking to gdb should give you the extra info. This is also neat if you want to write short projects and you don't want to copy and paste the same ugly WinDbg.h WinDbg.cpp into every project so people can give you core dumps (or if you occasionally test out your own code without a hooked debugger). You can also mix this with a little bit of win api code by defining a dumb exception callback and instead of decoding it, you print what happened (optionally tell what type of exception it is), explain what the .RPT file is, and maybe ask the person to email the RPT or something. And you are probably thinking, of course a core dump is probably better in every possible way, but with every version you release that could be a bit annoying since it screws up your signals, and if your code is open source, people can read the stack trace (although highly optimistic), and ask themselves why that error could possibly be related to, and maybe even post a github issue or something.
Also there is this example which can be useful for you if you use VS or not:
https://spin.atomicobject.com/2013/01/13/exceptions-stack-traces-c/
It says Mingw, but it also should work for Visual Studios (with minor modification). Note that I have a gut feeling that Mingw C++ wont work with finding the line number (but I haven't tested, it would be cool if it did, but then again, "system"...).
Another example of a minidumper can also found at http://www.debuginfo.com/index.html which also tells you how to use the low level commands of windbg (but I would imagine using the VS IDE would be much more easier to use perhaps).
There is also a plugin for VS called pvs studio which just gives more in depth warnings, this is a static analyzer (this also works without VS).
There are also much more richer set of automagical C++ debugging tools on linux and mac, it is very worthwhile to try a really small linux virtualbox on your computer, and try out things like valgrind (known for memory leaks, but does many other things), and with clang's sanitizers (similar but different than valrgind since it changes the code generated), and on mac I think there is a clang static analyzer as well (not sure how useful it is).
Windows also has a memory leak detection system, something to do with CRT functions this is an example from 2002 but should still be perfectly valid (its a shame that the listings urls don't work, perhaps you need the dr dobbs DVD from archive.org, or look for a website that ripped it.
http://www.drdobbs.com/simple-memory-leak-detection/184416404
But this requires more setup, and when you start out you really should focus on making your code as short and concise as possible first, maybe focus on learning codestyles and idioms that are designed to make the code easier to read / avoids writing buggy code instead of using tons of tools pretending like they will save you, because I would consider this win CRT code as a bit bloaty and weird (its old C code after all), and if you feel too confident that your tools will find all the bugs, you will be proven wrong when you it fails you and now the error is much harder to figure out since not even your tools can see anything wrong.
But of course these tools are useful and I am not saying that you should exclusively avoid debugging tools since that isn't gonna prevent you from writing hard to debug code, but but it all depends on your situation and what you need and want. In my opinion, software that debugs your code is half the battle, having a array of thinking processes is the other, like rubber duckying, or taking the flawed code and recreating it in a minimal project, or test suits, asserts, printf, and many other techniques.
There are probably much more to talk about, including VS plugins, and built in features, for example resharper is neat and probably worth the price, but it is all super opinion based.
tldr VS is ok but it looks ugly if you presented it in github, Linux has cool tools but it is not windows, but in the end you are better off just reading books, practicing, and making stuff people are interested in, than worrying about this crap, debugging isn't hard, and as long as you have stack traces and breakpoints, that might be all the info you will ever need (but sometimes not).
I actually forgot this was posted on the windows board, rip. But you shouldn't really expect any other answer to your question because the only debugger for VS 2017 is VS 2017 (specifically cdb).
I should first get off my chest that the nice thing about VS is that if it crashed without a debugger hooked, you can technically debug it from the "not responding" popup, or dumping the core from task manager, and this wont work on the Mingw/Mingw+Clang based compiler.
So it really does make sense for VS to be the better choice, so at the end of the day it really is a choice of aesthetics since some people don't like VS because it creates a ton of garbage files (which with some work can be cleaned up obviously), and other minor points like utf-8 source code, cross platform code, and you have to pay to use the the "better" build tools (but that may have changed, I haven't checked). Meanwhile mingw does require you to throw a bunch of DLL's with the executable (unless you do a
-Wl,-Bstatic), and the debug problem that I mentioned already. So if you are sold on VS, good, I am not gonna argue with you, it works, and the path of crossplatfrom C++ code is a bumpy one.Continuing on, one neat thing you can do if you switched to mingw / mingw+clang, is use something called DrMingw, and put exchndl on it, and now you can get stack traces to errors without being forced to hook to a debugger or dumping and reading a core dump (which requires nasty win api setup if you want to do it automatically), and you can do this with minimal setup, and this doesn't create multiple files. Only problem of course is the fact that the result is a plain text file with a stack trace, and you don't have an exact line number to your error, but honestly, just a simple stack trace + log is all that you need when something breaks once in a blue moon, and if you need more info, hooking to gdb should give you the extra info. This is also neat if you want to write short projects and you don't want to copy and paste the same ugly WinDbg.h WinDbg.cpp into every project so people can give you core dumps (or if you occasionally test out your own code without a hooked debugger). You can also mix this with a little bit of win api code by defining a dumb exception callback and instead of decoding it, you print what happened (optionally tell what type of exception it is), explain what the .RPT file is, and maybe ask the person to email the RPT or something. And you are probably thinking, of course a core dump is probably better in every possible way, but with every version you release that could be a bit annoying since it screws up your signals, and if your code is open source, people can read the stack trace (although highly optimistic), and ask themselves why that error could possibly be related to, and maybe even post a github issue or something.
Also there is this example which can be useful for you if you use VS or not:
https://spin.atomicobject.com/2013/01/13/exceptions-stack-traces-c/
It says Mingw, but it also should work for Visual Studios (with minor modification). Note that I have a gut feeling that Mingw C++ wont work with finding the line number (but I haven't tested, it would be cool if it did, but then again, "system"...).
Another example of a minidumper can also found at http://www.debuginfo.com/index.html which also tells you how to use the low level commands of windbg (but I would imagine using the VS IDE would be much more easier to use perhaps).
There is also a plugin for VS called pvs studio which just gives more in depth warnings, this is a static analyzer (this also works without VS).
There are also much more richer set of automagical C++ debugging tools on linux and mac, it is very worthwhile to try a really small linux virtualbox on your computer, and try out things like valgrind (known for memory leaks, but does many other things), and with clang's sanitizers (similar but different than valrgind since it changes the code generated), and on mac I think there is a clang static analyzer as well (not sure how useful it is).
Windows also has a memory leak detection system, something to do with CRT functions this is an example from 2002 but should still be perfectly valid (its a shame that the listings urls don't work, perhaps you need the dr dobbs DVD from archive.org, or look for a website that ripped it.
http://www.drdobbs.com/simple-memory-leak-detection/184416404
But this requires more setup, and when you start out you really should focus on making your code as short and concise as possible first, maybe focus on learning codestyles and idioms that are designed to make the code easier to read / avoids writing buggy code instead of using tons of tools pretending like they will save you, because I would consider this win CRT code as a bit bloaty and weird (its old C code after all), and if you feel too confident that your tools will find all the bugs, you will be proven wrong when you it fails you and now the error is much harder to figure out since not even your tools can see anything wrong.
But of course these tools are useful and I am not saying that you should exclusively avoid debugging tools since that isn't gonna prevent you from writing hard to debug code, but but it all depends on your situation and what you need and want. In my opinion, software that debugs your code is half the battle, having a array of thinking processes is the other, like rubber duckying, or taking the flawed code and recreating it in a minimal project, or test suits, asserts, printf, and many other techniques.
There are probably much more to talk about, including VS plugins, and built in features, for example resharper is neat and probably worth the price, but it is all super opinion based.
tldr VS is ok but it looks ugly if you presented it in github, Linux has cool tools but it is not windows, but in the end you are better off just reading books, practicing, and making stuff people are interested in, than worrying about this crap, debugging isn't hard, and as long as you have stack traces and breakpoints, that might be all the info you will ever need (but sometimes not).
closed account (z05DSL3A)
oh yeh there's also...
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
Deleaker (https://www.deleaker.com/) is good debugger for Visual Studio. It searches for most types of leaks.
I also used the built-in debugger, it is good too.
I also used the built-in debugger, it is good too.
I am very impressed with the poteto's answer! It's great. Thanks to you, I learned about useful plugins for Visual Studio. Many thanks for such a detailed answer!
I know Valgrnid is a great debugger, but now I’m working with Windows. Therefore, I am looking for something similar for Windows.
I know Valgrnid is a great debugger, but now I’m working with Windows. Therefore, I am looking for something similar for Windows.
Topic archived. No new replies allowed.