问题标签 [contextswitchdeadlock]

这是我的问题的情况：
我有ListBox两个类型的项目MyClass。
MyClass有一个List<Column>集合。
在同一个窗口的其他地方，我有一个ComboBox选择MyClass.ColumnCollection为 ItemsSource 的列。

这是麻烦开始的地方：
我第一次打开 ComboBox 的弹出窗口时一切正常。
当我在 ListBox 中选择其他项目（以及更改 ComboBox 源）时，打开弹出窗口需要超过 10 秒的时间。如果花费的时间超过 60 秒，我会收到以下错误：

我用谷歌搜索了这个错误，无论我走到哪里，都建议禁用 ContextSwitchDeadlocks 的抛出，这根本不是解决方案！

我对此进行了进一步研究，发现了以下 COMException：

我不使用线程/任务或其他任何东西，只是在ComboBox.
我尝试在选择另一个项目时刷新 ItemsSource，但它没有任何区别，因为它已经正确设置。

我试图用谷歌搜索这个错误，但似乎没有解决这个问题的方法。
微软为此提供了一个修补程序，但没有下载。

列表框的代码：

组合框的代码：

SelectionChanged 事件：

问题：
有人知道如何防止 COMException 吗？

更新 1：
添加了一些 Xaml 代码示例

更新 2：
简化问题

更新 3：
我发现真正的错误是 COM 异常。
用新信息更新了我的问题。

更新 4：
ListBox 中的所有对象都是完整的并且存在于内存中，因此没有查询。此外，无论组合框是 1 还是 100 项，都会出现等待时间。（我测试了两者）。

我正在通过 Assembly.LoadFile 使用运行时 dll 初始化来为我的项目加载其他视口。我已经以这种方式成功启动了 WPF 表单和 CS-SDL 表单（均构建为 dll），但 MonoGame 表单在 60 秒后给了我一个错误。运行：

托管调试助手“ContextSwitchDeadlock”检测到问题。CLR 在 60 秒内无法从 COM 上下文 0x5b16f8 转换到 COM 上下文 0x5b1920。拥有目标上下文/单元的线程很可能要么进行非泵送等待，要么处理非常长时间运行的操作而不泵送 Windows 消息。等等

插件（作为类库构建的表单）初始化代码：

RunViewControl 方法：

我想知道如何解决这个问题（除了关闭 MDA）。我应该明确实施消息泵送吗？

表单做得很好，它可以看到鼠标/键盘事件并且可以移动。唯一的问题是可能与这种情况有关的内存泄漏（MDA 描述表明它可能导致内存泄漏）。

更新：为 XNA 线程设置 STA 似乎可以抑制这个错误，尽管我不清楚为什么。也许我应该更深入地研究 Windows 内部机制。

如何防止死锁？有没有算法可以做到这一点？我有两个进程：一个持有信号量，另一个等待信号量。当持有信号量的进程死亡时，就会发生死锁。我的问题是无论如何（在信号量或操作系统中）可以避免这种情况？谢谢！

我的代码在目录中查找 .zip 文件，并将它们提取到临时文件夹结构中以便稍后删除。

有时，我会收到ContextSwitchDeadlock was detected错误消息，当我调查发生这种情况的位置时，它是在解压缩 zip 文件的过程中。

结果，我想把它移到后台工作线程中，但我一生都无法弄清楚从哪里开始使用后台工作线程。

任何帮助将非常感激。

我想我需要将 zipfile 列表传递到后台工作线程，但到目前为止还没有成功。

解压缩 zip 文件的第一行代码是： foreach (FileInfo fz in ZipFiles) { 做解压缩的东西 }

所以我想把整个 foreach 循环放在后台工作人员中（我想？）

就像快速的前文一样，我知道是什么导致了异步等待死锁问题，但仍然遇到问题。希望我只是忽略了一些简单的事情。

我有一个有趣的问题，我正在扩展实体框架 IdentityDBContext 的保存功能。我正在扩展它并覆盖这些方法。

问题是这些调用中的任何一个都可能调用返回可等待任务的对象上的接口方法。这又回到了同步运行异步方法的整个过程中。我已经采取了预防措施来避免死锁，但让我们看看一些代码，这样你就可以看到调用链。

下面是从 UI 按钮单击事件调用的。Task.Run() 用于避免死锁问题。此时，我们处于 UI 上下文中，这就是它将使用 .Wait() 阻止的内容

现在在 ExecutePreSaveTasks() 函数内部有以下内容（为了清楚起见，省略了无用的代码。

现在这部分是关键。在上述“OnBeforeInsert”调用之一中，有一个回调到 DataContext 以调用等待等待的“SaveChangesAsync”。

然后最后在 SaveChangesAsync

完整的调用堆栈...

这等待永远不会回来！现在我的理解是，当我打电话时

任务.运行（动作）

我提供了一个新的 SynchronizationContext 回调可以在其上运行。这将确保我不会遇到死锁情况。实际上，在执行 Task.Run 之前，我已经调试并验证了我在 DispatcherSynchronizationContext 上，当我在 SaveChangesAsync 中等待真正的异步调用时，我在 ThreadPool 上下文中（当前上下文为空）。然而死锁仍然发生？

内部 SaveChangesAsync 调用是否执行了一些导致此问题的特殊逻辑，或者我的理解有缺陷？感谢那些花时间阅读并尝试提供帮助的人。

ps 我还在所有任务上尝试过 ConfigureAwait(false)，只是想看看它是否有帮助，但没有。

我正在尝试加载表适配器asynchronously。我用的await方法。

xml:

代码：

上面确实会异步加载数据，但问题是我在组合框中有一个 ID 字段。当我按下组合框来选择和识别程序时，程序就会锁定。当我调试应用程序时，我得到一个“发生 ContextSwitchDeadLock”。我查看了那个错误，显然它发生在一个过程花费太长时间时。不知道为什么会这样。如果我不异步加载数据，组合框就可以正常工作。

现在的情况

有一个客户端通过 HttpClient.GetAsync 执行获取请求。不幸的是，出于某种原因，我们需要阻止这些调用。

为此，使用此 Asynchelper 类以避免上下文切换死锁（而不仅仅是使用 .Result）

然后实际的调用如下所示：

问题

在使用 Netlimiter 降低网络速度的压力测试期间，我们遇到了请求未完成的问题。例如，当我终止网络连接（在 NetLimiter 中）时，这样的请求将永远留在客户端。它将停留在 AsyncHelper.RunSync 调用中，直到遇到 httpClient.Timeout。

当连接丢失时，不应该有一个异常会结束这个调用吗？我错过了什么吗？

我在继承的一些代码中有一个奇怪的行为 - 下面的简化示例演示了如果内置到普通控制台应用程序中的问题。

WhoIs 在第 5 次调用时达到其使用限额 - 并返回一条消息 + 关闭套接字。使用 ReadLineAsync 这会产生一个 SocketException 和一些 IOExceptions - 有时这些被捕获在 catch 块中，一切都应该是，大多数时候它们没有被捕获并且程序只是挂起 - 在 VS 调试器中的 Break all 向我展示了其中一个在主线程上调用 Console.WriteLine。直接在调试器外部运行 .exe 文件时，此行为仍然存在。

谁能看到这是什么/为什么会发生？

我实际上可以通过使用 Peek() 来解决我的问题，但我想知道没有被捕获的异常以及“死锁”是怎么回事。大概是某种线程或上下文问题。如果这是我正在做的事情，我想知道是什么，这样我就可以在其他地方避免它！

建议的重复问答可能相关，但不能回答我可以看到的这个查询，当然不能完全回答：即我需要对 SynchronizationContext 做什么 - 我已经在使用 ConfigureAwait(false)。

当代码如上所述死锁时，堆栈跟踪是：

IOException 是：{“无法从传输连接读取数据：现有连接被远程主机强制关闭。”}

SocketException 是：{“已建立的连接被主机中的软件中止”}

我在 Windows 服务中有一个运行时间相当长的进程，它会定期抛出“ContextSwitchDeadlock”异常：

我还操纵我的服务向自己发送电子邮件，其中包含有关遇到的异常的详细信息。我得到：

...然后三秒钟后：

顺便说一句：至少它是一致的：我有三对这样的异常，每次第二个的日期时间都在第一个之后的三秒。

我以前有过以这种或那种方式调整 SQLCommand 的 CommandTimeout 值（当前设置为 360）的经验，这似乎有点像蒙着眼睛扔飞镖，甚至是黑魔法。有没有更好的方法来防止这种死锁？

我有其他非常相似的方法不会导致这个问题；那些需要更少的时间。方法的持续时间（特别是查询运行所需的时间长度）似乎是“问题”。我无法改变这一点——“它就是这样”——那我还能做什么？

更新

自然地，在发布上述内容之后，顽固的过程“让我成为骗子”，因为我又得到了两对异常，这次是第二对错误消息发生在第一个而不是三个之后一秒。如果我等待的时间足够长，也许第二个异常会在第一个异常之前发生。

我正在尝试使用像数据库这样的 Excel 文件。我已经编写了这段代码来打开我将用来工作的 Excel 文档

当编译器执行这条指令gecc.ExcelToGrid(sheet, grid)我等待一分钟，然后 Visual Studio 向我显示这个错误：

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

我在网上阅读了一个解决方案，所以我尝试使用 Backgroundworker，但错误消息仍然存在。也许我不太了解如何使用Backgroundworker。谁能解释我在哪里做错了？