Writing the code is half the job. Figuring out why it isn't doing what you told it to is the other half — and debugging is the skill that gets you there fast.

Your program compiles. It runs. And the total on screen is wrong by exactly one cent, or a customer's order shows up twice, or the app just... stops, silently, three screens into a flow that used to work fine. There's no red squiggly line to click on. The compiler already agreed this code was valid. Now what?

Every developer, from their first week to their thirtieth year, hits this moment. The instinct is to stare at the code and re-read it, hoping the bug jumps out. Sometimes it does. Usually it doesn't — because if you could see the bug just by reading, you wouldn't have written it in the first place. What you need is a way to watch the program think: to pause it mid-execution, look at what every variable actually holds at that exact moment, and walk forward one line at a time until reality stops matching your expectations.

That's debugging. It isn't a consolation skill for when you're "not good enough" to write bug-free code — nobody writes bug-free code. Debugging is a core engineering skill, arguably the one that separates developers who ship working software from those who don't. In this lesson you'll learn how a debugger actually works, the small set of moves (breakpoints, stepping, watching) that cover 95% of real debugging sessions, and the habits that keep you fast when something breaks.

What Is It?

The Simple Explanation

Debugging is the process of finding out why a program isn't behaving the way you expect, and then fixing it. A debugger is the tool that makes this possible: it lets you freeze your running program at a specific line, inspect the exact value of every variable at that instant, and then move forward one statement — or one method call — at a time.

The Technical Definition

In .NET, debugging is handled by the CLR's debugging APIs together with an IDE (Visual Studio, Visual Studio Code, Rider, etc.) acting as the front end. The core tools you'll use constantly are:

• Breakpoints — a marker on a specific line telling the debugger "pause execution here, before this line runs."
• Stepping — moving execution forward one line, one method call, or out of the current method, while the program stays paused.
• The Locals window — shows every variable currently in scope and its live value.
• The Watch window — lets you pin specific variables or expressions you care about, so you don't have to hunt for them in Locals every time.
• The Call Stack window — shows the chain of method calls that got you to where you currently are paused.
• Conditional breakpoints — a breakpoint that only pauses execution when a condition you specify is true (e.g., only when orderId == 4471).

Together, these tools let you replace guessing with observation. Instead of asking "what do I think this variable is?", you ask the debugger and it tells you exactly.

Why Does It Exist?

The Problem — "Print Debugging" Doesn't Scale

Before debuggers were convenient, and still today when people reach for the fastest tool at hand, the go-to technique is sprinkling Console.WriteLine calls everywhere:

decimal CalculateTotal(List<decimal> prices, decimal taxRate)
{
    Console.WriteLine("entered CalculateTotal");
    decimal subtotal = 0;
    foreach (var price in prices)
    {
        Console.WriteLine($"price = {price}");
        subtotal += price;
    }
    Console.WriteLine($"subtotal = {subtotal}");
    decimal total = subtotal + (subtotal * taxRate);
    Console.WriteLine($"total = {total}");
    return total;
}

This works, technically — but it has real costs:

• You have to guess in advance which variables might be interesting, edit the code to print them, and re-run.
• If the bug isn't where you guessed, you edit again, and re-run again — a slow loop.
• You can only see values as text; you can't inspect a complex object's full state without writing a print statement for every field.
• It's easy to forget a Console.WriteLine and accidentally ship it, or leave dead code cluttering the method.
• In a loop that runs 10,000 times, you get 10,000 lines of noise when you only cared about iteration #4,471.

The Solution — Pause and Inspect, Instead of Predict and Print

A debugger flips the process around. Instead of deciding in advance what to print, you pause the program at the moment you're unsure about, and then look at everything — every local variable, every field, every object graph — with no code changes and no guessing about what to log. You can change your mind mid-session and inspect something you didn't expect to need, for free.

Big Picture

Here's the shape of a typical debugging session, from "something's wrong" to "fixed and verified":

Almost every bug you'll ever chase down follows this loop: hypothesize where the wrongness starts, pause there, and use stepping to squeeze the gap between "still correct" and "already wrong" until it's a single line.

How It Works

1. Setting a breakpoint

Click in the left margin next to a line number (or press F9 with the cursor on that line). A red dot appears. This tells the debugger: "when execution is about to run this line, pause and hand control back to the developer."

2. Starting a debug session

Instead of just running the program, you start it under the debugger (F5 in most IDEs). The program runs completely normally — same speed, same behavior — right up until it reaches a line with a breakpoint on it. Then it freezes, mid-statement, with every variable exactly as it was.

3. Stepping — the three moves

Once paused, you have three ways to move forward, and picking the right one is most of the skill:

4. Inspecting state — Locals, Watch, and hover

While paused, hover your mouse over any variable in the editor and its current value pops up. The Locals window lists every variable in scope automatically. The Watch window lets you type in a specific variable or even an expression (like subtotal * taxRate) and keep it pinned across every pause, so you don't have to search for it each time.

5. Conditional breakpoints — for loops and rare cases

Right-click a breakpoint and add a condition, and it will only stop when that condition is true. This is essential when a bug only shows up on, say, the 4,471st item in a loop of 10,000 — without it, you'd have to hit "Continue" four thousand times.

foreach (var order in orders)          // breakpoint here, condition:
{                                        //   order.Id == 4471
    ProcessOrder(order);
}

With that condition set, the debugger silently runs through every other iteration at full speed and only pauses on the exact one you care about.

6. The Call Stack window

While paused, the Call Stack window shows the chain of method calls that led here — Main() called ProcessOrder(), which called CalculateTotal(), which is where you're currently stopped. You can click any frame in that list to inspect the local variables of that caller too, which is invaluable for understanding how execution got to this point, not just what it looks like right now.

Simple Example

Here's a small method with a real bug — a classic off-by-one mistake — worked through the way a debugging session would go.

static decimal AverageOfFirstThree(List<decimal> values)
{
    decimal sum = 0;
    for (int i = 0; i <= 3; i++)        //  breakpoint set on this line
    {
        sum += values[i];
    }
    return sum / 3;
}

// Called with:
var prices = new List<decimal> { 10m, 20m, 30m };
Console.WriteLine(AverageOfFirstThree(prices)); // throws instead of printing 20

What a debugging session looks like here:

• Set a breakpoint on the for line. Run. It pauses before the loop starts — i doesn't exist yet, sum is 0.
• Step over repeatedly (F10). Each pass, check i and sum in the Watch window: i=0, sum=10, then i=1, sum=30, then i=2, sum=60.
• One more step over — and the line sum += values[i] throws an IndexOutOfRangeException before you even reach return.
• The debugger stops exactly there, with i = 3 visible in Locals, and values only has indices 0, 1, 2. The condition i <= 3 should have been i < 3.

Notice what happened: you didn't have to guess that i would reach 3. The debugger showed you the exact value at the exact moment things went wrong — no print statements needed, no re-running with extra logging.

Real-World Example

Imagine a small order-processing system where a Customer can have a Discount applied, and the final total is coming out higher than it should for certain customers:

public class Customer
{
    public string Name { get; set; } = "";
    public decimal DiscountPercent { get; set; } // e.g. 10 means 10%
}

public class OrderProcessor
{
    public decimal CalculateFinalTotal(decimal subtotal, Customer customer)
    {
        decimal discountAmount = subtotal * customer.DiscountPercent;   //  breakpoint
        decimal total = subtotal - discountAmount;
        return total;
    }
}

A customer with a 10% discount ends up with a negative total on a $50 order. Rather than staring at the formula, a developer would:

1. Put a breakpoint on the discountAmount line and re-run the failing scenario.
2. When it pauses, check customer.DiscountPercent in Locals — it shows 10, not 0.10.
3. Step over and watch discountAmount get set to 500 (50 × 10) — five hundred dollars off a fifty dollar order.
4. The bug is now obvious: DiscountPercent is stored as a whole number (10 meaning 10%) but the formula treats it as a fraction (0.10). The fix is subtotal * (customer.DiscountPercent / 100).

This is a perfect example of a bug that's nearly invisible by reading the code — the formula looks reasonable — but becomes obvious the instant you can see the actual number flowing through it.

Analogy

Common Confusion

1. "Step Over" vs "Step Into" — which method gets skipped?

Both keep you on the same line's method call, but Step Over treats that call as a black box (it runs to completion and you land on the next line), while Step Into follows execution inside it. A good rule of thumb: Step Over methods you already trust (like framework calls, or code you've already verified); Step Into the one method you actually suspect is broken.

2. Debug build vs Release build

Debugging works best against a Debug build (the default when you press F5 in an IDE). A Release build is compiler-optimized: the JIT may reorder statements, inline small methods, or eliminate variables entirely — which means breakpoints can land in unexpected places or a variable you want to inspect might not even exist anymore in the compiled code. Always debug against Debug configuration unless you're specifically diagnosing a Release-only issue.

3. A breakpoint is not the same as "break on exception"

A normal breakpoint pauses at a line you chose in advance. Most IDEs also let you configure the debugger to automatically pause the instant any exception is thrown, anywhere in your code — even one you'd normally never think to put a breakpoint near. This is invaluable when you don't yet know where the problem originates; it takes you straight to the throwing line instead of making you guess where to look first.

Common Mistakes

Mistake 1 — Stepping into everything, including framework code

Hitting F11 on every single line, including calls into List<T> or Console.WriteLine, wastes time wandering through code you didn't write and don't need to see.

Reserve Step Into for the one method you actually suspect. Use Step Over for everything you trust.

Mistake 2 — Debugging without a hypothesis

Setting a breakpoint at the very top of Main and stepping through the entire program line by line, hoping to notice something.

Form a guess first — "I think the problem starts around the discount calculation" — and put the breakpoint as close to that guess as possible. It's far faster to be wrong and adjust than to step through everything blindly.

Mistake 3 — Forgetting a breakpoint is still there

Leaving a breakpoint set in a hot loop, then wondering why the app "hangs" the next time you debug something unrelated — it's just paused, waiting.

Clear breakpoints you're done with (Ctrl+Shift+F9 in most IDEs clears all of them at once).

Mistake 4 — Not using conditional breakpoints in loops

Setting a plain breakpoint inside a loop over 10,000 items, then clicking "Continue" hundreds of times to reach the one iteration that fails.

Right-click the breakpoint, add a condition matching the specific case (e.g., item.Id == 4471), and let the debugger skip straight to it.

Mistake 5 — Giving up and going back to print statements too early

After one confusing pause, abandoning the debugger and littering the method with Console.WriteLine calls instead.

Print debugging has its place for quick sanity checks in throwaway scripts, but for anything with real logic, the debugger will almost always get you to the answer faster once you're comfortable with stepping and watches.

When Should I Use It?

Reach for the debugger when:

• Output is wrong in a way you can't explain just by reading the code.
• You need to inspect a complex object graph (nested objects, collections) at a specific moment.
• An exception is being thrown somewhere in a call chain and you need to find exactly where and why.
• You're learning someone else's code and want to watch it actually execute, not just read it.

A debugger may be the wrong tool when:

• The bug only happens in production, under real load, and can't be reproduced locally — that's a job for logging and monitoring, not a live debugger.
• Timing-sensitive bugs (race conditions across threads) can behave differently — or vanish — the instant you pause execution, since pausing changes the timing itself.
• You just need a one-off sanity check on a tiny script — a quick print statement can be faster than setting up a debug session.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how breakpoints, stepping, and watches turn guesswork into observation. Let's check that it stuck.

You now know how to turn "I have no idea why this is broken" into a fast, methodical investigation — the debugger is officially part of your toolkit.

dotnetmadeeasy.com — Learn C# and .NET, the right way.