Debugging with Rider breakpoints and watches

A debugger allows you to pause code while it runs and inspect the state around a problem. Before opening a debugger, write down a reproducible failure and the value you expect to see. This prevents aimless stepping through a large solution.

A focused debugging workflow

1. Start the intended run/debug configuration and place a breakpoint near the suspicious method.
2. Reproduce the issue. If the breakpoint does not hit, verify your symbols, configuration and whether that code path actually executes.
3. Inspect locals and watches. Check whether the data is already wrong before the method or changes unexpectedly inside it.
4. Step over to execute a statement without entering a method; step into when the called method matters; step out when you want to return to the caller.
5. Record the cause in a regression test if possible, then remove temporary debugger-only changes.

Conditional breakpoints

A conditional breakpoint can pause only when a specific condition is true, for example when a player ID matches the bug report. Avoid conditions that modify application state. Breakpoint behavior depends on runtime and whether Rider is attached to a .NET or Unity process.

Unity considerations

For Unity debugging, Rider must be attached to the correct Editor or player process. Check that the project and symbols correspond to the running build. Remember that frame timing and physics callbacks may change when execution is paused.

Exercise: Find why a counter resets unexpectedly. Inspect the call stack before changing code, then create a test for the corrected behavior.

References: Rider debugger help and Rider navigation.