VS2008 Debugger Hang

Question

I'm using Visual Studio 2008 Team System with SP1, and I've noticed an annoying tendency for the IDE to hang for several (10-15) seconds whenever I stop debugging an application. At first I thought this only happened with WPF apps, but I've observed the behavior in Windows Forms apps and ASP.NET sites as well. I've made a series of changes to the Options based on this previous post and done exhaustive Google/MSDN searches, but still haven't found a way to stop this.

Anyone have any ideas?

Answer 1

Does it hangover even with basic apps? Like making a new windows form then hitting debug, or is it only with more complicated apps? Because I've noticed that before too (maybe not quite 10-15 seconds, but there has been a bit of a lag that I've noticed) but when I just tried debugging a relatively simple windows form app, I didn't get it at all.

Answer 2

Good question. I created a very simple Windows Forms app:

private void button1_Click(object sender, EventArgs e)
{
    MessageBox.Show("I am saying hello.");
}

Still hangs a good 10 seconds on closing the form.

Answer 3

I observed this kind of behaviour on one of my development machines and Visual Studio 2005. The problem was caused by Visual Studio trying to reach some non existent network share (I don't remember exactly why). You could give Process Monitor a try in order to see if your Visual Studio is trying to do something silly when finishing debugging and returning to the normal view. Maybe because you have some broken plug-in in some tool bar or in your toolbox.

Answer 4

I'm not 100% sure it's the same problem, but I've had VC++ behave in a similar manner during debugging. This mostly happened when breaking into a crashed program though, so once again I'm not sure if it's the same issue but it might be worth a try.

The reason: The debugged process dies while having locks acquired on mutexes that Text Services Framework uses to render text. When other apps try to render any text they end up being deadlocked until the debugged process dies.

The fix: Turn off advanced text services by opening Control Panel, Regional and Language Options, Languages, Details..., Advanced and checking the box labeled "Turn off advanced text services".

Sorry if this is unrelated to your problem, but it sure has helped me with my debugger acting up and locking my system.

More information: http://www.virtualdub.org/blog/pivot/entry.php?id=118

Answer 5

@korona - Nope, that didn't fix it. Thanks for your suggestion, though.

More research in ProcMon shows this interesting tidbit, not sure if it is related:

8:45:46.6790857 AM  WindowsFormsApplication1.vshost.exe 7684 FASTIO_CHECK_IF_POSSIBLE C:\WINXP\Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.cch FAST IO DISALLOWED Operation: Read, Offset: 48, Length: 12
8:45:46.6793569 AM  WindowsFormsApplication1.vshost.exe 7684 ReadFile C:\WINXP\Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.cch FAST IO DISALLOWED Offset: 508, Length: 12

This repeats several times, like hundreds of times, then it switches to a different path:

8:45:46.7470314 AM  WindowsFormsApplication1.vshost.exe 7684 FASTIO_CHECK_IF_POSSIBLE D:\documents and settings\myusername\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch FAST IO DISALLOWED Operation: Read, Offset: 48, Length: 12
8:45:46.7472187 AM  WindowsFormsApplication1.vshost.exe 7684 ReadFile D:\documents and settings\myusername\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch FAST IO DISALLOWED Offset: 508, Length: 12

And repeats again many more times, with slight changes in the offset each iteration. Maybe unrelated, but....

Answer 6

Looking at your ProcMon results, it appears that it's that CreateFile() call that's taking all the time. I'm assuming that all activity is waiting for that thread to return. You can verify this -- with some difficulty -- in Process Explorer (also part of the SysInternals package previously linked), using the Threads tab on the Properties window.

So, if CreateFile is what's causing the blockage, that would suggest that it's a delay in Windows itself. What Pierre said -- look out for network shares -- was my first instinct, too. I've had a lot of seemingly-inexplicable slowdowns in the past when Explorer had a mapping to a share that I couldn't currently reach, even though I wasn't doing any work on those shares at the time.

Can you test this possibility by unmapping all your drives and unplugging from the network? Is D: a separate physical drive from C:? If so, see if it goes faster if you move your build directory to C:.

Answer 7

Bingo! It's something to do with a network share. I don't know which one yet, but it should be pretty easy to figure out now that I know where to look. I took your advice, unhooked my NIC, disconnected my network drives, and re-ran. No hang! Thank you so, so much. This will make life much better.

Answer 8

Great, as in my case, then. Have you been able to find out what network share Visual Studio was trying to access. You might want to try wireshark to investigate further. You'll see what traffic your PC is generating...

Answer 9

From the site below I found several possible solutions.

http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/e9c5da47-a194-4051-a3d5-28b404263b3f

The one that worked best was to run Internet Explorer Then go to Tools -> Internet Options -> Advanced tab -> Security section, uncheck "Check for Publisher's Certificate Revocation"