ContextSwitchDeadlock在C#中被检测到错误

Question

我正在运行一个C#应用程序，在运行期间我得到了以下错误：

CLR无法从COM上下文0x20e480转换到COM上下文0x20e5f0 60秒。拥有目标上下文/单元的线程很可能要么执行非抽水等待，要么处理非常长时间运行的操作而不发送Windows消息。这种情况通常会对性能产生负面影响，甚至可能导致应用程序变得无响应或内存使用量随着时间的推移而不断累积。为了避免这个问题，所有单线程单元(STA)线程都应该使用泵送等待原语(如CoWaitForMultipleHandles)，并在长时间运行操作期间常规地对消息进行泵入。

有人能帮我解决这个问题吗？

非常感谢。

Answer 1

程序的主线程一直忙于执行代码一分钟。它没有注意到它的正常职责，把消息循环抽出来。当您在工作线程中使用COM服务器时，这是非法的:在主线程再次空闲之前，无法分派对其方法的调用。

它应该是容易看到的，你的UI应该已经死了，就像钉子一样。Windows应该将主窗口替换为显示“未响应”的鬼。关闭窗口将无法工作，没有点击事件有任何影响。

无论您的主线程在做什么，都应该由一个工作线程来完成。BackgroundWorker类对此很好，您可以在MSDN文章中找到它的许多用法帮助。如果您不知道主线程在做什么，请使用Debug + Break、Debug + Windows + thread。

另一个可能的原因是:如果您使用的是VS2005的RTM版本，请确保安装service 1。

Answer 2

要查找哪个操作阻塞了上下文开关并导致contextSwitchDeadlock丙二醛显示，您可以使用以下步骤。请注意，我指的是Visual 2012。

1. 复制错误。这可能涉及到一些尝试和错误。
2. 在显示的托管调试助手中单击“确定”而不是“继续”。
3. 通过右键单击工具栏停靠区域并选择“调试位置”，确保“调试位置”工具栏处于活动状态。如果工具栏处于活动状态，则应在工具栏中看到标签为“Thread”的下拉列表。
4. 线程下拉列表中的选定项应该是一个线程，而不是主线程，因为它将是一个后台线程，它抱怨主线程占用了所有的注意力。在下拉列表中选择主线程。
5. 现在您应该可以在代码编辑器中看到阻止上下文切换的代码。

假设您决定不将资源密集型操作从您的主线程中移出--在此之前在这里查看其他一些答案和注释--您有以下选项来禁用托管调试助理。

Visual调试器中的

1. 您可以直接在MDA对话框中禁用MDA，当错误发生时，可以取消选中“引发此异常类型时的中断”。
2. 使用下面来自MSDN的说明进行异常设置对话框。

...on调试菜单，单击“异常”。(如果Debug菜单不包含异常命令，请单击“工具”菜单上的“自定义”以添加该命令。)在“异常”对话框中，展开“托管调试助理”列表，然后清除单个MDA的引发复选框。

在Visual调试器之外

1. 注册表项 (机器宽，所有受影响的MDA)
2. 环境变量 (机器宽度，可以指定MDAs )
3. 应用程序配置设置 (可指定MDAs的应用范围)

注意:必须将前两个选项之一的设置为1才能使第三个选项产生任何效果。

在我的例子中，问题是在控制台应用程序中调用实体框架中的ObjectContext.SaveChanges()。当MTAThreadAttribute应用于Main()方法时，ContextSwitchDeadlock异常不再引发。不幸的是，我不确定这一变化的全部影响。

Answer 3

此消息表示您的某些代码正在尝试切换线程，而目标线程正处于繁忙状态。例如，一个后台线程试图向UI线程分派一个调用来更新UI，而UI正在运行一个紧循环一段时间。

要真正弄清楚到底发生了什么，您需要进入调试器，查看所有线程以及它们正在做什么。