When a program behaves unexpectedly, reading the source code is useful.
Sometimes it is not enough.
The debugger lets you pause a running program and inspect what the program knows at that moment.
In this course, you will begin with a simple workflow:
Set a breakpoint → Start debugging → Reach the breakpoint → Inspect the current state
The goal is not to change everything while the program is paused.
The goal is to gather evidence.
A breakpoint tells Visual Studio:
When execution reaches this statement, pause before continuing.
Imagine a supplied soccer program contains:
Player player1 = new Player();
player1.name = "Jordan";
player1.jerseyNumber = 7;
If you want to observe player1 after the object has been created and some values have been assigned, place the breakpoint at a statement that occurs after those assignments.
The location matters.
If the program pauses before:
Player player1 = new Player();
then the object has not yet been created by that statement.
If it pauses later, the program may already have changed the object.
A breakpoint lets you choose the moment you want to observe.
With the breakpoint set, start the supplied application using Visual Studio's normal debugging command.
The program runs until one of several things happens:
When the breakpoint is reached, Visual Studio highlights the current statement and pauses the program.
The program is not finished.
It is temporarily stopped so you can inspect its state.
While the program is paused, debugger windows can show values that are currently available.
Depending on where the program is paused, you may see:
For the soccer example, you might be able to inspect a Player object and see values such as:
name = "Jordan"jerseyNumber = 7The important question is not merely:
What values are visible?
Ask:
Do these values match what I expected at this point in the program?
That comparison turns debugger output into evidence.
This source:
Player player1 = new Player();
player1.name = "Jordan";
shows instructions.
A paused debugger view shows the result of instructions that have already executed.
Before the assignment:
player1.name may not yet contain "Jordan".
After the assignment:
it should.
The debugger helps you connect source instructions with runtime state.
Suppose you expect:
jerseyNumber = 7
but the debugger shows:
jerseyNumber = 17
That observation gives you a specific difference to investigate.
You can return to the code that assigns the value and ask:
You do not need to guess that “the program is broken.”
You have evidence about one particular state difference.
When the debugger reveals an unexpected value:
This creates a repeatable technical process.
A breakpoint only pauses execution.
It does not correct code.
Debugger windows only show current information.
They do not decide what the correct value should be.
The specification tells you what is required.
The source code tells you what instructions were written.
The debugger shows what happened while those instructions ran.
Strong debugging uses all three.
At this stage, you do not need advanced debugger commands.
Become comfortable with one useful observation cycle:
Later activities will add stepping commands and more specialized debugger windows.
For now, learn to pause deliberately and look at what the program actually knows.