Diagnosing Rider .NET Debugger Breakpoints That Won't Hit

Recognizable condition

When you start a debugging session in Rider, breakpoint icons appear hollow or show a tooltip such as "Breakpoint will not be currently hit". Execution never stops at those lines, even though the code is being executed.

Cause/diagnostic table

Possible cause	How to verify
Build is Release or optimizations enabled	Check the solution configuration dropdown; look for "Release" or "Optimize code" in project properties.
Symbols (.pdb) not loaded or mismatched	Open Debug → Windows → Modules and look for the module; status should be "Symbols Loaded".
Debugger attached to wrong process	In the Attach to Process dialog, confirm the process name (e.g., IIS Express vs. dotnet) matches the project’s launch profile.
Just My Code filtering hiding breakpoints	Enable Tools → Options → Debugger → Just My Code and see if breakpoints in framework or generated code become solid.

Ordered checks

1. Verify build configuration
   Open the configuration selector in the Rider toolbar. Ensure it is set to a Debug configuration (e.g., "Debug" or "Debug|AnyCPU"). If you see "Release", switch to Debug.
2. Confirm optimizations are disabled
   Right‑click the project → Properties → Build. Uncheck "Optimize code" for the Debug configuration.
3. Check symbol loading
   Start debugging, then open Debug → Windows → Modules. Locate the assembly containing your breakpoint. The Symbol Status column should read "Symbols Loaded". If it shows "Symbols not found" or a version mismatch, note the path.
4. Ensure correct process attachment
   While debugging, open Debug → Windows → Processes. Verify that the process listed matches the executable launched by Rider (e.g., "MyApp.exe" for a console app or "dotnet" for a .NET Core web app). If you see multiple instances, detach and re‑attach to the correct one.
5. Review Just My Code settings
   Go to Tools → Options → Debugger → Just My Code. Temporarily disable the option, restart the debugging session, and observe whether breakpoint icons become solid.

Fixes tied to findings

If the build is Release or optimizations are on

Switch to a Debug configuration and disable optimizations as described in steps 1‑2. Rebuild the solution (Build → Rebuild Solution). This forces the compiler to emit debuggable IL and matching PDBs.

If symbols are not loaded or mismatched

Make sure the project’s output path points to the folder Rider is debugging from. Clean and rebuild (Build → Clean Solution, then Build → Rebuild Solution). After rebuilding, repeat the Modules window check. If symbols still fail, verify that the .pdb file exists alongside the DLL in the output directory.

If the debugger is attached to the wrong process

Stop debugging, then choose Run → Attach to Process… Select the exact process that corresponds to your launch profile (e.g., "IIS Express" for IIS Express hosting, or the dotnet process launched by Rider’s "Docker" or "WSL" profile). Re‑start the debugging session.

If Just My Code is hiding breakpoints

Leave Just My Code disabled while debugging the problematic code, or add a [DebuggerNonUserCode] attribute to generated files you do not need to step through. Remember to re‑enable Just My Code after debugging to reduce noise.

Escalation criteria

If after performing all checks and applying the corresponding fixes the breakpoint icons remain hollow:

• Collect the Debug output window (View → Debugger Windows → Output) and look for messages such as "The breakpoint will not currently be hit. No symbols have been loaded for this document."
• Verify that the project targets a supported .NET version (Rider 2024.2+ supports .NET 6‑8). Older SDKs may produce PDBs that Rider cannot consume.
• Test with a minimal reproducible project (e.g., a new console app with a single breakpoint) to isolate whether the issue is project‑specific or environment‑wide.
• If the minimal project works, compare .csproj settings, especially DebugType, DebugSymbols, and Optimize properties.
• If the issue persists across projects, consider invalidating Rider caches (File → Invalidate Caches / Restart) or reinstalling the Rider .NET plugin.

Practical verification

After applying a fix, start a debugging session and confirm:

1. Breakpoint icons are solid (no warning tooltip).
2. Execution stops at the breakpoint when the code path is reached.
3. The Modules window shows "Symbols Loaded" for the relevant assembly.
4. The Debug output window contains no "Breakpoint will not be currently hit" messages.

These observations indicate that the debugger can bind the breakpoint successfully.

Rollback considerations

Only operations that change state require rollback:

• Switching from Release to Debug configuration – revert to Release after debugging if performance testing is needed.
• Disabling Just My Code – re‑enable it once debugging is complete to keep the debugging experience clean.

All other steps (checking modules, verifying process attachment) are read‑only and do not need rollback.