Andrew Stopford's Weblog

poobah

Sponsors

News

Articles

Family

Old Blogs

ContextSwitchDeadLock erorr while debugging

While debugging a managed code batch process today I ran into VS throwing a 'ContextSwitchDeadlock MDA' error. The debugger was attached to several long running process's and towards the end of the cycle VS was reporting this issue. As Mike Stall reports it seems to be caused by the thread running the managed code I am debugging timing out but the unmanaged thread seeing not seeing it as dead. Why the managed code I am running times out in the debugger thread I am not clear about. It seems like that the debugger has a fixed response to all break points that starts at execution time, as each step I am debugging goes off to the database, waits a while and then comes back, it eats into this time. Eventually the debugger thread times out and the ContextSwitchDeadlock error occurs. You can't stop this kind of error (although I do wonder if the time out value on the debugger thread could be adjusted) but you can disable the warning.

Two tips I extracted from this thread is

  • First you don't already have it (Debug - Exceptions) obtain the debug exceptions window (right click tool bar - customize - debug and drag exceptions into the debug menu).
  • Select from Debug - Exceptions - Managed Debugging Assistants and disable ContextSwitchDeadlock.

I had no luck with trying to disable this via reg keys and config files but that is suggested in the MDA help files.

Posted: May 19 2008, 05:14 PM by andrewstopford | with 3 comment(s)
Filed under:

Comments

Jeff Brown said:

MDAs are useful diagnostics but can be somewhat insidious.

I get a disconnected context MDA when debugging Visual Studio add-ins under certain circumstances.

IIRC you can disable MDAs using environment variables and other options but that may only mask a deeper problem that is manifesting in debug mode.  Granted it may not be a real bug in your code but rather a problem with the debugging environment, but allowing them to go unacknowledged could be detrimental to your debugging experience.

Actually, the MbUnit.Samples.sln in the Gallio source tree came about because loading All.sln into Visual Studio under debug would crash 75% of the time.

# May 19, 2008 4:13 PM

Andy Stopford said:

Thanks Jeff, the enviroment variable would be another option. Turning off this warning could mask a problem I agree but runs through the code with no debugging ran ok and I suspect as noted it is due to the long running nature of the batch process that is causing this one.

Sometimes this can show up when working with COM wrapppers such as VSTO and can also be a false warning but use with great care folks, as Jeff notes it can mask a true defect.

# May 20, 2008 2:13 AM

Rob Chafer said:

Hi Andy

I suppose if you are stepping through a long routine it could just be a message waiting to be delivered from an unmanaged thread. The code being stepped would look dead -- which is sort of is unless you let it go at full speed.

# June 4, 2008 7:05 PM