“ContextSwitchDeadlock”MDA 消息中提到的“COM 上下文”是什么？答案

【问题标题】：What is the 'COM context' referred to in the 'ContextSwitchDeadlock' MDA message?“ContextSwitchDeadlock”MDA 消息中提到的“COM 上下文”是什么？
【发布时间】：2009-07-21 12:12:15
【问题描述】：

在运行单元测试时，我得到了如下所示的 MDA。

在错误消息中，被称为“COM 上下文”的十六进制值是什么？

我可以为给定的 STA 线程确定这个值吗？如果有，怎么做？

托管调试助手 'ContextSwitchDeadlock' 检测到一个 'C:\Program Files\Microsoft 中的问题视觉工作室 9.0\Common7\IDE\vstesthost.exe'。附加信息：CLR 有无法从 COM 过渡 上下文 0x14cff0 到 COM 上下文 0x14d218 60 秒。线程拥有目的地上下文/公寓最有可能要么进行非抽水等待，要么处理很长时间的运行无抽水操作 Windows 消息。这种情况一般有负面的性能影响，并可能甚至导致应用程序变成无响应或内存使用随着时间的推移不断积累。到避免这个问题，全单线程单元 (STA) 线程应该使用抽水等待原语（例如 CoWaitForMultipleHandles）和在很长一段时间内定期发送消息运行操作。

【问题讨论】：

标签： com clr

【解决方案1】：

据我所知（查看 mscorwks 反汇编）它是一个 IObjContext*，从 CoGetContextToken() 返回。

基本上，看起来像使用来自mscorwks!CtxEntry::EnterContextOle32BugAware() 的IContextCallback::ContextCallback() 将调用排队，一旦对象上下文（公寓）处理消息，它又调用mscorwks!CtxEntry::EnterContextCallback()。他们使用 CLREvent 来表示回调完成。对于 STA 线程，不泵送消息会导致事件等待超时，从而触发 ContextSwitchDeadlock MDA。

注意：我没有在调试器下运行它，所以我无法确认行为，但这可能是相当准确的。

【讨论】：

【解决方案2】：

我以前没见过，我怀疑它只是一个内部指针。线程 ID 和线程句柄通常都没有那么大。

无法从当前线程获取单元类型，而且我从未在本机代码中看到单元 ID（编组时表示源/目标单元的 GUID 除外）。

【讨论】：

【解决方案3】：

单元测试很可能在 MTA 模式下运行，并且您在其中有显示 UI 的代码。一个 COM 上下文是 Visual Studio，另一个是单元测试中的 UI。您可以不显示 UI 或关闭 MDA。

【讨论】：

单元测试是非 GUI 的，并且配置为在 STA 中运行。
有问题的 UI 可能是测试运行程序原生的，而不是您的代码。我在单元测试中运行资源密集型代码时看到了有问题的 MDA，VS 想要从忙于回答的附加进程中进行更新。
我想我知道为什么会发生 MDA（我从终结器到 STA 线程进行跨线程 COM 调用），但我确实想知道是否可以使用 MDA 错误消息中的幻数以任何方式进行诊断 - 以防检测到真正的问题。

【解决方案4】：

STA COM 应用程序似乎没有旋转消息循环。这将导致 STA COM 死掉。我不知道 COM 上下文是什么，但让我感到震惊的是，您应该能够重现您的目标应用程序以长时间挂起。

听起来好像有一个函数需要超过 60 秒才能运行。你能隔离它吗？

编辑这是为 .NET 编写 COM 互操作的人。

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

看看他的博客或查看他经常光顾的板。他写了很多关于为什么 COM 互操作的东西。在微软的一个板上问这个问题可能会有所帮助。

【讨论】：

是的，这是一个没有在某处提供服务的 COM 消息循环。但我想知道十六进制数字指的是什么，以及是否可以将其用于诊断。