C# 调试问题：CoWaitForMultipleHandles

异常提示：

CLR  无法从  COM  上下文  0x444f88  转换为  COM  上下文  0x4450f8，这种状态已持续  60  秒。拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送  Windows  消息的情况下处理一个运行时间非常长的操作。这种情况通常会影响到性能，甚至可能导致应用程序不响应或者使用的内存随时间不断累积。要避免此问题，所有单线程单元(STA)线程都应使用泵式等待基元(如  CoWaitForMultipleHandles )，并在运行时间很长的操作过程中定期发送消息。

 

The CLR has been unable to transition from COM context 0x444f88 to COM context 0x4450f8 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.

 

 

解决：

Debug -> Exceptions -> Managed Debug Assistants，取消 ContextSwitchDeadlock 项的选中状态。

 

 

参考：

he ContextSwitchDeadLock MDA (I blogged about MDAs here) sometimes fires under the debugger. MSDN says:

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.

 

 

Reference:

http://blogs.msdn.com/b/jmstall/archive/2005/11/11/contextswitchdeadlock.aspx

http://msdn.microsoft.com/zh-cn/library/ms172233.aspx

https://groups.google.com/forum/?fromgroups#!topic/microsoft.public.vsnet.debugging/HkrBAQrlkg0