BlackWaspTM

This web site uses cookies. By using the site you accept the cookie policy.This message is for compliance with the UK ICO law.

Debugging
VS 2005+

Linking Breakpoints in Visual Studio

Breakpoints are useful tools for debugging code. They allow the code to be halted at a specific position so that variables can be examined. Visual Studio does not provide a way to make one breakpoint dependent upon another but this is possible.

Breakpoints and Tracepoints

Breakpoints and tracepoints are very helpful tools that you can use when you need to debug your code. When a breakpoint is encountered whilst running a program in the debugger, the program halts. You can then examine the current state of the program and step through the code line by line to identify potential issues.

A tracepoint is a variation upon a breakpoint. Although it can be configured to halt the program when encountered, it is more commonly used to print a message to the Output window without interrupting execution. In early versions of Visual Studio you could also use a tracepoint to execute a macro. Unfortunately, macro features have been removed from later Visual Studio releases.

Breakpoints and tracepoints can be configured to operate only when a condition is true. For example, you might expect that a particular variable should always be within a specific range of values. You could create a breakpoint that only interrupts the program when this is not true.

Sometimes you will want one breakpoint to be active only if another has already been encountered. At first glance, it does not seem possible to achieve this. However, you can use a side effect of tracepoints to link breakpoints in this manner.

Linking Breakpoints

To allow one breakpoint to be dependent upon another having already been encountered, you need to record when the first breakpoint is hit. You can do this using a side effect of the message output of a tracepoint. When printing a message to the Output window, you can include the values of variables or the results of expressions. By using an expression that sets a value, you can record that a tracepoint was reached. In a later breakpoint you can use a condition that checks the recorded value and, optionally, resets it.

To demonstrate, we need a sample project. Create a new console application in Visual Studio, naming the new solution, "LinkedBreakpointDemo". Add the following code to the Main method of the automatically generated class.

Console.WriteLine("Skip breakpoint 1?");
if (Console.ReadKey(true).Key == ConsoleKey.N)
{
    Console.WriteLine("Breakpoint 1 hit!");
}
Console.WriteLine("Breakpoint 2 hit!");

With the code in place, add a breakpoint on the fourth and sixth lines, these being the second and third calls to Console.WriteLine. We'll update these breakpoints so that the second halts the code only if the first has been encountered.

We'll need somewhere to store that the first breakpoint was hit. Add a new class named, "BreakpointData". Make this a static class and add a Boolean, static property that we'll use as a flag. The class should appear as follows:

public static class BreakpointData
{
    public static bool Breakpoint2Active = false;
}

Configuring the Breakpoints

Let's now configure the breakpoints. Firstly, we'll convert the first breakpoint into a tracepoint that sets the Breakpoint2Active flag to true when it is reached. Right-click the breakpoint glyph in the margin of the code window and choose "When Hit..." from the context-sensitive menu that appears. Add the following to the "Print a Message" text box. The brace characters, {}, indicate that this is an expression that should be evaluated. The expression sets the flag to true. It will also output the result of this operation to the Output window when the tracepoint is hit.

{LinkedBreakpointDemo.BreakpointData.Breakpoint2Active=true}

Before closing the dialog box, ensure that the "Continue Execution" checkbox is ticked. This will stop the first breakpoint from causing execution to halt.

The second breakpoint will be configured to stop the code if the first breakpoint was encountered and the static flag was set. You can configure this using a standard breakpoint condition. Right-click the second breakpoint and choose the "Condition..." option. Set the condition to read the Breakpoint2Active flag, as shown below. Make sure that the "Is true" radio button is selected.

LinkedBreakpointDemo.BreakpointData.Breakpoint2Active

Once you have made the changes, the code window should appear similar to the image below. The exact output is dependent upon the version of Visual Studio in use:

Linked breakpoints

Testing the Breakpoints

You can now try the linked breakpoints. Run the program in the debugger and press the "Y" key to indicate that the first breakpoint should be skipped. This will prevent the flag from being set to true, so the second breakpoint will not affect execution. Run the program again, this time pressing "N". The flag will be set by the tracepoint and the breakpoint will halt the program.

5 December 2013