Debugging is a major part of the development lifecycle. Sometimes
challenging, sometimes puzzling, sometimes annoying, one for sure - it
is unavoidable for any not-so-trivial program. The progress of debugging
tools over the last years has made many debugging tasks much easier and
less time-consuming.
This article summarizes ten debugging tricks and techniques that can save you a lot of time when using Visual Studio.
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
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.
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.
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.
This article summarizes ten debugging tricks and techniques that can save you a lot of time when using Visual Studio.
1. Hover mouse to evaluate expression
2. Change values on-the-fly
3. Set next statement
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
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.
5. A convenient watch window
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.
No comments:
Post a Comment