The CLR has been unable to transition from COM context 0x118b008 to COM context 0x118b178 for 60 seconds. The thread that owns the destination contex

ContextSwitchDeadlock was detected

Message: The CLR has been unable to transition from COM context 0x118b008 to COM context 0x118b178 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.

The contextSwitchDeadlock managed debugging assistant (MDA) is activated when a deadlock is detected during an attempted COM context transition.

Symptoms

The most common symptom is that a call on an unmanaged COM component from managed code does not return. Another symptom is memory usage increasing over time.

Cause

The most probable cause is that a single-threaded apartment (STA) thread is not pumping messages. The STA thread is either waiting without pumping messages or is performing lengthy operations and is not allowing the message queue to pump.

Memory usage increasing over time is caused by the finalizer thread attempting to call Release on an unmanaged COM component and that component is not returning. This prevents the finalizer from reclaiming other objects.

By default, the threading model for the main thread of Visual Basic console applications is STA. This MDA is activated if an STA thread uses COM interoperability either directly or indirectly through the common language runtime or a third-party control. To avoid activating this MDA in a Visual Basic console application, apply the MTAThreadAttribute attribute to the main method or modify the application to pump messages.

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.

To determine if the MDA is being falsely activated, disable all breakpoints, restart the application, and allow it to run without stopping. If the MDA is not activated, it is likely the initial activation was false. In this case, disable the MDA to avoid interference with the debugging session.

Resolution

Follow COM rules regarding STA message pumping.

To avoid these error popups from appearing, select Exceptions from the Debug menu from Visual Studio window and in the Exception Dialog box select the Managed Debugging Assistants Exception Node. Then select ContextSwitchDeadlock and remove the select from Thrown column