How to Troubleshoot Visual Studio: Fix Crashes, Errors & Slowdowns
Why This Is Happening
You've been there. You open Visual Studio, pour your first coffee, and , nothing. The IDE hangs on the splash screen, throws a cryptic error like HRESULT: 0x80131500, or takes four full minutes to load a solution that used to snap open in fifteen seconds. I've seen this exact situation on dozens of developer machines, from solo indie devs running VS 2022 Community to enterprise teams with sprawling multi-project .NET solutions. It's genuinely maddening because you can't ship code from a broken IDE.
So why does Visual Studio , one of the most sophisticated pieces of software Microsoft has ever built, behave so badly sometimes? A few reasons, and they're worth understanding before you start clicking around blindly.
Extension conflicts are the number one culprit. Visual Studio's extension ecosystem is massive. When an extension written for VS 2019 gets loaded into VS 2022, or when two extensions fight over the same IDE services, you get crashes, freezes, and memory leaks. The extension host runs in-process, meaning one bad extension can take down the entire IDE.
Corrupted component cache is a close second. Visual Studio maintains a MEF (Managed Extensibility Framework) component cache at %LocalAppData%\Microsoft\VisualStudio\17.0_[instance ID]\ComponentModelCache. When this cache gets stale, after a Windows update, a .NET SDK change, or an incomplete VS update, the IDE can't initialize properly. You'll often see the error "The 'XYZ' package did not load correctly" right before VS crashes or hangs.
SDK and .NET targeting pack mismatches are another common headache, especially on machines where developers manage multiple projects targeting different framework versions. Missing or mismatched targeting packs cause IntelliSense to break, project loads to fail, and build errors that have nothing to do with your actual code.
There are also hardware-adjacent causes: a full SSD (Visual Studio loves disk space), antivirus software scanning PDB files in real time, and Windows Defender blocking access to build output folders. None of these produce helpful error messages, Visual Studio just slows to a crawl and you're left guessing.
The frustrating truth is that Microsoft's error dialogs for Visual Studio are famously unhelpful. "An unexpected error has occurred" tells you precisely nothing. This guide cuts through that and gives you the actual fixes that work.
The Quick Fix, Try This First
Before you go down a rabbit hole of registry edits and reinstalls, try this. It resolves about 60% of Visual Studio troubleshooting cases in under five minutes.
Launch Visual Studio in Safe Mode. Safe Mode disables all extensions and loads only the core IDE components. Open a Command Prompt or the Run dialog (Win + R) and type:
devenv.exe /SafeModeIf Visual Studio opens cleanly in Safe Mode, you've confirmed the problem is an extension, not the core IDE. That's actually good news. Now you know exactly where to look.
If Safe Mode works, go to Extensions > Manage Extensions, then disable all extensions. Re-enable them one at a time, restarting Visual Studio after each one. The extension that causes Visual Studio to hang or crash on startup is your culprit. Uninstall it, check the extension's marketplace page for a compatibility update, or look for an alternative.
If Visual Studio doesn't open even in Safe Mode, the next fastest fix is clearing the MEF component cache. Close Visual Studio completely, then open File Explorer and navigate to:
%LocalAppData%\Microsoft\VisualStudio\17.0_[yourInstanceID]\ComponentModelCacheDelete everything inside that folder, don't delete the folder itself, just the contents. Visual Studio will rebuild the cache on next launch. This takes about 30–60 seconds on first open but often completely resolves "package did not load" errors and IntelliSense failures.
Don't know your instance ID? Open Developer Command Prompt for VS and run vswhere -all, it'll list every installed instance with its ID. Alternatively, the path usually ends in something like 17.0_a1b2c3d4; just look for folders matching that pattern.
If the Safe Mode test and cache clear didn't fully resolve things, the next step is running an official repair. Visual Studio ships with a dedicated repair function inside the Visual Studio Installer, it's not the same as uninstall/reinstall, and it's much faster. It checks every installed component against the expected state and replaces anything that's missing or corrupted.
Open the Visual Studio Installer from the Start menu. If you can't find it, search for "Visual Studio Installer", it's a separate app from Visual Studio itself. Once open, find your Visual Studio installation (you may have multiple versions listed), click the three-dot menu (⋮) to the right, and select Repair.
The repair process downloads fresh copies of any components it determines are damaged. On a decent connection, this typically runs 5–20 minutes. You do not need to uninstall first, the installer handles everything in place.
During repair, pay attention to the log output at the bottom of the installer window. If you see repeated failures around a specific component, say, Microsoft.VisualStudio.Component.NuGet or Microsoft.VisualStudio.Component.Roslyn.Compiler, note the component ID. That tells you exactly which workload is broken.
After repair completes, restart your machine (not just Visual Studio, a full reboot). Then launch VS normally and try loading your problem solution. If IntelliSense comes back and build errors disappear, you're done. If the same issues persist, move to Step 2.
Visual Studio stores a huge amount of user state, window layouts, editor settings, project history, environment customizations, in files that can themselves become corrupted. When the IDE behaves strangely in ways that don't match typical extension or component issues (random UI glitches, menu items not appearing, toolbars disappearing), the user settings store is often to blame.
To reset settings, open Visual Studio (or try opening it, even if it's partially broken), go to Tools > Import and Export Settings > Reset all settings and follow the wizard. You'll have the option to save a backup of your current settings first, do this if you have custom keyboard shortcuts or editor preferences you don't want to rebuild.
Separately, check the Visual Studio Activity Log to understand what's failing at startup. Close VS completely, then launch it with the logging flag:
devenv.exe /LogThis writes a detailed XML log to:
%AppData%\Microsoft\VisualStudio\17.0_[instanceID]\ActivityLog.xmlOpen that file in any browser (it renders as readable XML). Search for type="Error" entries, these are the actual failure points. You'll see entries like:
<entry>
<record>42</record>
<time>2026/04/20 09:14:33.812</time>
<type>Error</type>
<source>VisualStudio</source>
<description>Package 'SomeExtension.Package, Version=1.0.0' failed to load.</description>
</entry>That tells you exactly which package is causing problems, far more actionable than any error dialog Visual Studio shows on screen.
One of the most common Visual Studio troubleshooting scenarios for .NET developers is IntelliSense showing red squiggles everywhere, or build errors like "The SDK 'Microsoft.NET.Sdk' specified could not be found" even though your code hasn't changed. This is almost always a .NET SDK mismatch.
Open a Developer PowerShell for VS and run:
dotnet --list-sdksThen check what SDK version your project's global.json is requesting (if one exists at your solution root). If the requested version isn't in the list, you need to install it. Go to Tools > Get Tools and Features inside Visual Studio, or download the specific SDK version directly from the .NET download page.
For targeting pack issues, which cause errors like "The reference assemblies for .NETFramework,Version=v4.7.2 were not found", open the Visual Studio Installer, click Modify on your VS installation, and go to the Individual components tab. Search for your target framework version (e.g., ".NET Framework 4.7.2 targeting pack") and make sure it's checked.
After installing missing targeting packs, close Visual Studio, delete your solution's .vs hidden folder (it's in the same directory as your .sln file, you may need to show hidden files in Explorer), and reopen the solution. Visual Studio will regenerate this folder cleanly. IntelliSense should come back within 30–60 seconds of the solution loading while the Roslyn language service indexes your project.
If you see red squiggles but the build succeeds, that's specifically an IntelliSense caching issue. Go to Build > Rebuild Solution once, then close and reopen the solution.
If Visual Studio opens but runs painfully slowly, sluggish IntelliSense, delayed typing response, builds that crawl, performance tuning is the fix. I've seen well-specced developer machines with 32 GB of RAM where Visual Studio was still unusable because of a few configuration issues.
First, check whether real-time antivirus scanning is the culprit. Windows Defender (and third-party AV) will scan every file Visual Studio reads and writes, including PDB files, build output, and temporary compiler files. This alone can double or triple build times. Add the following folders as exclusions in Windows Security (Windows Security > Virus & threat protection > Manage settings > Add or remove exclusions):
C:\Users\[YourName]\AppData\Local\Temp
C:\Users\[YourName]\source\repos (or wherever your projects live)
C:\Program Files\Microsoft Visual Studio\2022\[Edition]
C:\Windows\Microsoft.NETSecond, disable lightweight solution load if you're seeing delayed project loads. Go to Tools > Options > Projects and Solutions > General and uncheck Lightweight solution load (in older VS versions) or make sure Restore last project and Automatically restore NuGet packages are configured as you expect.
Third, check your GPU. Visual Studio uses hardware-accelerated rendering by default. On some machines with driver issues, this causes UI stuttering. Go to Tools > Options > Environment > General and check Automatically adjust visual experience based on client performance, or uncheck Use hardware graphics acceleration if available to test if GPU rendering is the problem.
Finally, run Help > Send Feedback > Report a Performance Problem, this tool captures a performance trace you can analyze yourself using PerfView or submit to Microsoft. The trace will show exactly which operations are slow.
If Visual Studio crashes repeatedly, especially if it crashes mid-session rather than on startup, you need to look at crash dump files. Windows automatically captures these when a process crashes unexpectedly.
Open Event Viewer (Win + R, type eventvwr.msc). Navigate to Windows Logs > Application. Filter by event source "Application Error" and look for entries with devenv.exe as the faulting application. Note the Faulting module name, this is the DLL that caused the crash. If it's something like SomeExtension.dll, that's your answer. If it's clrjit.dll, vcruntime140.dll, or another Microsoft component, that points to a corrupted runtime.
For crash dumps specifically, check:
%LocalAppData%\CrashDumpsIf dump files exist there, their names include the process name and timestamp. You can open these in Visual Studio itself (ironically) or in WinDbg. In WinDbg, run:
.loadby sos clr
!analyze -vThis gives you the exact call stack at the moment of the crash, which is far more specific than anything in Event Viewer.
For the common crash caused by a corrupted devenv.exe.config, navigate to your VS installation directory (typically C:\Program Files\Microsoft Visual Studio\2022\[Edition]\Common7\IDE\) and rename devenv.exe.config to devenv.exe.config.bak. VS will regenerate a clean one on next launch. This fixes several known crash patterns, particularly around .NET runtime binding redirects.
Advanced Troubleshooting
If you've worked through all five steps and Visual Studio is still giving you grief, we're into deeper territory. This section is for developers on domain-joined machines, enterprise environments with Group Policy applied, or anyone hitting errors that the standard fixes don't touch.
Group Policy Conflicts
In corporate environments, Group Policy can block Visual Studio features you'd never expect. I've seen GP policies that prevent writing to the user's temp folder (which breaks the C++ compiler), block unsigned code execution (which prevents extensions from loading), and restrict registry access that Visual Studio needs for its license check. Run gpresult /h gpresult.html in an elevated Command Prompt and open the resulting HTML file. Look under "Computer Configuration" and "User Configuration" for policies related to application execution, registry access, or software restriction policies. Take this report to your IT admin, it's the fastest way to get a targeted exception rather than a blanket "reinstall VS."
Registry-Level Fixes
Visual Studio stores per-instance configuration in the registry under:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\17.0_[instanceID]If you're seeing license validation errors or activation problems, check the Licenses subkey. For persistent "package load failed" errors that survive a repair, delete the entire instance key (after backing it up with File > Export in Registry Editor) and let Visual Studio recreate it on next launch. This is a more aggressive reset than clearing the MEF cache, and it resolves some stubborn initialization failures.
Event Viewer Analysis for Build Failures
MSBuild failures that don't surface clean error messages often log detail to the Application event log under source MsBuild. Filter Event Viewer for Event ID 2 from source MsBuild, these entries contain the full build target failure chain that VS's error list condenses into a single useless line. Cross-reference with your build's binlog: pass /bl to MSBuild on the command line to generate a msbuild.binlog file, then open it with the free MSBuild Structured Log Viewer tool.
Network and Proxy Issues
If NuGet restore fails in Visual Studio but works fine from the CLI, check whether Visual Studio is configured to use a different proxy. VS reads proxy settings from %AppData%\NuGet\NuGet.Config. Add your proxy explicitly:
<config>
<add key="http_proxy" value="http://proxy.yourcompany.com:8080" />
</config>On Azure DevOps-connected environments, also check that the Azure Artifacts Credential Provider is installed and up to date, this is a separate component that handles authenticated NuGet feeds.
Prevention & Best Practices
The best Visual Studio troubleshooting session is the one you never have to run. I know that sounds obvious, but there are specific, concrete habits that keep VS healthy long-term on a developer machine.
Update Visual Studio on a schedule, not reactively. Running updates through the Visual Studio Installer on a regular cadence (monthly works well) means you're never sitting on a build that has known crash bugs. Don't let VS nag you for months and then update right before a deadline, updates occasionally require a component cache rebuild and you don't want that surprise. Check for updates under Help > Check for Updates.
Audit your extensions quarterly. Go to Extensions > Manage Extensions and look at your installed list. Disable anything you haven't used in 60 days. Extensions that haven't been updated in over a year for your current VS version are time bombs, they will eventually conflict with a VS update. The 2–3 extensions you genuinely use daily are worth keeping; the other 12 you installed on a whim are not.
Keep your SSD healthy. Visual Studio builds generate enormous amounts of temporary data. A drive with less than 10 GB free will cause build failures, IntelliSense degradation, and crash-on-save behavior. Monitor disk space and periodically clear %Temp%, NuGet's package cache at %LocalAppData%\NuGet\v3-cache, and old bin\ and obj\ folders in abandoned projects.
Use a dedicated antivirus exclusion profile for development. Don't just add exclusions reactively when builds slow down. Set up proper exclusions from day one for your repos folder, temp folder, and the VS installation directory. Document these exclusions so they survive machine reimages.
Lock down your .NET SDK version with global.json. Adding a global.json file to your solution root with a pinned SDK version prevents unexpected SDK upgrades from breaking your build mid-project. This is standard practice on team projects and it saves hours of debugging when a new SDK ships a breaking change.
- Run
devenv.exe /updateconfigurationfrom Developer Command Prompt after any VS update to force a clean config rebuild - Enable Tools > Options > Environment > Startup > Show empty environment to speed up VS launch time, skip the startup page entirely
- Set your project's
objandbinfolders as antivirus exclusions specifically, these are the hottest build paths and the biggest AV scan targets - Back up your VS settings with Tools > Import and Export Settings > Export selected environment settings before any major VS update so you can restore your configuration if something breaks
Frequently Asked Questions
Visual Studio won't open at all, it just crashes on the splash screen. What do I do?
Start with devenv.exe /SafeMode from Run or Command Prompt to bypass extensions. If that opens, an extension is crashing the IDE, disable them all and re-enable one at a time. If Safe Mode also crashes, delete the contents of %LocalAppData%\Microsoft\VisualStudio\17.0_[instanceID]\ComponentModelCache and run the VS Installer Repair. Check the Activity Log at %AppData%\Microsoft\VisualStudio\17.0_[instanceID]\ActivityLog.xml for specific error entries, launch VS once with the /Log flag to generate it before it crashes.
IntelliSense has completely stopped working but my code still builds fine. How do I fix this?
This is almost always a corrupted Roslyn language service cache. Close Visual Studio, delete the hidden .vs folder from your solution directory (enable hidden files in Explorer to see it), and reopen your solution. Give IntelliSense 60–90 seconds to reindex after the solution loads, watch the status bar at the bottom of VS for "Ready" confirmation. If that doesn't work, go to Tools > Options > Text Editor > C# and toggle the IntelliSense settings off and on, then do a full solution rebuild.
Why is Visual Studio using 8+ GB of RAM and making my machine crawl?
Large solutions with many projects, combined with hungry extensions like ReSharper or CodeLens enabled across thousands of files, can push VS into multi-GB territory fast. First, check Task Manager, look for ServiceHub.Host.dotnet.x64.exe processes, which are the extension host workers; multiple instances running at high memory are a sign of extension leaks. Disable extensions you don't need. Second, go to Tools > Options > Environment > General and disable CodeLens if you don't use it, it's a major memory consumer. Third, consider splitting very large solutions into smaller focused ones and only loading what you're actively working on.
I'm getting "The 'XYZ' package did not load correctly" every time Visual Studio opens. How do I stop this?
This error means a Visual Studio extension package failed to initialize. First, identify the package name from the error and check if it corresponds to an installed extension under Extensions > Manage Extensions. If it does, uninstall or update that extension. If the package name looks like a built-in VS component (starts with Microsoft.VisualStudio), clear your MEF cache at %LocalAppData%\Microsoft\VisualStudio\17.0_[instanceID]\ComponentModelCache and run the VS Installer Repair. You can also suppress the dialog for non-critical packages by clicking "Don't show this again", but that doesn't fix the underlying load failure, just hides the symptom.
Visual Studio builds are extremely slow, much slower than building from the command line. Why?
Three common culprits: antivirus scanning your build output in real time (add your repos and temp folders as AV exclusions), too many background tasks running during build (CodeLens, file watchers, extension analyzers all compete with MSBuild for CPU), and disk I/O throttling from a nearly full or slow drive. Try building from Developer Command Prompt using msbuild /m, the /m flag enables parallel builds. If the CLI is significantly faster than VS, the overhead is coming from VS's in-process tooling, not MSBuild itself. Disabling Tools > Options > Projects and Solutions > Build and Run > Maximum number of parallel project builds to a higher value can also help.
How do I fix "Visual Studio has detected that NuGet packages are missing from this solution"?
This usually means NuGet restore failed silently. Open the Package Manager Console (Tools > NuGet Package Manager > Package Manager Console) and run Update-Package -reinstall to force restore all packages. If you're on a corporate network, NuGet may be unable to reach your package source, check Tools > Options > NuGet Package Manager > Package Sources and verify your feed URLs are correct and accessible. On Azure DevOps environments, re-authenticate your credential provider by running dotnet nuget locals all --clear from a terminal and then triggering restore again.