VS 2017 - Very slow (laggy) when debugging

When I debug my solution, vs 2017 is very laggy and slow it's like it has to operate something heavy in the background.

So it stops "responding" every 5 seconds for 2 seconds, which is very annoying. Any suggestions?

EDIT (tried suggestions):

  • Browser Link is turned off
  • Stopped customer feedback
47245 次浏览

After some additional investigation I found this thread Unchecking Enable Diagnostic Tools while debugging in Tools → Options → Debugging → General did the trick!

Unchecking Enable JavaScript debugging for ASP.NET in
Tools → Options → Debugging → General
makes a huge difference in performance.

If disable Diagnostic Tools don't fix the problem try to disable IntelliTrace, Unchecking Enable IntelliTrace, in Tools -> Options -> IntelliTrace. Work for me.

I gave up getting Debug=>Attach To Process working... even tried ALL the solutions on this SO post (2-pages worth).

Solution

Use ReAttach VS IDE Extension. This bypasses the need to ever use the Attach to Process dialog again if it's a process you've recently attached to.

enter image description here

If you are using VS 2017 Enterprise edition, try disable IntelliTrace feature (Tools -> Options -> IntelliTrace)

with this feature turned off, the laggy behavior went away even keeping the Diagnostic tools turned on (Tools -> Options -> Debugging -> Enable Diagnostic Tools while debugging)

I have tried disabling few things myself just to see what is causing it. The only thing that did work for me is Tools > Options > Debugging > General > "Enable JavaScript debugging for ASP.NET (Chrome and IE)".

I'm using VS2017 Enterprise v15.2 for Asp.net WebForms.

Hiding the Threads window did the trick for me.

I experienced same problem. In debug mode, my webforms project ran very slowly. When using Ctrl+ F5, it ran quickly (as it does when deployed). I found a try/catch block that was executing 45 times. It wasn't doing anything, it was just trapping an error that I had made. I fixed the error and, when removing the try-catch block - voila! -- back to full speed.

So if you're experiencing this problem and you've tried all the solutions above (I did), look for a try catch block that is firing often. [ Fix your error :) ] and then remove the try-catch block. I can't believe the difference it has made. Shouldn't have made any difference at all, of course, since the try-catch block wasn't doing anything, but it did.

I also experience the lag when "Enable Javascript debugging for ASP.NET (Chrome and IE)" is checked. And Turning off the "Enable Diagnostic Tools while debugging" did not help.

However, I also noticed that when I F12 for Chrome Developer Tools, then lag time goes away and the app performs.

Hope this helps.

Sometimes it is because of a Realtime scan in Antivirus.

"Add exceptions" Visual Studio files/folders for your Antivirus

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ Common7 \ IDE \ devenv.exe

C: \ Program Files (x86) \ Microsoft Visual Studio \ 201

Only one thing that helped me was disabling Debugger option of Resharper. If you use Resharper, try to UNCHECK "Show local variables values in editor" in menu: Resharper -> Options -> Tools -> Debugger.

Resharper's Debbuging options

It helped for me.

What worked for me was removing all the following folders in the solution's directory:

  • .vs
  • x64
  • Debug
  • Release

workaround that I used was to run msvcmon.exe locally with admin mode before starting the debugger. Then start the attach window and providing the remote debugging port.

I had this problem where the program was running slower if started from visual studio, turned out to be too many threads, like alot of new System.Threading.Thread() in a loop etc. I switched the code to use the ThreadPool instead with Task etc and the slowness went away.

choosing "Load only specified modules" did the trick (Tools=>Options=>Debugging=>Symbols)

I also had this problem, for me helped disabling Enable Edit and Continue options in Tools → Options → Debugging → General.

In my case I had a break point with a condition that was never met. I had forgotten about about this break point altogether. Sometimes adding a simple condition to a break point can slow down the debugging speed a lot.

Just adding this in case it might help someone.