Darrell Norton's Blog [MVP]

Fill in description here...

Why is Visual Studio debugging so slowly?

There are many possible causes for Visual Studio (2002 and 2003) to run slowly during debugging.

Antivirus software can really slow down the process, so check there first.

Many times it's a domain issue such as an authentication timeout. Check the event log for errors.

Setting Enable Unmanaged Debugging to true in project properties can also cause debugger slowness. Try setting it to false. Native debugging is slower in general than managed code debugging, so if you don't need to debug Native code, turn it off in the options.

Another possible cause is if you had a Beta or Release Candidate version of Visual Studio .NET installed. There may be no problem initially and it occurs intermittently after a solution gets larger with multiple projects in it. See Microsoft Support article q312115.

Policy files in projects used in Enterprise Templates can also slow things down. Make sure your strongnamed project does not have any policy file (*.tdl) included.

Sometimes IIS can get "hosed." Uninstall and reinstall IIS, and then run aspnet_regiis -i.

If that doesn't work try repairing the .NET Framework in:

Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
Click "Click here for support information".
Open the Repair.htm file, which is installed to the version directory for the .NET Framework.
Follow the instructions in Repair.htm.

Published Jul 19 2005, 10:53 AM by darrell

Filed under: .NET

Comments

Ranjan Sakalley said:

Great compilation Darrell. I can probably share a story here; I was debugging my Winforms application, and suddenly the debugger stopped working. I waited for some time, probably 10 minutes, restarted, kept doing this all over again, until very much later to find out that a break point was placed, on a webserver hosting a webservice that my app used. Happened 2 years back, and I still remember the day everytime the debugger slows down.

# July 19, 2005 9:02 AM

Kevin Blakeley said:

Most of the time when my debugger slows down either an IISReset fixes the problem, or I got too carried away with my watch window and put a rather large object in there.

# July 19, 2005 10:12 AM

AC [MVP MCMS] said:

And for those really obscure times when you can't manually attach the debugger to a specific process (which you'll need to when developing for a managed application like CMS or SharePoint): http://feeds.feedburner.com/AndrewConnell?m=230

# July 19, 2005 10:34 AM

darrell said:

Thanks for the pointer, Andrew!

# July 19, 2005 12:08 PM

Justin Crandall said:

I've had VS slow down when I've got certain objects in my Watch window that have a lot of properties or are large because after each step it reprocesses the object again.

Could happen in the Locals window too, I'm sure.

# July 19, 2005 5:13 PM

darrell said:

Good point Justin.

# July 19, 2005 7:47 PM

BigJim in STL said:

One thing I've found in multi-project solutions - if you've got a bunch of breakpoints set across many different solutions, this can really slow down the startup of a debug session. Better to periodically do a "clear all breakpoints" or "disable all breakpoints", then set the ones you really want to debug with in the current session.

# July 20, 2005 7:23 AM