Visual Studio debugging/loading very slow

Here is how I solved the "slow symbol loading" problem in Visual Studio 2012:

Go to Tools -> Options -> Debugging -> General

CHECK the checkmark next to "Enable Just My Code".

Go to Tools -> Options -> Debugging -> Symbols

Click on the "..." button and create/select a new folder somewhere on your local computer to store cached symbols. I named mine "Symbol caching" and put it in Documents -> Visual Studio 2012.

Click on "Load all symbols" and wait for the symbols to be downloaded from Microsoft's servers, which may take a while. Note that Load all symbols button is only available while debugging.

UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers.

Click "OK".

From now on, symbol loading should be much faster.

Note that if you make any changes/downloads to Microsoft assemblies, you may need to go back into the Symbols dialog box and "Load all symbols" again.

---

Turning off intelliTrace fixed this for me.

In Visual Studio, Tools -> Options -> IntelliTrace

Then, uncheck the checkbox for "Enable IntelliTrace".

https://i.stack.imgur.com/dKLxZ.png

---

None of this worked for me but I found a Breakpoint on a symbol that was deleted. Seems 2010 was hanging on it. To see if this is your issue do debug->windows->breakpoints If any are in there just delete them.

Saunders, mentioned he checked for that but it was not mentioned in the solutions for this problem. Maybe common knowledge for some, but not all of us.

---

I deleted the "Temporary ASP.NET Files" folder and my localhost page load improved dramatically. Here is the path... %temp%\Temporary ASP.NET Files\

---

Do you have enabled FusionLog?

My VisualStudio was very slow to start, open solution and load symbols when start debugging. It was slow only on my machine, but not on other machines.

FusionLog writes tons of log stuff to disk. Just disabling it on RegEdit solved everything, on my case.

This is the FusionLog key on registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Check ForceLog value (1 enabled, 0 disabled).

---

I experienced the same problem and tried most of the resolutions above. Simply deleting cache and temp files end up working for me.

Try removing the contents of these two folders:

C:\Users\\{UserName}\AppData\Local\Microsoft\WebsiteCache

and

C:\Users\\{UserName}\AppData\Local\Temp (in particular the iisexpress and Temporary ASP.NET Files folders).

This can be set up to happen automatically on logging on to Windows by adding a cmd file to the C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup folder with the following content:

rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q

rmdir C:\Users\\{username}\AppData\Local\Temp /s /q

---

I think I may finally at least know the cause, though not the reason why. When the problem started occurring again, I noticed a ton of "conhost.exe" processes orphaned. I would close Visual Studio and they would remain open. Ending task on each of them has finally, reliably solved the problem. [hopefully]

(Just note, conhost.exe isn't a Visual Studio process though Visual Studio uses it. Thus, other users out there may have other applications out there that run conhost.exe. I know my machine doesn't which is why I can safely end task all of them but YMMV.)

As to why this happens? It seems to occur when I open more than one project at once, which I tend to do often, even though I only build and debug one of them at any time.

Edit #1 - This isn't a "silver bullet" unfortunately. It doesn't always work for me. Typically, when things get slow, I just close all of my Visual Studio sessions, then go into the task manager and end any instance of it, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe and MSBuild.exe I can find.

Typically, after that, when I restart my project it'll then load quickly. But not always.

Really I think the best course of action is probably to not build & debug code off a redirected folder/network share.

Edit #2 - Two years later, and this is still an issue for me in Visual Studio Community 2013, but I did seem to at least find the culprit task: Explorer.exe. Yeah, who knew. The moment I end that task, bam, page loads in a single second.

If I have a Windows Explorer file browser open to my redirected network drive (which is often since that's where my code is), this problem seems to occur. Closing the window isn't enough, I have to kill the whole Explorer.exe task. I could only guess what it's doing...going nuts with file handles?

I can usually use the task manager to start up a new explorer.exe task (I can only take so much alt-tabbing), and Visual Studio will continue to load nice and quick. But if I so much as open Windows Explorer again, it almost always goes back to super-slow-mo.

So, if you've got a redirected network share, give it a shot. It sure beats working locally.

---

The above are all good solutions and I tried all of them, but got the solution here, which is to

Debug -> Delete All Breakpoints

---

For me it was IE 9.08.8112.16241. As soon as I used Firefox or Chrome there was no sluggish debugging with F10 or F11. I do not know what the problem with IE is but I officially despise using it for testing now.

Update: I have turned off all IE program add-ons and it is back to full speed. Turning them on one at a time revealed that LastPass (in my case) was the culprit. I guess I do not get to blame MS after all.

Several years into the future... If you are using Brave you can easily access your extensions and turn them off one at a time (or several) while debugging.

brave://extensions

Just click the toggle slider. Notice that all of mine are on except for DuckDuckGo Privacy essentials. They are not removed, just temporarily disabled.

https://i.stack.imgur.com/1sbdP.png

---

For me, I implemented this tip which basically drastically improved performance by adding the following two attributes to compilation tag in web.config

<compilation ... batch="false" optimizeCompilations="true"> ... </compilation>

What does batch="false" do?

It makes pre-compilation more selective by compiling only pages that have changed and require re-compiling

What exactly is the optimizeCompilations doing? Source

ASP.NET uses a per application hash code which includes the state of a number of things, including the bin and App_Code folder, and global.asax. Whenever an ASP.NET app domain starts, it checks if this hash code has changed from what it previously computed. If it has, then the entire codegen folder (where compiled and shadow copied assemblies live) is wiped out. When this optimization is turned on (via optimizeCompilations="true"), the hash no longer takes into account bin, App_Code and global.asax. As a result, if those change we don't wipe out the codegen folder.

Reference: Compilation element on MSDN

---

I had execution perfomance troubles with debugging too and i tried very many options of debugger. In my case huge perfomance achieved when i change this options:

Tools - Options - Debugging - Output Window - (General output settings - All debug output) - OFF

---

I had problems with slow Visual Studio debugging when "Native Code" debugger was enabled. Try disabling it.

On "Visual Studio 2012" go to:

Project Properties -> Web -> Debuggers (bottom of page). -> Disable all except ASP.NET

Hope it helps.

Similar questions: 1, 2

---

In my case, it was the .NET Reflector Visual Studio Extension (version 8.3.0.93) with VS 2012. Debugging was taking 10 seconds for each Step Over (F10).

In Visual Studio, go to Tools/Extensions and Updates... and disable the .NET Reflector Visual Studio Extension. Don't forget to restart Visual Studio.

---

In my case it was

Tools/Options/Debugging/General/Enable JavaScript debugging for ASP.NET (Chrome and IE)

Once I unchecked this, my debug start went from 45-60 seconds down to 0-5 seconds.

---

One time, after a power outage, I had to face the same slowness problem each time a breakpoint was hit or a Exception was thrown.

I had the vague remembering that the "suo" file (in the same directory as the "sln" solution file) can be corrupted and make everything slow down.

https://i.stack.imgur.com/qC8bM.png

I deleted my "suo" files and everything was ok. The .suo files deletion is harmless and only implies to recreate my windows layout plus the starting project and a few other non critical customizations.

---

I was also facing this issue, below are the steps that I perform and it works for me always:

Deleting the solution's .suo file.

Deleting the Temporary ASP.NET Files (You can find it at find it at %WINDOW%\Microsoft.NET\Framework\\Temporary ASP.NET Files)

Deleting all breakpoints in the application.

---

I don't know if you're still having this issue, but I debug sites in Visual Studio by attaching the debugger to the process itself rather than letting VS do it for me and I have found it to greatly improve times. I use an extension for VS called AttachTo and I have a small article on how I use it here.

I hope this helps.

---

My slow VS issue was resolved by disabling the Browser Link

https://i.stack.imgur.com/mSMkg.png

---

If someone notices this behavior coming out of left field, check to make sure you don't have any breakpoints set in web.config. I must have set one with a stray mouse click, and it really slowed down all debug operations.

---

After spending all day waiting for symbols to load as slow as turtle speed, mixing and switching between all the possible combinations: Just My Code, Caching symbols, Intellitrace, Just-In-Time, killing processes, etc.

My solution was actually to disable the antivirus. Yeah, Windows Defender was slowing my project launch! It would check all the dlls as Visual Studio requested them and slowed the whole symbol load process.

I have to say our machines have great specs to compile the solution really fast, so that was never a problem. We code in VS 2013 Ultimate.

---

Emptying the symbol cache worked for me.

See: menu bar / Tools / Options / Debugging / Symbols / Empty Symbol Cache

---

In Visual Studio:

Tools -> Options -> Debugging -> Symbols

Choose "Only specified modules". Click the "specify modules" link, and add a blank module (click the new document button and hit OK).

---

to Clear cache etc. use Options 1 & 2; for settings/troubleshooting Options 3 & 4, enjoy!

Option 1: Navigate to IIS express , clear cache and sites

cd "C:\Program Files (x86)\IIS Express\"

run this appcmd.exe list site /xml | appcmd delete site /in

run this Del /S /F /Q %temp% - to clear the Userprofile Temp folder.

run this Del /S /F /Q %Windir%\Temp

Also, clear your temp files in %temp% and logout, or reboot

this clears the Windows temp folder. This will delete all the sites, enjoy!

Option 2: remove/recreate the temp folders

Cmd> rmdir C:\Users\\{username}\AppData\Local\Microsoft\WebsiteCache /s /q

Cmd> rmdir C:\Users\\{username}\AppData\Local\Temp /s /q

Option 3: JMC (Just My Code) Option from MSDN

To enable or disable Just My Code in Visual Studio, under Tools > Options (or Debug > Options) > Debugging > General, select or deselect Enable Just My Code.

https://i.stack.imgur.com/myJIv.png

Option 4: configure the Visual Studio/Disable Common plugin issues

Even more Visual Studio settings You can also configure the Visual Studio and disable resource-killing features on the environment, cant remember where I got this, but threes some more I will post shortly.

Environment -> General

Uncheck “Automatically adjust visual experience based on client performance”

Uncheck “Enable rich client visual experience” Check “Use hardware graphics acceleration if available” Environment -> AutoRecover

Uncheck “Save AutoRecover information every”

Environment -> Documents

Check “Save documents as Unicode when data cannot be saved in codepage” Environment -> Keyboard

Set “ForceGC” to ctrl+num1

Set “ReSharper_Toggle” to ctrl+num0 (if ReSharper is used)

Set “ReSharper_EnableDaemon” to ctrl+num8 (if ReSharper is used) Environment -> Startup

Set “At startup” to “Show empty environment at startup”

Uncheck “Download content every” Environment -> Synchronized settings

Uncheck “Synchronize settings across devices when signed into Visual Studio”

---

Asp.net core debugging was painfully slow because of unknown VS extension had replaced default Just in Time debugger.

I have found such message in the OPTIONS\DEBUGGING\Just-In-Time configuration tab (as warning text). Another debugger has registered itself as the Just-In-Time debugger. To repair, enable Just-In-Time debugging or run Visual Studio repair.

Description: https://msdn.microsoft.com/en-us/library/ssc8234s.aspx?f=255&MSPPError=-2147217396

Returning back the default JIT debugger (just checked Managed option that was unchecked) solve all my problems.

---

In my case I noticed that disabling my internet connection would make it run as fast as with ctrl-f5, so I went to debug->options->symbols and just unchecked all .pdb locations.

Seems like VS was trying to connect to these servers every time a debug session was launched.

Note that disabling Debug->Options->Debugging->General "Enable source support" or "Require source files to exactly match the original version" wouldn't make any difference.

---

Similar problem wasted better half of my day!

Since solution for my problem was different from whats said here, I'm going to post it so it might help someone else.

Mine was a breakpoint. I had a "Break at function" breakpoint (i.e instead of pressing F9 on a code line, we create them using the breakpoints window) which is supposed to stop in a library function outside my project.

And I had "Use Intellisense to verify the function name" CHECKED. (Info here.)

This slowed down vs like hell (project start-up from 2 seconds to 5 minutes).

Removing the break point solved it for good.

---

One thing that worked for me after doing all the above was: In the Threads window (Debug->Windows->Threads), set Group by to None. This can only be done while debugging.

This was having an impact even after closing that window.

---

Open the solution folder in windows explorer, close the visual studio, delete .suo file from windows explorer.

Now open the project in visual studio, hopefully debugger will attached/detached fastly.

---

For me it was conditional breakpoints. Those seem to really slow things down.

---

Go to your environment variables and look for the key _NT_SYMBOL_PATH.

Delete it.

Voila, worked like a charm.

---