Visual Studio Debugger Running Slow

Over the past few days, one of my C# projects started debugging unusually slow. “What could be the cause?” I asked myself. It could be any number of things. I recently upgraded to Windows 7. Along with the upgrade, I changed to x64. I’ve marched along the forced upgrade path to IIS7. Any and all of these things could be causing a slow down. So what did I do? What any good techy does in hopeless situations: I Googled.

There were lots of tips and suggestions. I tried them all, one by one with no success. One of the more complete threads I found is over at

Robbie writes:

As an update, I found an even better fix so you dont’ have to lose any functionality in VS 2008. This also drastically improved performance (response time) for me in SQL server management Studio. In Internet Explorer 7…

Tools->Internet Options->Advanced->Security Node->Uncheck ‘Check for publisher’s certificate revocation*’

Once I did this, like magic, VS 2008 works great even with ‘Enable the Visual Studio hosting process’ checked and SQL Server Management Studio’s response time was almost immediate. It is a good day! My theory is the corporate network I am in is blocking certain ports (out of my control), and thus certain ‘behind the scenes’ requests are timing out, causing the delays.

This didn’t work for me, but it looks like it helped a lot of people. I’d suggest trying it out. At the very least, it will cut down on come unnecessary traffic.

Debugging still ran painfully slow. It often took 20 seconds to half a minute to load all my assemblies before even attempting to step through code. Back to Google.

This time, I came by a fairly limited Stack Overflow response. No answer was selected as correct, but one had enough votes to make a read worthwhile:

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.

I tried it. Success! Who would have thought removing all breakpoints (adding some if you have none) would rebuild the solution file? I was rather upset to have lost my carefully crafted hundred or so breakpoints, but the speed increase makes up for the loss in spades.

Leave a Reply