What are conditional breakpoints, hit counts, filters, tracepoints and data breakpoints, and when do you use each?

1. What the debugger does on every hit

 thread reaches the breakpoint address
         |
         v
 process suspends (ALL managed threads)
         |
         v
 debugger checks, in order:
   filter (machine / process / thread)  -- no match --> resume
   hit count                            -- not yet  --> count it, resume
   condition (evaluated IN your process)-- false    --> resume
         |
         v
   tracepoint action?  -- yes --> format message, write to Output
         |                         "continue execution" ticked? --> resume
         no
         v
   stop in the IDE

The important point: a false condition still costs a full suspend, an evaluation and a resume. The IDE doesn't show a pause, so it looks free, but it isn't.

2. Every breakpoint type, side by side

IDE support: Visual Studio has all of them. VS Code with C# Dev Kit has conditions, hit counts, logpoints and function breakpoints. Rider has conditions, hit counts, log messages, dependent breakpoints and its own field watchpoints.

3. Measuring the overhead

The exact numbers vary by machine, but the shape is consistent:

 loop of 1,000,000 iterations, simple body

 no breakpoint                 ~ milliseconds
 conditional breakpoint        ~ minutes   (one round trip per iteration)
 tracepoint on every hit       ~ minutes   (round trip + string formatting)
 in-code if (...) Debugger.Break()  ~ milliseconds until it fires

For hot code, the in-code check is the right tool. Add it temporarily and remove it before committing.

4. How data breakpoints work

 you: "Break when value changes" on order._status (from Locals or Watch)
         |
         v
 debugger finds the field's memory address in that object
         |
         v
 programs a CPU debug register (x64 has 4) to trap writes
         |
         v
 any code writes to that address --> CPU trap --> debugger stops
         |                              on the line AFTER the write
         v
 you read the call stack to see who wrote it

Consequences:

• Only a few at once, because there are only a handful of hardware debug registers, and each covers a small range of bytes.
• One object, not all instances. It watches the field in the object you picked, not the field on every Order.
• The GC moves objects. For .NET (Core 3.0 and later, including .NET 10) Visual Studio tracks the object as it moves. If the object is collected, the breakpoint is removed.
• Writes only. A write of the same value may still trigger it, depending on the debugger.
• It stops after the write, so look one line up and at the call stack.

5. Tracepoint messages

In Visual Studio, {expression} is evaluated in the current frame, and these keywords add context:

Output goes to the debugger's Output window (VS Code: Debug Console), not to your application's logs, so it is gone when the session ends.

6. Conditions are real code

A condition runs inside your process through function evaluation, with the same risks as the Watch window:

Keep conditions to plain comparisons of locals and simple properties.

7. Choosing the right tool

 Do you know WHICH input is bad?        --> condition: is true
 Do you know WHEN (iteration number)?   --> hit count
 Is only one thread or process relevant?--> filter
 Do you need values over time?          --> tracepoint (keep it short)
 Is the field corrupted by "someone"?   --> data breakpoint
 Is the line hit millions of times?     --> temporary if (...) Debugger.Break()
 Will you need this again in production?--> a structured log event in code

8. Concurrency and timing

Stopping changes a concurrent system: other threads stop too, locks are held longer, leases and timeouts expire, and message brokers redeliver. When a bug depends on timing, prefer tracepoints with $TID, data breakpoints (which only fire on the bad write), or logging with correlation ids. A filter on a thread id helps when one worker thread is the interesting one.

9. .NET 11 awareness

The breakpoint types are features of the IDEs, not of .NET itself. Expect improvements in Visual Studio, Rider and C# Dev Kit releases rather than in .NET 11.

10. Try it yourself

1. Run the code example under the debugger with no breakpoints and note the elapsed time.
2. Add a conditional breakpoint inside the loop, order.Number == "A-0750", and compare the time.
3. Replace it with if (order.Number == "A-0750") Debugger.Break(); and compare again.
4. Add a tracepoint {order.Number} {order.Amount} on $TID with "Continue code execution" ticked, and read the Output window.
5. Set a hit count of "is a multiple of 100".
6. Pause, find _status on one order in Locals, choose Break when value changes, continue, and read the call stack when it fires.

A loop to practise on:

using System.Diagnostics;

var orders = Enumerable.Range(1, 1_000)
    .Select(i => new Order($"A-{i:0000}", i * 1.5m))
    .ToList();

var sw = Stopwatch.StartNew();
decimal total = 0;
foreach (var order in orders)
{
    total += order.Amount;           // set conditional breakpoints and tracepoints here
    if (order.Amount > 1_000m)
    {
        order.MarkForReview();       // data breakpoint target: Order._status
    }
}

Console.WriteLine($"Total {total} in {sw.ElapsedMilliseconds} ms");

public sealed class Order(string number, decimal amount)
{
    private string _status = "New";
    public string Number { get; } = number;
    public decimal Amount { get; } = amount;
    public string Status => _status;
    public void MarkForReview() => _status = "Review";
}

Breakpoint settings to try (Visual Studio Conditions and Actions):

Condition (Is true):     order.Number == "A-0750"
Condition (When changed): total > 100000
Hit count:               is a multiple of 100
Filter:                  ThreadId = 1
Action (tracepoint):     {order.Number} amount {order.Amount} in $FUNCTION on $TID

The in-code alternative for a hot loop (remove before committing):

if (order.Number == "A-0750") Debugger.Break();