Static News Archive

   (18-Jun-09 23:57)  Horrible CLR context switch deadlock error
Our application at work is quite complex, and has a lot of lines of code.

So when you get a strange exception like this:

Context Switch Deadlock was detected
The CLR has been unable to transition from COM context 0x21fe68 to COM context 0x21ffd8 for 60 seconds.
The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages.
This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time.
To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

... it's a bit worrying.

Searching for the exception seems to turn up hundreds of ways to turn the exception off.
But I don't want to just ignore it!!!

So I managed to track down the precise code that causes this to occur.

We have a load of objects that get created on startup. One of them grabs the windows installation ID using a ManagementClass query like this:

ManagementObjectCollection mbCol = new ManagementClass("Win32_ComputerSystemProduct").GetInstances();

No matter what I tried, I couldn't get the deadlock exception to stop occurring.
In the end, I ended up not using WMI at all - for others that need to, I'd love to know what you did to get around this problem.

I suspect that it won't always occur when you make a call to WMI - it's most likely related to the specific circumstances under which I was making the call.

Let me know if you have more information!


Post a comment     

<-  (3-May-09 17:52)  Internet explorer an... (9-Sep-09 18:38)  Connection limit in ...  ->