Back to Basics: Mastering Visual Studio Breakpoints
Join the DZone community and get the full member experience.Join For Free
i know what you’re thinking right now. breakpoints? seriously? what’s there to master about breakpoints? you hit f9 and then you stop at the line of code. if that’s what you’re thinking, this post is for you: read on
visual studio offers a fairly rich set of breakpoint types and actions that can make your debugging experience more comfortable and productive. we will look at four kinds of breakpoints in this post.
conditional breakpoints when defining a breakpoint, you can associate it with a condition (right-click the breakpoint and choose when hit). in the condition you can use virtually any c# statement that you can evaluate in the immediate window, including complex expressions. the debugger will then evaluate the expression every time the breakpoint is reached, and will break only if it evaluates to true.
note that even though the breakpoint may only break infrequently, it still slows down the application because the debugger has to evaluate the expression when the application is paused before resuming it.
tracepoints breakpoints don’t have to break your application’s execution. in many cases, you just need to inspect the current value of some variable or expression and continue execution straight away. this doesn’t require changing the code to include trace statements: you can simply associate the breakpoint with a trace action that will display whatever message you’d like to the visual studio output window. again, you can display complex expressions.
function breakpoints you can set a breakpoint in a function even if you don’t have its source code. simply go to debug > new breakpoint > break at function and specify the function name.
this is also available from the call stack window – simply click a frame and hit f9 to place a breakpoint on that function.
data breakpoints (c++ only) you can use data breakpoints to stop the debugger when a particular memory location is modified. this super-powerful feature is very useful for multi-threaded applications and miscellaneous memory corruption scenarios, where a memory location is modified in an unexpected way. unlike a source breakpoint, you don’t place the breakpoint on a line of code. instead, you specify a memory location by using the debug > new breakpoint > new data breakpoint menu item.
unfortunately, this feature works only for c/c++ applications. managed objects move around the heap when they are promoted between generations or when heap compaction occurs, making them impossible to track.
as you have seen, by combining conditional breakpoints and tracepoints, you can obtain a trace of your application’s execution without adding any trace statements to your code or restarting your debugging session. by adding function breakpoints and data breakpoints, you can further improve the flexibility of your debugging work. enjoy your visual studio breakpoints!
i am posting short links and updates on twitter as well as on this blog. you can follow me:
Published at DZone with permission of Sasha Goldshtein, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.