Karmic Code Monkey

Every once in a while, Visual Studio 2008 will lock up on me. When it was in beta and even after release, I ran into a situation where it put up a dialog saying “Blah blah blah” with the options:

• Switch to application
• Continue waiting

From someone, probably either directly from John Robbins or via one of the many blogs he has recommended through his presentations, I learned that this was being caused by a managed debugging assistant. Looking around on the web, it seems that this bug has been known for quite a while. Here is the issue and why it happens as explained by a Jim Stall from the Visual Studio team (link to post):

It is possible for this MDA to be falsely activated when all of the following conditions are met:
    * An application creates COM components from STA threads either directly or indirectly through libraries.
    * The application was stopped in the debugger and the user either continued the application or performed a step operation.
    *Unmanaged debugging is not enabled.

The reasoning is that:
1) When you’re stopped in the debugger while managed-only debugging, unmanaged threads are still running. This means that any unmanaged threads that are waiting on some timeout from managed code will continue to run. The unmanaged thread will see the timeout fire, but it won’t realize that the managed thread is actually stopped by the debugger. Thus the managed thread looks it’s deadlocked.  This is not an issue when unmanaged debugging because then the timeout thread is also frozen when stopped in the debugger, and so the timeout won’t fire.

2) The finalizer for an STA COM objects needs to run code on the STA thread. So there’s some cross-thread stuff between the finalizer thread and the STA thread.

So the STA thread may be blocked by the debugger (since the whole managed process is frozen at a breakpoint), while the timeout check (on an unmanaged thread) is still ticking.

This is a race because it needs the finalization and debugger event to happen at just the right windows.
We assessed that this scenario as a rare situation. I’d expect you to see this only on very rare occasions (due to prerequisite timing issues).
If you are hitting this bogusly, one workaround is to disable this specific MDA.

Let’s walk you through disabling the specific MDA, since this problem still exists and is not as rare as these guys think. I don’t get the issue when debugging normally, but I will get it when I run Visual Studio as an admin. Running Visual Studio 2008 as admin is required if you want to deploy applications straight over to the same machine’s IIS instance-something I do often enough. Note: I haven’t run into this issue in a non-admin context in several months. I think the two conditions are somehow linked.

Please note-you have to run this sequence for every project. VS2008 will not remember your settings across invocations.

1. With an open project, go into the menus and select DebugàExceptions.
2. Expand the Managed Debugging Assistants node.
3. Select ContextSwitchDeadlock and uncheck it.
4. Click OK.

I hope this helps a few other brave souls out there.