Rider Code Analysis Stuck at High CPU: A Diagnostic Guide for the Rider.Backend Process

You open a large solution in JetBrains Rider and the eye icon in the status bar never stops pulsing. The "Analyzing..." indicator sits there indefinitely, code completion gets sluggish, and your laptop fan spins up. The useful takeaway: this is almost always the ReSharper-based backend process (Rider.Backend) spinning on something specific — a corrupted cache, a pathological file, a NuGet restore loop, or a known backend bug — and each cause has a targeted fix. You do not need to reinstall the IDE.

Confirm the backend is the process spinning

Rider runs as two main processes: the JVM-based frontend (the IDE UI) and the .NET backend (Rider.Backend), which does code analysis, inspections, and navigation indexing. Before changing anything, confirm which one is consuming CPU.

Open your OS process monitor — Task Manager on Windows, Activity Monitor on macOS, or top/htop on Linux — while the analysis indicator is stuck. If Rider.Backend shows sustained high CPU while the frontend process is idle, this guide applies. If the frontend JVM is the one spinning, the problem is more likely UI rendering, a plugin, or frontend memory pressure, and the fixes below mostly will not help.

Cause and diagnostic table

Cause	How it presents	Quick diagnostic
Corrupted caches / indexes	Analysis never settles after an upgrade or crash; inspections wrong or missing	Invalidate caches and restart — if fixed, this was it
Pathological file (generated code, minified JS, huge .sql/.cs)	CPU spikes when a particular project or folder is indexed	Backend log shows repeated analysis of the same file; excluding it fixes it
NuGet restore loop	High CPU plus continuous restore activity in the NuGet tool window	Check NuGet sources for unreachable feeds or auth failures
Known backend bug in your Rider version	Started immediately after an upgrade; reproduces on multiple solutions	Search JetBrains YouTrack for your version and symptoms; test the latest stable release

Ordered checks, cheapest first

1. Invalidate caches and restart

Cache corruption is the most common cause, especially after an IDE upgrade or an unclean shutdown. In Rider, go to File > Invalidate Caches, choose Invalidate and Restart. No special permissions are needed; this deletes Rider's local indexes and system caches for your projects, not your code.

Be aware of the trade-off: after restart, Rider performs a full re-index, which can take a long time on very large solutions. Let it finish completely before judging the result. If the daemon settles and CPU returns to idle afterward, you are done.

2. Exclude pathological files from analysis

If high CPU persists, look for a file the analyzer is choking on. Typical offenders are generated C# (large designer files, protobuf output), minified JavaScript checked into the repo, or multi-megabyte .sql scripts. Open the backend log via Help > Diagnostic Tools > Show Log in Explorer/Finder (the exact wording varies by version) and look for repeated entries mentioning the same file or project while CPU is high.

Once identified, right-click the containing folder in the Solution Explorer and mark it as Excluded, or add specific files to the skip list under Settings/Preferences > Editor > Inspection Settings > Elements to skip. Understand the cost: excluded files get no inspections and limited navigation, so exclude generated or third-party content, not hand-written code — otherwise you may hide real errors.

3. Check for a NuGet restore loop

Open the NuGet tool window and watch whether restore runs repeatedly or fails and retries. Common triggers are an unreachable private feed, expired credentials, or a VPN-dependent source. Remove or fix the offending source in the NuGet settings, or restore from the command line (dotnet restore in a terminal, run from the solution directory) to see the actual error outside the IDE.

4. Capture thread dumps and logs to localize the bottleneck

If none of the above helps, gather evidence before changing anything else. While CPU is high, use Help > Diagnostic Tools to capture thread dumps (menu names vary by version; check the Rider help pages for your installed release). Thread dumps taken while Rider.Backend is spinning show exactly which analysis pass is stuck — valuable both for your own diagnosis and for a support ticket.

5. Upgrade Rider

If the behavior started right after an upgrade or reproduces across multiple solutions, check whether your version has a known backend issue. The Toolbox App makes it easy to install the latest stable release side by side. If the new version fixes it, stay on it; if not, roll back is simply launching the older install again — installing a new Rider version does not modify your projects.

Verify each fix

After every change, close and reopen the solution, let indexing complete, and confirm two things: the daemon/eye indicator settles to its idle state, and Rider.Backend CPU drops to near zero in your process monitor when you are not actively typing. Do not judge success by the first minute after opening — initial indexing legitimately uses CPU.

When to escalate to JetBrains support

File a YouTrack issue when all of the following hold: the problem survives cache invalidation, file exclusion, and an upgrade to the latest stable release; and ideally it reproduces on a minimal sample solution you can attach. Include the backend logs, thread dumps captured while CPU was high, your Rider version, and OS. Before posting logs publicly, scrub proprietary file paths, internal hostnames, and any credentials — logs can contain all three.

Limitations

Menu paths and setting names differ across Rider versions, so verify against the help pages for your installed release. Sustained backend CPU can also be legitimate on first load of a very large solution — the condition to act on is CPU that never returns to idle, not CPU during initial indexing.