Visual Studio debugging/loading very slow

Question

I'm at wit's end. Visual Studio is typically painfully slow to debug or just plain load ("start without debugging") my ASP.NET MVC sites. Not always: at first, the projects will load nice and fast, but once they load slow, they'll always load slowly after that. I could be waiting 1-2 minutes or more.

My setup:

I'm using Visual Studio 2012 Express, currently, but I've had the same problem in Visual Studio 2010 Express as well. My solution is stored on a network drive; specifically, it's My Documents redirected to a network drive, if it matters. (It shouldn't. There are times where my site loads very fast under this setup.)

I load in Internet  Explorer 9 usually, but the same problem happens in Firefox.

This can happen in any ASP.NET MVC project I work on, and it seems to revolve around having DisplayTemplates, which all my ASP.NET MVC projects do. And it's all C# and Razor if that mattered.

Symptoms:

The system will load my symbols hundreds of times. Basically, the following, but there are at least 300 such rows, each with ever-so-slightly different DLL files for the same CSHTMLs:

'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.xighmhow.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_contact.cshtml.22013bb9.cv5hktkf.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.1o77hs8i.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.jja-77mw.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.l_e9ev_s.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.b4n59gom.dll', Symbols loaded.

In the above, I've got three DisplayTemplates: "Contact", "Location", and "StatusCode". It appears that IIS is loading symbols twice for each time the display template gets called. Thus, if I'm displaying a table of 100 entries that call all three of these display templates, it's 600 separate symbols loaded.

This isn't a fast operation either. The log files that IIS generates take about 200  ms for each symbol to load. Thus, super-long delays.

What I've Tried:

• Debug or Release version, it doesn't matter.
• Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
• Cassini, IIS  Express 7.5, and IIS  Express 8.0 all have the problem.
• Delete All Breakpoints does nothing.
• Clean Solution, or deleting the .suo also do nothing.
• If I repair IIS  Express/ delete the My Docs\IISExpress folder, or repair/reinstall Visual Studio → the issue MAY go away, but only for a while before it comes right back.

Any advice at all is appreciated.

To answer more questions, yes my machine definitely has horsepower. The infuriating thing is that the same project, with NOTHING altered, can sometimes load very quickly, typically after I repair IIS  Express and delete the My Docs\IISExpress folder. Eventually, "something" happens and it's down to 2 minutes to load again. What I'm working on is not a complicated project. No external libraries or dependencies and my VS.NET has no add-ons whatsoever.

Of note, this machine has Symantec Endpoint Protection, which has a history of causing havoc. But disabling it outright (it's good to be an administrator) did not fix the problem.

I have a theory at this point. I'm thinking this is all because I'm working off a redirected folder off a network share. While the debugger was going through its hundreds of "loaded symbols" lines, I paused to see what it was doing. It was in my code, loading the DisplayTemplate I had. Stepping into the template output this:

Step into: Stepping over non-user code 'System.Threading.WaitHandle.InternalWaitOne'
Step into: Stepping over non-user code 'System.Threading.WaitHandle.WaitOne'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCapture'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromFileBatch'
Step into: Stepping over non-user code 'System.Web.Compilation.AssemblyBuilder.Compile'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.bciuyg14.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.CompileWebFile'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultInternal'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerWrapper.System.Web.Mvc.IBuildManager.FileExists'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.GetPathFromGeneralName'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.Find'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.Html.TemplateHelpers.ActionCacheViewItem.Execute'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\App_Web_statuscode.cshtml.22013bb9.kwj3uqan.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.RuntimeType.CreateInstanceSlow'
Step into: Stepping over non-user code 'System.Web.Mvc.DependencyResolver.DefaultDependencyResolver.GetService'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerViewEngine.DefaultViewPageActivator.Create'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerCompiledView.Render'

It looks like Visual Studio is recompiling my display template every time it's called, which is again, hundreds of times. My theory is that Visual Studio compiles the file, saves it to the network share, then somehow stamps a new time on it, and Visual Studio then thinks the file has changed. Thus, Visual Studio recompiles it yet again. Only a theory though; I really have no clue.

For one, apparently, I have offline files (this is a desktop computer in an office; I couldn't care less). I'm going to disable, reboot, and retry tomorrow.

Plus, moving my project, as is, to the local C: fixes it. It loads very quickly. But this is not ideal in a work environment. I lose Previous Versions, my code isn't backed up at all unless I manually copy it, and it's no longer shared with anyone.

I can make do with copying it back and forth from C to the network share if it comes to it. It's much more annoying to wait two minutes for every page to load.

Toback

I have lots of questions: What about the machine you are running it on? Does it have enough horsepower for what you are trying to do? Do you have any third party plugins? What kind of antivirus do you have? – Br

Updated my question with more info. – Harmon

Removing offline files only seemed to be the fix. It worked great for a while, then problem came back. But I have another possible answer. Updating my solution. – Harmon

To second the antivirus question, I had major issues with ThreatFire running. Temporarily turning it off sped the debugger back up for me hundredsfold at least. Turning off my main AV (Avast!) only helped slightly. – Degreeday

@JohnSaunders Did you try running it in administrator mode?: #36322940 – Aborn

Check your CPU FREQUENCY and CORE TEMP!!!! My computer was running at 20% capacity now everything is amazing again after reseating my cpu with some new thermal paste. – Gasholder

Answer 1

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.

Lanitalank

Awesome that fixed it for me too. I had turned all of that symbol stuff on a while ago to step through the MVC source – Necrology

No fix for me I'm afraid. This would be a good solution for those revolving around issues with Microsoft symbols. Unfortunately for me, my problem seems to revolve around my own symbols. Those symbols already cache locally, and for some reason, compiled hundreds of tiles in just one page load. – Harmon

thanks for this tip one problem i am having here is the load all symbols button is disabled for me any ideas? – Younker

@ChrisMcGrath try this link social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/…. Btw thanks for the great answer – Resupine

Ok, seems this is helping most with this problem so I'll mark it as the solution. Personally, I just gave up working off a redirected network share and do my coding locally now & manually back it up. A pain, but far less a pain than waiting 2 minutes for every page load. – Harmon

Where do I send you a paycheck for the incredible amount of time saved for me? – Paratyphoid

Tried this on a Windows Server 2012 (8 GB) + VS 2012 + SharePoint 2013 and it did not help.. Any suggestions please? – Maximalist

even after following your steps, the "Load all symbols" button is hidden and I cannot click that. What should I do now? I am using VS Express 2012. – Malamute

I just performed the first 2 steps here and it works much faster. Seems like previously I had unchecked that box. – Michaelamichaele

Here is solution for those who have button Load all symbols disabled: Button is only available while debugging. – Mirianmirielle

This didn't help me. I found the following solution working for me. Choose remove all breakpoints: #3378220 – Polarimeter

@Polarimeter Yes! Perfect. Went from a 45 seconds start up to 1. Thanks muchly. – Dharana

Unfortunately not a fix that worked for me. VS2013 is still sometimes extremely slow at starting up and running in debug mode. – Horal

I followed the above steps... It helped me on VS2010. Thank you so much. – Alternation

This issue was really painful, I followed steps provided by you and without deleting any temporary files and restarting VS, debugger is loading perfectly. Kudos!! to you Zeb Kimmel. – Monarchal

How could this solve the problem when it was occurring during a release build? – Chrestomathy

This stuff with turning off windows defender helps me! – Brom

This just helped me resolve the same issue for Visual Studio 2015. Thanks! – Patricepatrich

How long should it take to load all symbol? It's been running for minutes now. – Basaltware

The problem is now, everytime you debug it takes forever to load symbols. – Sandlin

where is this "Load all symbols" button? – Airborne

@Airborne in Tools -> Options -> Debugging -> Symbols, mind that it's available only during while debugging – Paloma

This saved my project. I ended up with 30+ seconds to run relatively small app. Really annoying. Now it's almost instant. I actually noticed change straight away when i changed symbols folder. Maybe old one was "corrupted" Thanks! – Cupriferous

This significantly increased my startup time. – Dongola

"CHECK the checkmark next to Enable Just My Code" does not specify whether to check it or uncheck it. – Fasten

Dear poster. I could kiss you. You just saved my bacon. – Heartache

Answer 2

Turning off intelliTrace fixed this for me.

In Visual Studio, Tools -> Options -> IntelliTrace

Then, uncheck the checkbox for "Enable IntelliTrace".

Ericerica

This worked for me. Intellitrace slowed VS2012 to a crawl such that a brand new MVC4 site would timeout on first run. – Lifeguard

I had this problem when stepping through one of my unit tests. It took about 300 seconds with intellitrace turned on and about 14 seconds when it was turned off. This fix really worked for me. – Impressure

Improved my startup from 25 secs to 6. I think it helped a lot because I was running a lot of my own code on application start – Pointenoire

Goddamnid... From 1 min to 10 seconds. It's selected by default in VS2012 Ultimate. Watch out guys – Sub

This also improved my code speed tremendously. All "deep" code was able to run much faster. – Applegate

Can`t find Intellitrace in Tools => Options. .. i have vsComunity 2015 – Bemock

also, vs is slow a bit when trying to open a file – Bemock

In Visual Studio 2015, Intellitrace exists only in VS 2015 Enterprise Edition. – Tasset

Solved it for VS 2017! Awesome! – Alkalinize

I have VS 2013 and it has IntelliTrace too, and the proposed solution worked for me just right now, by the way. – Corycorybant

Answer 3

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.

Spud

I started having this problem in VS2010 out of a sudden, and it was, indeed, one of my breakpoints that was causing it. As soon as I cleared my breakpoints, it became fast again. – Noblesse

Wow..VS2012 was crawling, 5 mins just to build a simple project. Cleared all the breakpoints and it's lightening fast again, thanks!! – Brewage

After reading this and following what you said, I found a breakpoint that somehow got placed in the XML code of one of my edmx entity files. You da man/woman. – Exothermic

Thanks a ton. This resolved my issue with very slow performance of VS2010. – Bowler

This also worked for a slow debugging problem I had in Visual Studio 2015. – Agrestic

I've been struggling for the past few hours, this has been a life-saver! Thanks a ton! – Lend

Answer 4

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

Substance

C:\Users\{USER_NAME}\AppData\Local\Temp is the path and "AppData" folder is a hidden folder – Scruffy

I found 1GB of old crap here....delete it all and VS running a little better. :) – Considerable

Answer 5

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

Supernumerary

This worked. "AppData" folder is a hidden folder, just in case, someone is unable to find it. – Scruffy

This is the one! It works so well that I now make it happen automatically when I log on to Windows: I have added a file called DeleteVisualStudioCache.cmd to C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup with the following commands: rmdir C:\Users\{username}\AppData\Local\Microsoft\WebsiteCache /s /q rmdir C:\Users\{username}\AppData\Local\Temp /s /q pause – Johnnie

I did all the previous answers on this page from the top one down, and this was the one that worked. possibly its doing something in conjunction with a previous answer to make this work, but amazingly clearing the cached files does make symbol loading quicker for me. dont skip over this answer thinking it won't be that. been struggling with this for a year, and now the app loads in 1 second after hitting F5. ridiculous problem, amazingly useful answer. – Louisville

Answer 6

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).

Swett

Uhmmm... very nice answer. I was on the same boat. I also enabled FusionLog a long time ago and forgot to disable it. Now debugging the ASP.NET MVC app is a lot faster. Thanks God and @rkawano. :) – Auriga

Can't find the "ForceLog" key - guess it's gone in Win10? – Lenticel

@ChristopherD.Emerson If you are not seeing this key, you certainly haven't enabled fusionlog. – Swett

Answer 7

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.

Toback

I know this is a bit old news, but I had this same problem. My team suggested I use a build script that copied over files from my local source to where the files were being run and every time I ran that subroutine by itself it would create a conhost.exe and not close it. Once I ended all the extra copies of that it ran lightning fast again. – Jaine

Answer 8

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

Debug -> Delete All Breakpoints

Cupule

Answer 9

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.

Laryngeal

This fixed my problem as well. I was getting complete system lockups when trying to debug, especially when using the QuickWatch window. LastPass Toolbar needs to be disabled. (IE 10.0.9200.16635) – Euphroe

And this is why I love StackOverflow. But LastPass should fix this - I'm emailing them now to let them know. It's obviously still a problem with VS2013 and IE 11. Disabled LastPass and back to normal. Thanks to UserBlueOne for the info - can get on with work again. – Thao

FREAKEN LASTPASS! My keyboard was completely stuffed when debugging in VS 2012 with my MVC app. Disabled LastPass and everything flew again. THANKS! Upvoted. – Belford

In Win8.x with IE if you use MS account for login you can have it sync your logins so no need to use LastPass but still have (partially) the benefits, :) – Beverleybeverlie

This … worked for me. Please note that it is now 2019---six years later---and I'm using the LastPass plugin with Microsoft Edge. – Delois

Answer 10

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

Dekker

Thank you for posting. This actually did more to improve my performance than the accepted answer. – Villain

@Toback can you try this one and share with us your results? – Dekker

compilation goes inside system.web – Uyekawa

Confirmed to work for large solution and web application (MVC) within. – Stableman

Answer 11

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

Quasi

Answer 12

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

On "Visual Studio 2012" go to:

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

Hope it helps.

Similar questions: 1, 2

Sodomy

Mine's already set to that unfortunately, so no fix for me. But could be good advice for others to try. – Harmon

That fixed it for me! – Resurrectionism

Answer 13

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.

Brunner

I found out the hard way that this was causing my problem too. Only after disabling the extension did I look to see if anyone else had noticed it. – Creosote

Answer 14

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.

Phocis

This one is the most fastest one – Gerladina

Answer 15

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.

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.

Meroblastic

I just realized that I got vs slow after power outage as well, thanks so much for this answer. – Athalee

look for a .vs folder in later versions of Visual Studio. Delete that. – Illstarred

Answer 16

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.

Monarchal

Restarting made it take 5x longer than normal instead of 10x longer than normal. Deleting the .suo file made it nearly instant startup. Thanks! – Millenarianism

Seems like deleting .suo file worked. Any reason deleting this files helps boosting performance.? – Fineman

@Fineman .suo contains a lot of information such as which files are currently open in the IDE, debugger info, local settings, etc. And when this files will corrupt, vs start consuming more CPU usage which leads to VS slow and even hang in some cases. – Monarchal

Answer 17

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.

Quadrivial

Answer 18

My slow VS issue was resolved by disabling the Browser Link

Unsaddle

I know "Thank you" comments are a bit frowned upon here, but seriously, THANK YOU SO MUCH. This one change took the program I'm testing from slow to the point of being unusable to essentially instant reactivity. You probably bought me about an hour or two per day of productivity just for not having to wait around for things to load – Anthotaxy

@Anthotaxy you're welcome - one of those MS default settings you need to watch out for :) – Unsaddle

It's not necessary to disable it, see my answer => https://mcmap.net/q/48012/-visual-studio-debugging-loading-very-slow – Pennate

Man thaks a lot! I can work muuuuuuch better now, as brazilians says: 'you are the guy'!! – Topdrawer

Answer 19

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.

Bettiebettina

Just had this exact same thing myself. Nearly drove me crazy. Why on earth does an inactive breakpoint in a web.config file completely break debugging? – Dizon

Answer 20

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.

Brottman

Yeah, turning off windows defender works like a charm! To permanently turn off windows defender in Windows 10, set Start="4" (4 is for disabled) in the RegEdit path HKLM\System\CurrentContolSet\Services\WinDefend – Brom

Having the issue with AVG antivirus. Has anyone worked out if a particular folder can be excluded from antivirus to resolve the problem, please? I've cached symbols, and have excluded the symbol cache folder - but this made no difference. – Johnnie

you can keep the AV and exclude from analysis certain path and targets (VS and your projects) – Juristic

Answer 21

Emptying the symbol cache worked for me.

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

Afrika

Answer 22

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).

Consolatory

Answer 23

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.

---

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”

Surbased

Thanks, this worked. Also resolved localhost ssl issues for me. – Modulus

Answer 24

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.

Myrnamyrobalan

Answer 25

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.

Template

Fixed it for me in VS2019 Community (i.e. years later!) - many thanks. Does anyone know how another debugger registers itself? Is this fall out from remote debugging? – Geophysics

Answer 26

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.

Preponderate

+1. I wouldnt recommend it though. See here what it means: #8175300 – Humiliate

Answer 27

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.

Pakistan

Answer 28

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.

Sensualist

Answer 29

Please make sure you haven't opened Visual Studio in administrator mode

I faced this issue and had to run in normal mode.

Lunn

Unfortunately running as administrator is required if you have your projects set to run in IIS. – Stroll

@NelsonRothermel Which version ? Not anymore (VS2017). – Juristic

@Soleil: In VS2017 it's still required. IIS runs as a Windows service (or set of services) and not in the user space. You may be referring to IIS Express which doesn't require administrator rights. I'd generally recommend you use the latter, especially in an organization that locks down machines, but it does have a few downsides. – Stroll

Answer 30

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

Paulownia

Indeed they do. But only if the lines containing them are actually executed. – Meghan

Answer 31

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

Delete it.

Voila, worked like a charm.

Fixative

value == symsrv*symsrv.dll*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols still no dice! – Tartarean

Answer 32

The problem for me was the "Browser Link" feature that is very heavy when you have several tabs open for the same project !

Because every time we launched the project, it opens a new tab with browser link communications.

Just close all tabs associated with the project and keep only one open !

This free instantaneously visual studio ! It’s magic ! ;-)

“Browser Link is a feature since Visual Studio 2013 that creates a communication channel between the development environment and one or more web browsers. You can use Browser Link to refresh your web application in several browsers at once, which is useful for cross-browser testing.”

Pennate

Answer 33

A quick and easy solution for those who don't have much deviation from default VS settings.

Tools-->Import and Export Settings-->Yes, save my current settings-->Visual C#

I am sure the above solution would work with other default settings too. In my case something messed up with my symbol loading settings but I could not fix it even though I tried quite a few of the suggested solutions.

Carr

Answer 34

There is also complications in partial views where there is an error on the page that is not recognized immediately. Like Model.SomeValue instead of Model.ThisValue. It might not underline and cause problems in debugging. This can be a real pain to catch.

Laryngeal

Answer 35

I had accidentally selected the option "Show Threads in Source". On unselecting stepping through the code was normal.

Dora

Yes, this fixed it for me too. It's mentioned here also (I think this is the same registry setting). – Dissociate

Answer 36

I finally fixed (or at least, improved a lot) this problem by making this changes in the local IIS configuration:

1. Open IIS configuration
2. Click into applications pools
3. Right click into each pool and open advanced configuration
4. Make sure that "Enable 32 bits apps" is set to TRUE and Startup mode is set to AlwaysRunning

Hope this helps someone, because I was starting to go crazy trying to fix the slow debug problem

Curly

Answer 37

For me it was that I was debugging in Managed Compatibility Mode. In Tools -> Options -> Debugging -> General at the bottom, un-check 'Use Managed Compatibility Mode'. Debugging became instantaneous where it used to take up to a minute to step through one line. I suspect that's what the 'Managed' means in OP's snippets above.

More on that here: https://blogs.msdn.microsoft.com/visualstudioalm/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/

Chamomile

Answer 38

Your "My Documents" folder mapped to a network share?

Startup of IIS Express can take minutes instead of seconds if this is the case even if your solution is local instead of on the network share. In regedit.exe, verify that HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User ShellFolders\Personal is pointing to %USERPROFILE%\My Documents.

If it's not, change it or ask your network admin to make an exception to your policy.

Adermin

Answer 39

I was having this problem with VS 2013. For months my tests had been debugging fine, but suddenly the dreaded Loading symbols messages were appearing, and I wasn't aware of anything I'd done to cause it.

Nothing suggested here or on any other internet page helped me. I tried everything at least 10 times. Deleting the .suo file didn't help, but in the same location were two files with .testsettings extension and one with .vsmdi extension. These files appeared to be obsolete, perhaps a relic from VS 2010. The team member who'd created them was long gone.

I found that I could delete all three of these files without a problem. I figured out that it was enough to just remove a particular one of the .testsettings files to stop the Loading symbols messages. My nightmare is over.

Amparoampelopsis

Answer 40

I set up my Visual Studio in a new job with C# as the default language. It hadn't yet dawned on me that I was doomed to be programming in VB.

I forgot about the C# default because VB seemed to work fine. However, stepping through code was taking a ridiculous amount of time. After trying a number of fixes, in desperation I changed the default language to VB... bingo!

If you've got down this far, it's definitely worth a try.

Carlie

Answer 41

For me the problem was Avast Antivirus. I uninstalled it and ran with Windows Defender instead and everything works fine. In my solution I only had this problem when running Windows applications, either WinForms or WPF. It was never slow on web applications for some reason.

Valeriavalerian

Answer 42

My solution was simply to reload a saved GOOD (backup) copy of my settings (made a year ago). Worth trying before resetting everything to blank. My VS2010 would take 60 seconds to start debugging and approx. 3 minutes to stop debugging. I saved the corrupted settings and to my surprise they were over 3MB instead of 260Kb. I loaded the good backup copy and everything is great again :-)

Gene

Answer 43

Each time I recompiled to local host while developing it took several minutes. It was terribly frustrating. After trying umpteen fixes including putting it all on an SSD. I found what really worked. I created a ramdisk and put the whole project in it. Recompiles to local host are now under ten seconds. Perhaps not elegant but it really worked.

Cake

Answer 44

This might help someone, I had the same issue and found out that i had SD card with drive e:\ After removing my SD card the problem was fixed

Reduced

Answer 45

My problem was due to the project being built each time I started debugging. All other solutions in this thread helped slightly, but still resulted in me having to wait until project finished building.

My Solution to avoid the build each time you start debugging:

• Go to Solution Explorer - > Right Click Your Solution File - > Click Properties

• In the Property Pages - > On the left, choose Configuration - > and Uncheck Build

• Click OK

• Ensure you have visual studio open as Administrator

• Go to Debug -> Attach to Process

• CLICK checkbox Show processes from all users -> Find and Select process called w3wp.exe -> Click Attach -> when warning comes up, click Attach

Now you can navigate to the page you are wanting to debug in localhost, and if you have break points set in your file, you can immediately begin debugging without having to wait for your project to build!!

Nipha

Answer 46

In my case,

I realized that remote debugging runs and consumes most of the resources. I did not really need to make the app 64 bit so after forcing it to be 32 Bit, remote debugging did not run and the execution was faster.

Ford

Answer 47

In my case the problem was an external running exe file - namely:

WUDFCompanionHost.exe

under the name of

"Windows Driver Foundation - User-mode Driver Companion Framework Host Process".

Process, which has taken a steady 10% of the CPU. Killing it helped directly and withing a second the page has loaded.

Original

Answer 48

Yet another possible cause is pre-compilation of old projects that exist on the file system but have been removed or partially removed from visual studio.

I had a solution that was taking 3.5 minutes to load after a build, I had a look at the timestamps in Temporary ASP.NET Files and saw that the 3 minute delay was on a file in an old project. Had a look in VS & the project was "unavailable". Deleted it from VS, deleted from the file system, and now we're down to a sweet 8 seconds.

Galenic

Answer 49

Deleting .vs folder inside solution folder fixed the slowness for me in VS2019.

Creese

Answer 50

As title says, VS debugging is slow. I can't find my problem, so post it here, may be it helps someone.

In my case slow debugging was on the website hosted in IIS.

• VS 2019 (16.4.4)
• VS 2017 (15.9.19)
• Windows 10 (1909)
• IIS (10.0.18362.1)
• Edge (44.18362.449.0)

At first time after site loading it works fine, but after 1+ minute it become lagging. Requests are pending for 1-2 minutes (F12 network tab) before my breakpoints can handle them. It was in all my active browsers.

Solution: Do not use Edge with IIS while debugging.

To understand where the problem i spent about 4-5 hours. I used Edge + Chrome for my workflow. For now i use only Chrome (with separated user profiles).

Link that helped me: https://answers.microsoft.com/en-us/windows/forum/all/iis-running-very-slowly-after-windows-10-upgrade/dae433ba-4efe-45ab-aa66-824e6fa92b51 "J Marcos" answer.

Adriene

Answer 51

Another last resort solution with respect to time is to repair the VS installation.

• Go to Tools => Get Tools and Features
• Locate the existing VS installation, and choose repair under the more button.
  • For example: Visual Studio Enterprise 2019 installation.

Patois

Answer 52

For me simply IIS was not running. Open IIS, spread Sites and "start" the Default Web Site.

Animus

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Worried

Answer 53

I solved the issue by unchecking the following Debug option:

Debug > Options > General > Enable Disgnostic Tools While Debugging

Crosslink

Answer 54

Restart your computer

I know it sounds far too simple but it was the only thing that worked for me.

Wells

Having been through this entire topic, I can say that there IS a persistent Windows condition that crops up and leads to slow symbol loading. Maybe it's some kind of resource exhaustion, I don't know (it's not obvious). It doesn't seem to affect anything to the point where there is a failure - but it DOES cause symbol downloads to be slowed way down. And yes, a reboot clears it right up. After 22 days uptime I have this condition and I'm investigating it right now before resorting to reboot. – Chaiken