VS 2005+

Breakpoints and Tracepoints in Visual Studio

by Richard Carr, published at http://www.blackwasp.co.uk/VSBreakpoints.aspx

When debugging program code it is important to be able to pause the code at a specific location. Using Visual Studio breakpoints and tracepoints, the code can be halted at a desired line or can output trace information when conditions are met.

Conditional Breakpoints

A conditional breakpoint only halts execution when a condition is met. The condition can be specified using the Breakpoint Condition dialog box. This dialog box is displayed when you right-click a breakpoint and select "Condition..."

To enable a condition, the Condition checkbox must be ticked. A condition expression may then be entered into the textbox. Two types of condition are permitted. An "Is true" condition specifies that the expression in the textbox must be met in order for execution to be paused. If, when the code reaches the breakpoint, the condition does not evaluate as "true", the code will continue as normal.

A second type of condition is the "Has changed" expression. In this case, when the breakpoint is hit, the value of the expression in the textbox is compared with the value of the expression on the previous occasion that the breakpoint was encountered. Only if the value has changed is execution paused.

To demonstrate conditional breakpoints, change the condition of the previously set breakpoint to "i==10" and use the "Is true" option. On returning to the code, the breakpoint glyph will have changed to indicate that a condition is present. When you run the program you will see that the code enters break mode only once, just before outputting the multiplication table for the number ten.

NB: Be careful when using an equality test to use two equals signs (==), not one (=). As the expression in the breakpoint is executed, using the latter will change the value of i for each run, causing an infinite loop.

Setting a Hit Count

All breakpoints maintain a hit count during execution in debug mode. This count starts at zero and is incremented each time the breakpoint is encountered. In some situations, it is useful to prevent the breakpoint from pausing the program every time it is hit. By using the Breakpoint Hit Count dialog box, you can modify the behaviour of the breakpoint according to the current hit count. To show this dialog box, select "Hit Count..." from the breakpoint's context-sensitive menu.

Four options are available:

• break always. The default setting causes the breakpoint to pause the code every time it is hit.
• break when the hit count is equal to. Using this option, you can specify that the breakpoint will activate only once, when the hit count reaches the value you specify in the textbox.
• break when the hit count is a multiple of. If you wish the breakpoint to be activated periodically, you can use this option. In the figure below, the breakpoint is set to halt execution on every fifth hit.
• break when the hit count is greater than or equal to. The final option indicates that the breakpoint will be ignored until the hit count reaches a specified value. Once this number has been reached, the breakpoint will halt execution on every subsequent hit.

NB: If you specify both hit count and condition options, both conditions must be met simultaneously for the breakpoint to be active.

Breakpoint Filters

Filters provide an additional level of control over breakpoints. With a filter applied, you can specify that a breakpoint is only active for a specific machine, process or thread. This is particularly useful if you are executing your program several times simultaneously, each with a different process ID, and you wish to debug only one instance.

The Breakpoint Filter dialog box is accessed by selecting "Filter..." from the breakpoint's context-sensitive menu. The filter is specified in the textbox as a series of equality comparisons, joined using AND and OR operators.

NB: Unlike with conditions, the expression uses a single equals sign (=) for an equality test.