Debug C# programming code with Visual Studio"s breakpoints

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.

IN THIS ARTICLE:

  • Fix code: debugging with Visual Studio"s breakpoints
  • Place debugging breakpoints in Visual Studio
    • Where to place Visual Studio breakpoints to debug C# code?
  • Start debugging after placing Visual Studio breakpoints
  • Disable and enable C# breakpoints in Visual Studio
  • Remove breakpoints in Visual Studio
  • Summary
# 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’; Start debugging iconStart debugging icon), F11 (‘Step Into’; Step Into iconStep Into icon), 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:

Placed a breakpoint on C# code in Visual StudioPlaced a breakpoint on C# code in Visual Studio

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’:

Toggle a Visual Studio breakpointToggle a Visual Studio 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.

When a breakpoint is on code that doesn"t execute, our program will not pause under the debugger there. And so often we place the breakpoint just before the line where we think the problem lays.

Then when the program breaks there, we inspect the program"s state leading up to the problem and then step into the suspicious code.

We typically don"t place a breakpoint many lines before the problem area, since that means we"ll have to step through a lot of code. Neither do we often place the breakpoint on the suspected problem code. That"s because if the error comes from that code not executing, our breakpoint doesn"t get hit.

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.

string authorName = "John Smith"; int booksWritten = 2; double royaltyAmount = 0.15; bool underContract = false; if (!underContract) { if (booksWritten > 1 && royaltyAmount >= 15) { Console.WriteLine("Seems to have potential. Let's reach out to {0}\n", authorName); } }

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

Place a Visual Studio breakpoint on a nested if statementPlace a Visual Studio breakpoint on a 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:

Placing a C# breakpoint on an if statementPlacing a C# breakpoint on an if statement

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:

Putting a Visual Studio breakpoint inside a nested if statementPutting a Visual Studio breakpoint inside a 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 ( Start debugging iconStart debugging icon) in the ‘Debug’ toolbar. Or we click on the ‘Debug’ menu item and select ‘Start Debugging’:

Start debugging in Visual StudioStart debugging in Visual Studio

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:

C# application paused under Visual StudioC# application paused under Visual Studio

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’:

Disable a breakpoint in Visual StudioDisable a breakpoint in Visual Studio

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

Disable all breakpoints in Visual StudioDisable all breakpoints in Visual Studio

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:

Disabled C# breakpoint in Visual StudioDisabled C# breakpoint in Visual Studio

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:

Turn all Visual Studio breakpoints back onTurn all Visual Studio breakpoints back on

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:

Re-enable a specific breakpoint in Visual StudioRe-enable a specific breakpoint in Visual Studio

While we can enable and disable breakpoints like we discussed above, another option is ‘Start Without Debugging’ (Ctrl + F5).

When we run a program from within Visual Studio without debugging, it doesn"t pause at any breakpoint. That way we can immediately see if our code changes fixed the problem without having to toggle individual breakpoints off first.

Start a C# application in Visual Studio without debuggingStart a C# application in Visual Studio without debugging# 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’:

Delete all C# breakpoints in Visual StudioDelete all C# breakpoints in Visual Studio

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

Select a breakpoint in Visual StudioSelect a breakpoint in Visual Studio

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

Remove a single breakpoint in Visual StudioRemove a single breakpoint in Visual Studio

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’:

Enable or disable Visual Studio breakpoints with Enable or disable Visual Studio breakpoints with # 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’; Start debugging iconStart debugging icon, hit the F11 key (‘Step Into’; Step Into iconStep Into icon), 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.

References

Asad, A. & Ali, H. (2017). The C# Programmer"s Study Guide (MCSD). New York, NY: Apress.

Liberty, J. & MacDonald, B. (2009). Learning C# 3.0: Master the Fundamentals of C# 3.0. Sebastopol, CA: O"Reilly Media.

Price, M.J. (2017). C# 7.1 and .NET Core 2.0 - Modern Cross-Platform Development (3rd Edition). Birmingham, UK: Packt Publishing.

Stephens, R. (2014). C# 5.0 Programmer Reference. Indianapolis, IN: John Wiley & Sons.

Last updated on October 25, 2018 (published February 10, 2018).
# Related C# tutorials
  • Quickly debug expressions with Visual Studio"s ‘QuickWatch’

    When debugging C# code, it often helps to quickly see what some expression evaluates to. The ‘QuickWatch’ window helps us do that and more.

  • Quickly debug C# code with Visual Studio"s ‘Run To Cursor’ option

    Before we can analyse and debug our C# program in Visual Studio, we have to start debugging. A quick way to do that is with ‘Run To Cursor’.

  • How to start and stop debugging C# code in Visual Studio?

    Before we can fix our C# programming code in Visual Studio, we need to start and stop the debugger. Learn more about that in this article.

  • Step through C# code: run a program line by line in Visual Studio

    In Visual Studio we can analyse our C# program line by line. This tutorial explores stepping through a C# application under the code debugger.

  • Debug example: fix C# if statements in Visual Studio

    Knowing where to start is often half the debugging work. This tutorial looks at debugging C# if statements, including tips for quick troubleshooting.

« All C# visual studio articles

Related: Maybe you are interested (Free: cafelandsaigon)


Related: Maybe you are interested (Free: suribaby)


Related: Maybe you are interested (kistigris)


Related: Maybe you are interested (maithai)


Related: Maybe you are interested (hoangvominh)


Related: Maybe you are interested (3limited)


Related: Maybe you are interested (eletrônicos)


Address: 79E Vo Noo - Singapore - Email: info@dangtinraovatmienphi.us - Phone: 818.333.007 - Website: dangtinraovatmienphi.us
Copyright © 2007 - Noos. All rights reserved