The Art of Debugging – A Developer’s Best Friend – Lesson 3 – BreakPoint HitCount - Repost

 

Lession 3 – Breakpoint Hit Count

Download the sample project – debugging.zip

This setting determines how the breakpoint should behave when it is hit. You can choose to:

Break always, regardless of hit count. This is the default option. This option has the least effect on program performance, since the debugger does not actually bother to compare the values.

Break when the hit count is equal to the counter.

Break when the hit count is a multiple of the counter. Like “Modulo.”

Break when the hit count is greater than or equal to the counter.

The loop below will now break when “i” is equal to 0, 3, 6, 9.

Notice we have a breakpoint defined and that the intellisense explains the breakpoint.

Note that we hit our breakpoint.

Note that the “Breakpoints” window can tell you the current state.

If your computer is crashing…

You can set the “hit count” to a very large number and when your software crashes you can see the loop count to get an idea where your software is crashing.

Conditional Breakpoints

You can specify a breakpoint condition which will be evaluated when a breakpoint is reached. The debugger will break only if the condition is satisfied.

To specify a breakpoint condition

In the Breakpoints window, right-click the line containing a breakpoint glyph and choose Condition from the shortcut menu

In a source, Disassembly, or Call Stack, right-click a line containing a breakpoint glyph and choose Condition from Breakpoints in the shortcut menu.

In the Breakpoint Condition dialog box, enter a valid expression in the Condition box.

Choose is true if you want to break when the expression is satisfied or has changed if you want to break when the value of the expression has changed.

Click OK.

“Has Changed” means it will break if i changes.

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.

Unselecting the “Condition Checkbox” allows you to return back to an regular, “unconditional” breakpoint.

Note: You can combine a “Hit Count” and “Conditional” breakpoint at the same time.

Using methods for conditional breakpoints

We will use the AssertExample class when doing “Conditional Breakpoints”

Now run the code. Essentially, we will hit the breakpoint when CheckName()returns the value of true. Also notice that intellisense is working.

From the menu select Debug, Start Debugging. Here you can see that the debugger stopped only on the second breakpoint because we tried to assign null to the name property. Being able to call functions from the conditional breakpoint window can be very useful as you have seen in this example. Essentially, this feature allows you to directly program the debugger and can be used in complex debugging scenarios.

Debugging in a multithreaded environment is very difficult. The same challenge exists on multi-CPU Machines as well.

Conditional breakpoints are for breaking at the expression level, when a particular condition is true, like x=5. But what if you have multiple instances of the same app running? How do you set to break the instance you want?

Filter breakpoints need to be enabled on the tools menu. Go to Tools – Options – Debugging – General, and there you’ll see the option to enable breakpoint filters.