How do you use the Watch, Locals, Autos and Immediate windows to inspect and change state while debugging, and what are the risks of evaluating expressions?

1. Reading memory versus running code

Every value you see in a debugger window comes from one of two places:

 expression in Watch: customer.Orders
      |
      v
 is it a local, parameter or field?
      |
      +-- yes --> debugger READS MEMORY directly. No code runs. Safe.
      |
      no (property getter, method call, ToString, DebuggerDisplay,
      |   LINQ, indexer with logic)
      v
 FUNCTION EVALUATION:
   borrow one stopped thread
   run the code inside your paused process
   (every other thread stays frozen)
      |
      +-- finishes      --> show the value
      +-- takes too long --> abort, show "evaluation timed out"
      +-- throws        --> show the exception as the value

That distinction explains every risk in this question. A field read can't change anything. Function evaluation is your code running for real.

2. Each window and what drives it

A Watch expression is re-evaluated on every step, so a side-effecting Watch runs its side effect every time you press F10.

3. Format specifiers

Add them after a comma in Watch, QuickWatch or Immediate:

Useful pseudo-variables: $exception (the current exception), $ReturnValue (the value just returned), and Object IDs such as $1.

4. Make Object ID

Right-click a value and choose Make Object ID. The debugger keeps a weak handle to that specific object, named $1, $2 and so on.

 frame A: var order = Load("A-102");    --> Make Object ID --> $1
 frame B: Process(order)                --> watch $1.Status
 frame C: order is out of scope          --> $1.Status still works
 ...later, another variable 'x' looks the same
          ? object.ReferenceEquals(x, $1)  --> is it the SAME object?

It answers questions such as "is this the same instance or a copy?" and "what happened to this object after it left my method?". It doesn't keep the object alive; if it is collected, $1 shows that it is no longer available.

5. The three classic traps, step by step

Trap 1: a getter with a side effect.

 public IReadOnlyList<string> Numbers { get { _readCount++; return _numbers; } }

 Watch: batch.Numbers   --> _readCount++ on every step
 Your log later says "getter called 7 times" -- 5 of those were the debugger

Trap 2: lazy loading and IQueryable.

The bug you were chasing (an N+1 pattern, a missing Include, a tracking problem) can disappear or change because the debugger loaded the data first.

Trap 3: deadlock during evaluation.

 Thread 1 (frozen) holds lock L
 Thread 5 (borrowed for evaluation) runs your getter, which needs lock L
   --> it waits forever --> evaluation times out
 Visual Studio may then disable further implicit evaluation for the session

The same happens with getters that call .Result on a task that needs a frozen thread to complete.

6. Changing state on purpose

You can edit a value in Locals or Watch, or run order.Status = "Paid" in the Immediate window. Use it as an experiment:

1. Change one thing.
2. Write down what you changed (and tell your pair).
3. Continue and observe.
4. Treat everything after that point as an experiment, not real behaviour.
5. If it goes wrong, restart the session instead of trying to undo it by hand.
6. Once confirmed, change the code and add a test. A value changed in the debugger is a hypothesis, not a fix.

Remember the Immediate window runs real code: db.SaveChanges() saves to the database, and httpClient.PostAsync(...) sends a real request.

7. Settings that control evaluation (Visual Studio)

Turning these off is a good idea when debugging code with fragile state or expensive getters.

8. Security and privacy

Watch and Immediate show whatever is in memory: tokens, connection strings, customer records and personal information. Debug with test data, don't share screen recordings of sessions on real data, and remember that pinned DataTips and Watch expressions are saved in your user settings for the solution.

9. .NET 11 awareness

These windows are IDE features and work the same for .NET 10 and .NET 11 previews. The expression evaluator follows new C# syntax as each IDE release adds support.

10. Try it yourself

1. Run the code example to the breakpoint line.
2. Add batch.Numbers to Watch, step a few times, and watch batch.ReadCount climb even though your code didn't read it.
3. Change the Watch to batch.Numbers, nse and read the message.
4. Add batch._numbers instead and confirm it shows the list without changing the count.
5. In the Immediate window run batch.Add("A-999"), then ? batch.Numbers.Count.
6. Right-click batch, choose Make Object ID, step out of the method and watch $1.
7. Turn off implicit property evaluation in the options and see the refresh icons appear.

A class whose property has a side effect:

var batch = new OrderBatch();
batch.Add("A-100");
batch.Add("A-101");

Console.WriteLine($"Orders: {batch.Numbers.Count}"); // set a breakpoint here
Console.WriteLine($"Getter called {batch.ReadCount} time(s)");

public sealed class OrderBatch
{
    private readonly List<string> _numbers = [];
    private int _readCount;

    public IReadOnlyList<string> Numbers
    {
        get
        {
            _readCount++; // side effect: watching this property changes state
            return _numbers;
        }
    }

    public int ReadCount => _readCount;

    public void Add(string number) => _numbers.Add(number);
}

Watch expressions and Immediate window commands to try:

batch.Numbers, nse          // refuses to run the getter
batch._numbers              // reads the backing field directly, no code runs
batch.ReadCount, h          // hexadecimal
batch, raw                  // ignores any DebuggerDisplay customisation

? batch.Numbers.Count       // Immediate: evaluate (runs the getter)
batch.Add("A-999")          // Immediate: call a method in the paused process