问题
In my Visual Studio, even I just wrote a single line of return in a C# console application, it will take me a minute after pressing F5 to execute the actual code (I mean the time it takes to stop on the single return statement after pressing F5 -- I set a breakpoint on return statement in Main function). I am wondering what is wrong? Any check list? Thanks!
I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.
thanks in advance, George
回答1:
You may need to delete all your breakpoints---note that you need to click the "delete all breakpoints" button (or use Ctrl-Shft-F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?).
If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
回答2:
I have seen this before. Try deleting all your breakpoints and then set the ones you want. Hit F5. Is it faster now?
I just noticed that you mentioned setting up .NET source debugging feature. Try to disable that, your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in Tools > Options > Debugging > Symbols
Also try disabling "Enable property evaluation and other implicit function calls" in Tools > Options > Debugging > General.
回答3:
Or remove your .suo file which can be found next to your solution (.sln) file. This solved an issue I had with debug sessions taking a long time to start and stop.
回答4:
Had this problem. After trying all the listed advice and removing all visual studio extensions, we finally figured out that somehow IntelliTrace was enabled. Disabling that fixed everything.
http://msdn.microsoft.com/en-us/library/dd264948%28v=vs.100%29.aspx
回答5:
Do you have a lot of breakpoints set? Those can really slow down startup time. Everytime a new module is loaded into the process address space, they all need to be checked to see if they are valid.
回答6:
Go to tools/options/debugger/symbols and check if you have public symbols set or UNC network paths set. Also check tools/options/debugger/general to see if you have source server set.
All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
回答7:
My colleague had a very slowly responding Visual Studio, it literally took minutes to perform a step while debugging. The root cause turned out to be an anti virus program (threatfire) that went crazy while VS was running. Killing its process immediately fixed everything.
回答8:
In my case changing debug symbol "Automatically load symbol for" option from "all modules" to "only specified modules" solved the problem. You can change this option from Tools -> Options -> Debugging ->Symbols
回答9:
A different cause plus... How to find the problem
To me it was the option ShowOtherThreadIpMarkers. A value =1 makes vs (2010) unbearably slow (3-5 secs for each debug step. With a value of 0 is fast again.
What is it that option? I have no idea. I could not find it through the vs user interface. I unchecked all possible debugging options in there and nothing worked.
So I went to Import Export Settings and loaded my old settings I've previously saved going backward in time until vs was fast again, then compared the vssettings files... etc, etc.
I'd like to remark that if you load the settings while you are in debug mode stopped on a breakpoint, they become effective immediately. You don't have to stop the debugger and restart.
回答10:
From ScottGu's blog linked by Travis: "One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue."
回答11:
Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
回答12:
Are you using a Symbol Server to download symbols for Windows DLL's?
If so disable that as it can take some time but I wouldn't expect that to cause long delays in a basic console app.
Tools > Options > Debugging > Symbols
回答13:
I know this is an old topic but for what it's worth...
I've found that if I've had a seperate IE window open for a long time it can take up to a minute to start debugging. Close all IE windows and debugging starts immediately.
回答14:
In my case Google Toolbar was slowing down my debugging. gplus_notifications_gadget.html just kept going on and on overloading the debugger. I wanted to keep the Google Toolbar because I use it on a regular basis, so I just disabled the G+ notification button (the small button besides the profile button.) It is happy now.
回答15:
Running under the debugger for me was roughly 10x slower than running without debugging.
After trying every solution suggested here, I went through every debugger setting and enabled/disabled to see if it made a difference.
For me, it turned out that disabling Suppress JIT optimization on module load in the debug settings massively improved things.
回答16:
I had the same issue in VS2010, with stepping in the code excruciatingly slow (between 3 to 10 seconds). However, none of the above settings modification did the trick. I eventually found the ultimate solution, which would work in all of the above post issues: reset all your settings, as described here.
You may first want to save a particular part of your settings, for instance I first saved my color theme (Solarized-like), then restored it after the global reset.
回答17:
For me, the setting that killed performance (windows 8 even hanged except for mouse movement) was to UNCHECK "Break all processes when one process breaks" in Options -> Debugging -> General.
Hope this helps anyone.
回答18:
Just one more cause of a slow Visual Studio debugging experience...
Long time ago I enabled FusionLog to see what was causing an assembly binding problem.
Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.
This is the FusionLog key on Window's Registry [ regedit.exe ]:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Change ForceLog, LogImmersive and LogResourseBindings values from 1 enabled to 0 disabled.
回答19:
I had this problem too, but it had nothing to do with breakpoints in my case. It was code shortcuts that I added in the tasks window:
http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines
I'm sure there are other ways you could see a problem like this, but there is a bug somewhere that caused this problem for me...deleting all my options would have fixed this, but that is something that I did not want to do. So, I debugged it and wrote about it in my blog...your problem sounds like mine.
Thanks.
回答20:
Something that has worked for me is to make sure there are no conditional break points. Other then that, I have had success fixing slow debugging by simply restarting visual studio and only opening one instance of visual studio at a time. Hope it helps somebody...
回答21:
I had a similar issue and none of the other guidance seemed to help. I had rebooted to no avail. I had removed all breakpoints, deleted the suo file, checked that symbols weren't being loaded from external sources, and checked that no paths existed in the application that was unavailable.
Then, I thought to clean the solution. I noticed in the output window that C# IntelliSense reported an issue when cleaning:
There was a problem reading metadata from '{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}' ('The system cannot find the file specified.'). IntelliSense may not work properly until the solution is reloaded.
In this case, once you actually discover the error message, it tells you exactly how to resolve it. (Good job on the error text, poor job on discoverability!) I unloaded the solution's projects, then reloaded them. I was then able to successfully run clean solution. It worked, and the debugger did as well.
HTH
回答22:
Closing the "Autos" window improved debugging for me in vs2008 for a big native c++ solution. Hiding it won't work, it needs to be closed.
回答23:
I experienced the same slow down, and disconnecting from the network fixed the problem for me as some other comments and answers have stated (But of course that is not an ideal fix).
For my case this one simple change fixed my solution: In the project properties on the debug tab I disabled "Enable the Visual Studio hosting process." (I am running VS2010)
回答24:
Get more memory and a faster HD. More details here.
来源：https://stackoverflow.com/questions/589338/slow-debugging-issue-in-visual-studio