89

In my Visual Studio instance, even if 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 the return statement in the main function). What is wrong? Is there a check list?

I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.

Improve this question
9
  • 2
    Just to make sure... How much memory do you have available to you when trying to run the code? VS is a memory hog from my experience... Commented Feb 26, 2009 at 6:18
  • 1
    Whats your hardware? Visual Studio is very disk and CPU intensive, so having a budget priced machine will lack in performance. Commented Feb 26, 2009 at 6:23
  • 1
    Having > 2-3 conditional breakpoints is badly handled by VS... Commented Feb 26, 2009 at 6:25
  • I have 4G memory and no other process is running at the same time. I just restarted my machine a couple of times and the same symptom. I did not met with such issues one week before. Any further ideas? Commented Feb 26, 2009 at 6:30
  • 2
    Theyre all listed in Debug->Windows->Breakpoints (Ctrl-Alt-B). But you would know if you made any... Commented Feb 26, 2009 at 6:48

24 Answers 24

Reset to default
153

You may need to delete all your breakpoints---note that you need to click the "Delete all breakpoints" button (or use Ctrl + Shift + 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.

Improve this answer
Sign up to request clarification or add additional context in comments.

13 Comments

Hi, zweiterlinde. I find the bottleneck should deal with network. When I plug-off the network cable, the performance is very good in debugging. Do you have any ideas about why? and how to evaluate further?
deleting a 14Mb .suo file worked for me :) its now a puny 150Kb. problem occured after upgrading from VS2010 Pro to Ultimate
+1. Thanks a lot, that worked). My VS 2010 took 2 minutes to start a project on a workstation. Huh. What a bug....
I also deletet the .suo file, but I did it while Visual Studio was running. When I restarted Visual Studio it attached the debugger real fast again, and it seems like it kept most of my settings.
+1 Thanks a lot, really. So in my case deleting the suo file perfectly worked for me.
|
26

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 the .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 menu Tools → Options → Debugging → Symbols.

Also try disabling "Enable property evaluation and other implicit function calls" in menu Tools → Options → Debugging → General.

Improve this answer

8 Comments

In my break points window, there is only one on the return statement of my Main function. Any other check lists?
Added more things to try. Hope it helps.
I have removed the only one break point on return statement of my Main function, but still very slow to start the application and stop, takes 1 minute or so. Any further ideas?
Here's another idea to isolate your problem. Try disconnecting your network cable, restart visual studio and hit F5 on your project. Does that change anything?
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 - This worked for me
|
20

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.

Improve this answer

5 Comments

+1 for saving my sanity (and saving me a reinstall of VS2010). Thanks!
This is the referenced solution on MSDN as well: social.msdn.microsoft.com/Forums/vstudio/en-US/…
Confirming this also applies to older versions 2003.NET and 2005. One application had a couple of breakpoints and running fine. Added a few more breakpoints...100% CPU usage and terrible flickering in VS when debugging. Closed VS, deleted the .suo, re-opened and debugging is fast again.
This is the solution that I find always works whenever VS gets too slow in terms of debugging
Or rename the .suo file first before deleting so it is possible to revert to the previous state.
13

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

How to: Enable and Disable IntelliTrace

Improve this answer

5 Comments

It solves also problem if you have project that uses SharpDX - it worked for me and now graphics performance come back to normal.
In the special case of using SharpDX and Debug-Build, I had the same effect, but it was just DX debugging enabled. If it is not needed, search for "DeviceCreationFlags.Debug" and disable it
In VS2015 I unchecked 'Enable Intellitrace' and clicked OK. Later discovered that you have to change from 'Intellitrace and call information' to 'Intelllitrace events only'; if you don't, 'Enable Intellitrace' STAYS CHECKED!
Solved the problems! (don't belive in the MS comment: "This topic applies to Visual Studio 2010 Ultimate only."). I have 2017 free edition and it speedet up the debugging dramatically!
IntelliTrace in VS 2017 and up is an Enterprise only feature, so this did not fix my issue (as I had only VS 2017 Pro edition).
7

My colleague had a very slowly responding Visual Studio, and 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 Visual Studio was running. Killing its process immediately fixed everything.

Improve this answer

4 Comments

I had a horrible web debugging experience at work until I disabled the ESET anti virus. After hitting F5 my response time has gone from 2-3 minutes to 2-3 seconds.
Suspending ThreatFire for a while helped me a lot too--thanks! (Temporarily turning off Avast! helped a bit too, but not that much.)
Malwarebytes was the cause of my problem. Quitting it fixed the slowness.
I'm also using Malwarebytes... After quitting it, VisualStudio debugging is much faster. Debug startup was 15sec before, now it is to 2sec).. Thanks!
6

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.

Improve this answer

4 Comments

I only have one break point in my user mode code. But I remembered a week before I used source debugging feature in Visual Studio to set some break point into .Net internal code. Any way to check all break points including .Net internal ones I set?
None, but still slow, any further ideas?
not really, it seems like your hardware should be ok and all the other items I would have tried seem to have been ticked off by other commenters. At this point I would probably try reinstalling visual studio - maybe something is messed up with the install
I reinstalled to another directory but stil the same symptom. Any further ideas?
6

Go to menu Tools → Options → Debugger → Symbols and check if you have public symbols set or UNC network paths set. Also check menu 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.

Improve this answer

1 Comment

Thank you, this was it for me. I would occasionally load 1 or 2 symbol files in the Modules window, pointing to symbols from our builds via UNC paths, or less frequently, pointing to virtual machines that no longer exist. Didn't realize it saved all these paths in the Debugger/Symbols settings.
5

In my case changing the debug symbol "Automatically load symbol for" option from "All modules" to "Only specified modules" solved the problem. You can change this option from menu Tools → Options → Debugging → Symbols.

Improve this answer

Comments

3

A different cause plus... How to find the problem

To me it was the option ShowOtherThreadIpMarkers. A value of 1 makes Visual Studio (2010) unbearably slow (3-5 seconds for each debug step. With a value of 0, it is fast again.

What is it that option? I have no idea. I could not find it through the Visual Studio 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 Visual Studio 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.

Improve this answer

1 Comment

+1 Thanks, this was my problem too with a C# web app in VS2015. I disabled the "Show Threads in Source" option in the toolbar while debugging and the problem went away. If the option is not available in the toolbar, it can be found by right clicking any thread inside the Threads window.
2

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

Improve this answer

5 Comments

Do you have Google Toolbar installed? Even saying no is helpful for future readers of this question.
I opened IE and no toolbar displayed, does it mean I have no toolbar installed and will not impact Visual Studio? :-)
Wow. I thought that it made no sense, but i just uninstalled and my machine returned to usable mode
Another plugin that gets blamed is LastPass. Is this only an issue with IE or can a plugin in any browser affect things?
@DeniseSkidmore You are amazing, I wish I could upvote more than once. All these other solutions and nothing was helping...then I read your comment, disabled the LastPass IE add-in and suddenly it is fast again. I confirmed this was the problem by re-enabling the add-in and it slowed back down. THANK YOU!!!!
2

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.

Improve this answer

Comments

1

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.

Improve this answer

8 Comments

Process Monitor is a cool tool! :-) But which option in Process Monitor could be used to see "if a network (or other file error) seems to be blocking for a long time"?
I would look for things such as errors when attempting to open a file or how long operations take (don't forget there are data items you might not seen such as 'Duration' that you can select in Options/Select Columns...). Use the filters and highlights to your advantage.
Hi Michael Burr, in Process Monitor you mean monitor VSTS process itself or monitor all processes on the machine?
I'd definitely start with just VSTS (devenv.exe) or you'll get inundated with information that's almost certainly not useful.
You'll want to use "Process Monitor" not "Process Explorer". See technet.microsoft.com/en-us/sysinternals/bb896645.aspx. The 2 utilities have different functions. Procmon will trace file and registry operations. Procexp is a handy utility but does not provide that type of tracing.
|
1

Are you using a symbolsServer to download symbols for Windows DLL files?

If so, disable that as it can take some time, but I wouldn't expect that to cause long delays in a basic console application.

Menu Tools → Options → Debugging → Symbols.

Improve this answer

1 Comment

The content is empty in Tools > Options > Debugging > Symbols. Any further ideas?
1

I know this is an old topic, but for what it's worth...

I've found that if I've had a separate Internet Explorer window open for a long time it can take up to a minute to start debugging. Close all Internet Explorer windows and debugging starts immediately.

Improve this answer

Comments

1

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.

Improve this answer

Comments

1

I had the same issue in Visual Studio 2010, 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 (essentially menu Tools → Import and Export Settings, Reset all settings, with saving existing settings to a file (for reverting)).

You may first want to save a particular part of your settings. For instance, I first saved my color theme (Solarized-like) and then restored it after the global reset.

Improve this answer

Comments

1

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 menu Options → Debugging → General.

Improve this answer

Comments

1

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 the ForceLog, LogImmersive and LogResourseBindings values from 1 (enabled) to 0 (disabled).

Improve this answer

2 Comments

That was what was happening to me. YOu can also disable Fusion Log through it's gui: hanselman.com/blog/…
You can see if this is your problem when running Process Monitor you'll see all the accesses to the Fusion Log file.
0

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.

Improve this answer

1 Comment

The link is broken: "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
0

Something that has worked for me is to make sure there are no conditional break points. Other than that, I have had success fixing slow debugging by simply restarting Visual Studio and only opening one instance of Visual Studio at a time.

Improve this answer

Comments

0

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.

Improve this answer

Comments

0

Closing the "Autos" window improved debugging for me in Visual Studio 2008 for a big native C++ solution.

Hiding it won't work. It needs to be closed.

Improve this answer

Comments

0

I experienced the same slowdown 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 Visual Studio 2010).

Improve this answer

Comments

-9

Get more memory and a faster HD. More details are here.

Improve this answer

3 Comments

I do not think it is H/W issue, since my hardware is 4G memory + 2 CPU (2.33G), is that enough? BTW: I did not suffer from this a week before, so I think it should be some configuration issues?
+1 Helpful advice, can't believe people vote this down. Although deleting your .suo file helps 10x more.
The OP has not even told what their spec is. If you were advising me, you would be advising me to get greater than 32Gb Ram and faster than my already fast solid state.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.