My fan spun up like a jet engine every time I opened a medium-sized solution, and Visual Studio would hang for a solid ten seconds on every keystroke in certain files. I assumed it was just a big solution being big. It wasn’t — it was CodeLens quietly running Find All References on every method I scrolled past, chewing through CPU in the background the whole time. Here’s what’s actually worth checking before you consider a full reinstall.
Quick Answer
- Disable CodeLens under Tools > Options > Text Editor > CodeLens if you’re on a large codebase
- Turn off “Enable Diagnostic Tools while debugging” when you’re not actively profiling
- Disable extensions one at a time to isolate which one is causing the load
- Make sure Visual Studio and your solution are running from an SSD, not a spinning drive or USB
- If freezing happens specifically on reopen after closing, check for a lingering background process rather than reinstalling
Why Visual Studio Eats CPU and Freezes
A few features baked into Visual Studio are genuinely resource-heavy by design, and they don’t always make it obvious that they’re the ones responsible.
CodeLens runs continuous background analysis. Every time you view a method, CodeLens performs a Find All References-style task to show that little “X references” indicator above your code. On large solutions, this adds up to real, sustained CPU load in a separate process, and it’s one of the first things Microsoft’s own performance guidance points to for exactly this symptom.
Diagnostic tools and CPU profiling persist across sessions more than people expect. If you turn on CPU profiling once to investigate something, that setting doesn’t necessarily reset itself — it can remain active in future debug sessions and quietly consume resources you’re not using anymore. Worth explicitly checking rather than assuming it turned itself off.
Extensions are a very common, very underrated cause. A single misbehaving extension can spike CPU usage constantly, even when you’re not actively doing anything that should require it. And the annoying part is that it’s rarely obvious which one, since most people install several over time and forget which does what.
There’s a fourth cause specific to newer Visual Studio versions that’s worth calling out: a background process not closing correctly on exit, which then causes the next launch to hang or freeze with a busy cursor. This has been reported enough in Visual Studio 2026 threads that it looks like a real pattern rather than an isolated case, and it doesn’t get fixed by reinstalling — only by fully restarting the machine or signing out, which is a pretty inconvenient workaround for daily use.
Where This Shows Up Most
Large solutions with many projects hit CodeLens and background analysis overhead the hardest, since more code means more continuous reference-checking happening behind the scenes as you navigate.
Machines running Visual Studio from a mechanical hard drive or external/USB storage see dramatically worse performance than SSD setups — Microsoft’s own guidance specifically calls out that an SSD affects Visual Studio performance more than extra RAM or a faster CPU.
Debug sessions with diagnostic tools left enabled show CPU spikes specifically during debugging rather than at idle, which is a good clue that it’s the diagnostic overlay rather than the codebase itself.
Fresh installs of newer Visual Studio versions on Windows 11 have reported startup and idle CPU issues distinct from the general codebase-size problem — this looks tied to specific builds rather than universal.
Cause Comparison Table
| Symptom | Likely Cause | Fix |
|---|---|---|
| High CPU while scrolling/editing | CodeLens background analysis | Disable CodeLens |
| High CPU only during debugging | Diagnostic tools / CPU profiling left on | Disable in Debugging > General |
| High CPU at idle, no clear trigger | A specific extension | Disable extensions one at a time |
| Freeze specifically on reopen after close | Lingering background process | Restart machine; check for pattern |
| Slow everything, especially large solutions | Non-SSD storage | Move VS/solution to SSD |
Step-by-Step Fixes
Step 1: Disable CodeLens. Tools > Options > All Settings > Text Editor > CodeLens, then clear “Enable CodeLens.” This alone resolves a large share of “typing feels laggy” complaints on bigger codebases.
Step 2: Turn off diagnostic tools while debugging if you’re not actively profiling. Tools > Options > All Settings > Debugging > General, clear “Enable Diagnostic Tools while debugging.” Re-enable it only when you actually need to profile something specific.
Step 3: Disable extensions one at a time. Extensions > Manage Extensions, disable them individually and restart Visual Studio between each to isolate which one is responsible, rather than disabling all of them at once and never finding the actual culprit.
Step 4: Check your power and visual settings if you’re on Windows 11. Set Power mode to Best Performance under Settings > System > Power & battery when plugged in, and consider setting Windows visual effects to “Adjust for best performance.” These sound unrelated to Visual Studio specifically, but they affect how aggressively your CPU can boost during heavy operations like builds and debugging.
Step 5: Confirm you’re running from an SSD. Check where both Windows and your solution files actually live. Running Visual Studio itself from an SSD matters more than solution file location, but avoid running from USB drives entirely — that’s a specifically called-out worst case.
Step 6: Update to the latest Visual Studio build. Performance regressions and fixes both happen across updates fairly often. If you’re on an older build within a version, checking for updates is a low-effort step worth doing before deeper troubleshooting.
Step 7: Try Safe Mode to rule out extensions and customizations entirely. Run devenv.exe /SafeMode from the command line. If performance is normal in Safe Mode, the cause is almost certainly an extension or customization rather than the core IDE.
Step 8: Reset user settings if Safe Mode doesn’t help. Run devenv.exe /resetuserdata to reset user settings without a full reinstall. This is a smaller, less disruptive step than uninstalling everything.
What Actually Worked For Me
I went straight for disabling extensions first, since that’s the advice I’d seen repeated the most. Spent a good chunk of an afternoon disabling them one by one, restarting each time, and found nothing — CPU usage stayed high regardless. Kind of demoralizing, not gonna lie.
What actually fixed it was almost embarrassingly simple once I found it: CodeLens. I hadn’t even considered it because I didn’t really think of it as a “feature” so much as just part of how Visual Studio looked. Turning it off dropped my idle CPU usage noticeably and made scrolling through larger files feel normal again. I probably should’ve checked Microsoft’s own performance tips page before spending an afternoon on extensions, but that’s troubleshooting for you sometimes — you chase the popular answer before the actually-relevant one.
Advanced Fixes and Edge Cases
Persistent freeze-on-reopen issues may need a full restart, not a reinstall. If Visual Studio works fine after a fresh boot but locks up specifically when closed and reopened without restarting the OS, this points to a background process (debugger-related services have been mentioned in reports) not releasing cleanly on exit. A full reinstall typically doesn’t fix this pattern — only rebooting does, which suggests the issue lives outside Visual Studio’s own files.
Clearing the ComponentModelCache can help with startup-specific hangs. Navigate to %LOCALAPPDATA%\Microsoft\VisualStudio and clear the ComponentModelCache folder (and potentially other cache folders) if Visual Studio hangs specifically on startup or the welcome screen, rather than during general use.
Capturing a performance trace gets you further with actual support. If none of the above resolves it, Visual Studio’s built-in Help > Send Feedback > Report a Problem tool can capture a performance trace (.etl.zip) during the exact moment of high CPU, which is far more useful for escalation than a text description alone.
Prevention Tips
Periodically review your installed extensions and remove ones you no longer actively use, since forgotten extensions are a common quiet source of background load. Leave diagnostic tools and CPU profiling off by default and only enable them for the specific session you need them for. And keep Visual Studio itself and your solution files on an SSD — this one change affects perceived performance more than most configuration tweaks combined.
FAQ
Does closing unused tool windows actually help CPU usage? Somewhat, especially windows that do active background work like Diagnostic Tools or certain profiler views. Closing a static window like Solution Explorer won’t do much on its own.
Is it normal for Visual Studio to use a lot of CPU during a build? Yes, builds are inherently CPU-intensive and that’s expected. The concern is sustained high CPU at idle or during simple editing, not during an active build or debug launch.
Should I reinstall Visual Studio if nothing else works? It’s a reasonable last resort, but try Safe Mode and resetuserdata first — several reported cases show reinstalling doesn’t actually fix persistent freezing, since the cause sometimes lives outside the Visual Studio installation itself.
Does more RAM fix Visual Studio performance issues? Less than people assume. Storage type (SSD vs not) tends to have a bigger measurable impact on Visual Studio’s responsiveness than adding RAM or a faster CPU.
Editor’s Opinion
codelens being on by default for everyone even though a lot of people dont use the reference counts much feels like a weird tradeoff, its a nice feature until your machine starts sounding like its taking off. anyway check that before you go extension-hunting like i did, would’ve saved me an afternoon honestly.
