What is the 'COM context' referred to in the 'ContextSwitchDeadlock' MDA message?

Question

While running unit tests, I'm getting the MDA shown below.

In the error message, what is the hexadecimal value refered to as a 'COM context'?

Can I determine this value for a given STA thread? If so, how?

Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem in 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\vstesthost.exe'. Additional Information: The CLR has been unable to transition from COM context 0x14cff0 to COM context 0x14d218 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.

Answer 1

I haven't seen that before, I suspect it's just an internal pointer. Neither thread IDs nor thread handles are usually that large.

There's been no way of getting the apartment type from the current thread, and I've never seen an apartment ID (other than a GUID representing the source/target apartment when marshalling) in native code.

Answer 2

The unit test is most likely running in MTA mode and you have code in it that displays a UI. One COM context is visual studio, the other is the UI inside your unit test. You can either not display a UI or turn off the MDA.

Answer 3

It looks like the STA COM application does not spin the message loop. This would cause STA COM to just die. I got no idea what the COM context is but it strikes me that you should be able to reproduce your target app to just hang for long periods of time.

Sounds like there is a function that takes more than 60 seconds to run. Have you been able to isolate it?

EDIT This is the guy that wrote COM interop for .NET.

http://blogs.msdn.com/cbrumme/

Have a look at his blog or check out the boards that he frequents. He's written lots of stuff about why COM interop the way it is. It might help to ask this question on one of the Microsoft boards.

Answer 4

From what I can see (looking at mscorwks disassembly) it is a IObjContext*, returned from CoGetContextToken().

Basically it looks like a call is queued up using IContextCallback::ContextCallback() from mscorwks!CtxEntry::EnterContextOle32BugAware(), which in turn calls mscorwks!CtxEntry::EnterContextCallback() once the object context (apartment) processes the message. They use a CLREvent to signal callback completion. For STA threads, not pumping messages would cause the event wait to timeout, which triggers the ContextSwitchDeadlock MDA.

Note: I'm not running this under a debugger so I can't confirm the behavior, but this is probably reasonably accurate.