When we debug a C# program we typically tell Visual Studio where it should pause so we can take a closer look. One way to communicate that is with a breakpoint. What are ‘breakpoints’ and how do we use them in Visual Studio? Let"s find out.

# Fix code: debugging with Visual Studio"s breakpoints

When we program C# applications, at some point we run into unexpected problems. With small programs looking over the code is often enough to find the possible problem. But that approach doesn"t work with complex programs. Luckily there"s a good alternative.

Debugging is the process in which we identify and remove errors from our application (Asad & Ali, 2017). To make that process easier we often use special debugging tools to help understand and analyse our code.

To use those kinds of debugging tools we first have to start our program under a debugger. We do that in Visual Studio with F5 (‘Start Debugging’; ), F11 (‘Step Into’; ), or the ‘Run To Cursor’ option.

An effective way to debug C# code is to pause our program just before the code that might be buggy. But how do we communicate that to Visual Studio? For that we use a breakpoint.

A breakpoint marks a line of code where we want to pause our program (Asad & Ali, 2017; Price, 2017). Then when we run our code under the debugger, Visual Studio stops (also called ‘breaks’) our program when it reaches the breakpoint (Stephens, 2014).

This way we use breakpoints to mark the line where we want the program to pause. Once it halts there, we can use Visual Studio"s other debugging tools to explore the program. Let"s see how breakpoints work.

# Place debugging breakpoints in Visual Studio

There are several ways to place breakpoints in Visual Studio.

The first approach is a left-click in the code editor"s margin at the level of a particular line. After that click a red dot appears in the margin and the entire line is red to highlight there"s a breakpoint on it:

Another option is to first place the text cursor on a line. Then press F9 or go to the ‘Debug’ menu item and select ‘Toggle Breakpoint’:

# Where to place Visual Studio breakpoints to debug C# code?

When the debugger executes our program and comes across a breakpoint, it stops program execution just before the statement with a breakpoint on it executes (Liberty & MacDonald, 2009). In other words, when a breakpoint makes our program pause under the debugger, the actual line with the breakpoint on it hasn"t executed yet.

And so with a breakpoint we tell Visual Studio: “just before you run this line of code, pause the program so we can inspect it”. The typical location of breakpoints is therefore just before the code area we"re interested in.

But that also means the following. For our breakpoint to hit and make Visual Studio pause our program there, the line with the breakpoint on it does needs to execute. It"s a common mistake to place the breakpoint on a line that never executes. That way our program will also never pause there.

To see where we might place breakpoints, let"s look at an example. The nested if statement below has an issue: its Console.WriteLine() method never executes.

This code has a couple lines where we can place a breakpoint. The first option is to place one on the nested if statement:

With this breakpoint our program enters debugging mode just when it"s about to execute the nested if statement. That way we can inspect the if statement"s condition, and get an idea why its code doesn"t execute.

But when the top if statement evaluates to false, the nested if statement doesn"t run. And with that our breakpoint won"t get hit, meaning our program will not pause under the debugger there.

That"s why a better option would be to place a breakpoint on the if statement itself:

This way our program pauses just when it"s about to evaluate the if statement. With no code directly above it that prevents this if statement from executing, we"re sure that this breakpoint hits when our program runs under the debugger.

But we should not place the breakpoint inside the nested if statement:

The problem with our example code is that the Console.WriteLine() line doesn"t run. Since our program doesn"t execute that line, a breakpoint on it will neither register and get our program into debugging mode.

This shows why we typically place breakpoints just before the likely faulty code.

# Start debugging after placing Visual Studio breakpoints

After we place breakpoints we have to start our program under the debugger. We do that with a click on the ‘Start Debugging’ (F5) icon ( ) in the ‘Debug’ toolbar. Or we click on the ‘Debug’ menu item and select ‘Start Debugging’:

Now our program runs until it comes across the first breakpoint (it can pause sooner when it runs into an unhandled exception).

When a breakpoint ‘hits’ and makes our program pause under the debugger, that looks like:

When a breakpoint ‘hits’, Visual Studio highlights the line it"s about to execute with yellow and places an arrow in the right margin (Liberty & MacDonald, 2009; Price, 2017).

At this point we can explore the state of the program just before it runs that line. That means we can check what values variables have, what expressions evaluate to, which content collections hold, and what the structure of objects is. Typical debugging tools we use for that are Visual Studio"s ‘Watch’ window and the small tooltips windows.

# Disable and enable C# breakpoints in Visual Studio

Once we found the possible bug and changed our code, we likely want to test our program without running into the same breakpoint again. For that we best disable the breakpoint and not remove it. That way we can re-enable it later on if the bug still happens.

To temporarily disable a breakpoint, place the text cursor on the line with breakpoint and press Ctrl + F9. Or right-click on the red dot in the code editor"s margin and choose ‘Disable Breakpoint’:

To turn off all breakpoints in your program for now, click on the ‘Debug’ menu item and choose ‘Disable All Breakpoints’:

A disabled breakpoint looks as follows. Its red dot in the left margin becomes a red circle. And the line of code doesn"t have a red background but instead a red border:

Once a breakpoint is disabled, we can run our program under the debugger and it will not pause at that line. If we later do want to jump into debugging mode at that line, we have two ways to re-enable breakpoints.

To turn all disabled breakpoints back on we click on the ‘Enable All Breakpoints’ option in the ‘Debug’ menu:

We can also re-enable specific breakpoints. For that we place the text cursor on the line and press Ctrl + F9. Or we click on the red circle in the left margin – just as we do when we first placed the breakpoint:

# Remove breakpoints in Visual Studio

Once we find and fix the programming bug we can remove the breakpoint. That way the debugger will not break at that location anymore. There are two ways to remove breakpoints in Visual Studio: remove all of them or a single one.

To remove all breakpoints from your Visual Studio project, press Ctrl + Shift + F9 or go to the ‘Debug’ menu item and choose ‘Delete All Breakpoints’:

To remove a single breakpoint, move the mouse cursor to the red dot in the code editor that highlights the breakpoint:

A click on that red dot removes the breakpoint from that line:

Or we place the text cursor on the line with breakpoint and press F9 to remove it. The same happens when we go to the ‘Debug’ menu and choose ‘Toggle Breakpoint’:

# Summary

Running our C# application under a debugger is an efficient way to fix code. To start debugging in Visual Studio we press F5 (‘Start Debugging’; , hit the F11 key (‘Step Into’; ), or use the ‘Run To Cursor’ option.

When the debugger runs our program, it initially only pauses when an unhandled exception happens. But we can also have it pause at specific points. We do that with breakpoints. When we place a breakpoint on a line of code, the debugger will pause there just before it executes that line of code. This way we mark lines where we want to explore our program further.

That also means a breakpoint only pauses our program when the line of code it"s on actually executes. If we place a breakpoint on a line of code that doesn"t run (like an if statement whose condition is false), then the breakpoint won"t trigger and our program doesn"t pause there.

After we place breakpoints we can temporarily disable them. That way we can run the program without pausing there. Later we can re-enable breakpoints if we want to analyse our code further, or remove them when the bug is fixed.

« All C# visual studio articles