Debugging can be challenging. Stepping through a function to understand what went wrong, looking through the call stack to see where did that value come from... In either case adding watch expressions or looking through a list of locals can take quite a time. However, things get easier if you just point your mouse at a variable of interest. Moreover, classes and structures will be expanded with one click, allowing to find the field you need quickly and conveniently.
Debugger is much more than a tool for analyzing crashes and wierd behavior. Many bugs can be prevented by stepping through a freshly written function and checking that it behaves as expected. Sometimes you are curious "would the function behave correctly if this condition was true?". And in most cases it does not mean changing the code and restarting. Just hover the mouse over a variable, double-click at the value and type in the new one!
Debugging can be challenging. Stepping through a function to understand what went wrong, looking through the call stack to see where did that value come from... In either case adding watch expressions or looking through a list of locals can take quite a time. However, things get easier if you just point your mouse at a variable of interest. Moreover, classes and structures will be expanded with one click, allowing to find the field you need quickly and conveniently.
One typical debugging scenario is analyzing why does a function call fail by going through the function step-by-step. And what do you do when you've just discovered that a function called another function that returned an error? Restart debugging? There's a better idea: just drag the yellow statement marker to the line you want to be executed next, like the function that has just failed, and then simply step in. Simple, isn't it?
4. Edit and continue
Debugging a complex program, or a plugin? Found an error, but don't want to lose time stopping, rebuilding and restarting again and the function is called too often to use the previous trick each time? No problem, just fix the bug in-place and continue stepping. Visual Studio will modify your program and continue debugging with no need to restart.
Beware, though. Edit-and-continue has a bunch of known limitations. First, it won't work for 64-bit code. If it refuses to work for your C# app, go to project settings, Build page, then select "x86" as Platform Target. Don't worry, the Platform Target for the Release configuration is separate from the debug one and can still be "Any CPU".
Second, the edit-and-continue changes should be local, i.e. within one method. If you change the method signature, add new methods or classes, you'll have to restart the app, or undo the changes to continue. Changing methods containing lambda expressions implies modifying the auto-generated delegate classes and thus prevents continuing.
Probably, every modern debugger has a watch window. However, what's really cool about the Visual Studio one is how easy you can add and remove variables there. Just click at the empty line, type your expression and press Enter. Or simply press delete button to remove an expression that is no longer needed.
Moreover, the information you can get from the watch window is not limited to "normal" variables. You can enter$handles to track the amount of handles opened by your application (and find leaks easier), $err to see the error code of the last function (and then use Tools->Error Lookup to get a meaningful description), or @eax(@rax for 64-bit code) to see the register containing the return value of a function.
Optimizing the performance of the critical parts of your program can be much easier using the interactive disassembly mode. Visual Studio shows you the instructions corresponding to every line of your code and allows running the code step-by-step, as well as setting breakpoints at arbitrary locations. And, of course, the expression evaluation and modification will work just like for the C++ code.
Debugging multi-threaded applications can be painful. Or it can be fun. Depends on your debugger. One really nice feature of Visual Studio 2010 is the stack view in the threads window. You can get a convenient overview of all your threads and navigate through their call stacks directly from the window.
If you're trying to reproduce a rare event and getting too many false positives with your breakpoints, you can easily make them conditional! Simply specify the condition for a breakpoint and Visual Studio will automatically ignore the breakpoint when the condition does not hold.
Some bugs are caused by incorrect structure definitions, missing alignment attributes, etc. Seeing the raw memory contents simplifies locating and fixing those bugs. Visual Studio features a convenient memory window that can interpret the values as 8/16/32/64-bit numbers, as well as floating-point numbers and allows changing them on-the-fly by simply typing the new values over the old ones like in a text editor.
10. Go To Definition
One last feature to mention is not directly related to debugging, rather to exploring big projects. If you are trying to find a bug in some code you have not written yourself, having a quick answer to "what is this type" or "what does this function do" can save you a lot of time. And Visual Studio does this with ease via the Go To Definition command.
11. Command Window
This eleventh trick has been suggested by chaau and it can indeed save you a lot of time. Visual Studio supports a Command Window that can be activated through the View->Other Windows->Command Window menu. Once active, you can type various commands to automate the debugging. For example, you can easily evaluate an MFC COleDateTime variable by running a simple command:
? dt.Format("%Y-%m-%d %H:%M:%S")
License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)