Last updated on May 11, 2015
Sometimes your program doesn’t work the way you expect.
It compiles (builds) correctly. But when you run it, it crashes (stops running) or gives an unexpected result. When that happens, you can use the debugger to see what is happening inside your program while it’s running.
Ideally, you should never need to use it. But, the reality is that all programmers do.
By the way, it is possible to connect the debugger to things that are not in your Visual Studio solution. But that’s not the most common way to use it.
For this lesson, we’ll only go over how you’ll need to use it 99% of the time.
Get into debugging mode
Let’s say you have a problem in a program you’re writing, and you don’t know why it’s happening.
So, you open up your solution in Visual Studio.
The first thing you need to do is make sure you have the solution set to debug configuration. In the Visual Studio menu, set the configuration dropdown to “Debug”.
Setting the debugger’s breakpoint
Now, you need to go to the class, or function, where the problem is happening.
You don’t need to know exactly where the problem is – sometimes the bug is in a function that is called by a function that is called by another function (and so on). But, you can start by finding the first function that you know is being executed before the error happens.
In this lesson, I’m going to say that I only know the bug happens when we start the program. So, I’m going to go to the constructor function for the SuperAdventure class (the class behind the starting form of a Windows form application).
Now I need to set a “breakpoint”. A breakpoint is a place where you want to the program to temporarily stop running, so you can look at what is happening inside your program. When you run the program in debug mode, and it reaches this breakpoint, you’ll be taken to Visual Studio, so you can examine your variables and follow the rest of the code as it runs.
For this example, let’s say I’m not sure where the bug is. So, I’m going to set a breakpoint on the first line of code in the function (by the way, you cannot set a breakpoint on a blank line).
You set a breakpoint by left-clicking on the blue bar to the left of the line of code – where the red dot is in the picture.
If you want, you can set several breakpoints in your source code. Each time a breakpoint is reached, while running the program, you’ll return to Visual Studio.
Removing a breakpoint
If you want to remove a breakpoint, click on the little red circle. It will disappear, and you won’t have a breakpoint there anymore.
If you want to remove all the breakpoints you’ve set, click on the “Debug” menu option, and then select “Delete all breakpoints”.
Running your program with breakpoints
Now that you have your breakpoints set, and you are using the “debug” configuration, you can run your program. Press the “Start” button, or F5, and do whatever you need to do to get to repeat the bug.
When your program reaches a breakpoint, it will return to Visual Studio. You’ll see the line where the breakpoint was set. It will be highlighted in yellow.
Now you can investigate the variables, and try to discover what is causing the bug.
At the bottom of Visual Studio, you’ll see a section that lists all the locally available variables, with their current values.
Moving through your program
You can follow you program as it executes each line, by using the F10 and F11 keys.
F10 will move you to the next line within the current function. If that line calls another function, F10 does not move you into that function. This is called “step over”, since you do not go into the function being executed.
F11 will move you into the function that the line calls (if that line calls another function). This is called “step into”, since you are stepping into the function.
As you move through the program, you’ll see the variables change in the “locals” section at the bottom the Visual Studio.
When you want to stop looking at the source code, and just have the program run, press F5. The program will continue running until it reaches another breakpoint.
If you want to run the program without stopping at the breakpoints (but still keeping them in place, in case you need them later), click on the “Debug” menu option, select “Disable All Breakpoints”, and run your program. When you want the program to stop at the breakpoints, re-enable the breakpoints from the same menu.
Encountering an exception
Sometimes your program may “throw an exception”. This happens when it tries to do something impossible, such as divide a number by zero.
If you’re pressing F10 to move through the program, you’ll suddenly see that you don’t move to the next line, but somewhere else in the program. When that happens, you now know exactly which line the problem occurs on.
Now, you can stop running the program, delete the other breakpoints (if you want), set a breakpoint on the line before where the error happened, and rerun the program in debug mode.
When you get to your breakpoint, check the values of the variables you are using to see the problem. Then you can change your code to fix the problem.
Using the debugger is simple. Once you know how to use it, you’ll have x-ray vision into your program. With it, you’ll be able to find, and fix, bugs much faster.
If you’ve never used the debugger before, you might want to set a few breakpoints in one of your programs, and practice with it (before you really need to use it).