5

我有一个问题，我们的应用程序挂在我们客户的机器上，我已经使用了好几天没有解决。从我们所看到的情况来看，这个问题是随机出现的，尽管情况可能并非如此。客户还报告说，当应用程序挂起时，CPU 正在达到峰值。

问题是我不知道应用程序在哪里失败（挂起）。我们也有几个用 C# 编写的插件作为主 COM 应用程序的插件。

我已经设法让客户在出现问题的机器上使用 ProcExp 进行 MiniDump。但是，我对 WinDBG 或 MiniDumps 也不是很熟悉。我运行了!analyze -vand !analyze -v -hang，它产生了一些输出，包括下面的堆栈。据我所知，应用程序似乎正在转换到我们的 C# 插件 (CLR) 之一，然后又回到 COM，它应该是返回到插件可用的主应用程序的接口。但是然后呢？可以从这个堆栈中说更多吗？

如果重要的话，主应用程序是用 VB6 编写的。

0012da70 7e3693e9 7e3693a8 0012daf0 00000000 ntdll!KiFastSystemCallRet
0012da9c 7e37a43b 0012daf0 00000000 0000000f user32!NtUserPeekMessage+0xc
0012dac8 7348e6fd 0012daf0 00000000 0000000f user32!PeekMessageA+0xeb
0012db1c 77532a9c 00d03774 00000000 00000000 msvbvm60!CMsgFilter::MessagePending+0x21f
0012db60 77532a48 00000102 0012dbec 00000001 ole32!CCliModalLoop::HandlePendingMessage+0x40
0012dba8 7751eda6 80010116 80010115 00000000 ole32!CCliModalLoop::HandleWakeForMsg+0x46
0012dbbc 77547297 0012ddf0 00000001 0012dbe8 ole32!CCliModalLoop::BlockFn+0x8b
0012dc30 0ae8a2fd 00000002 00000001 00000001 ole32!CoWaitForMultipleHandles+0xcf
0012dc50 0ae8a264 00000000 00000001 00000001 mscorwks!NT5WaitRoutine+0x51
0012dcbc 0ae8a1c8 00000001 0012ddf0 00000000 mscorwks!MsgWaitHelper+0xa5
0012dcdc 0af3ccd0 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateAptStateWait+0x28
0012dd60 0af3cd65 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
0012ddb0 0ae8c026 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWait+0x40
0012de00 0ae90f4c 00000001 05ae5c80 0012de60 mscorwks!Thread::JoinEx+0x86
0012de10 0b00ea40 00000001 00000001 5bdf0a2d mscorwks!Thread::Join+0x14
0012de60 0af0b9a7 00000001 0012deb0 0af0ba10 mscorwks!RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a
0012de6c 0af0ba10 001df674 0012df10 5bdf0afd mscorwks!RCW::Initialize+0x78
0012deb0 0af0b6a7 001df674 0012df10 5bdf0b6d mscorwks!RCW::CreateRCW+0x84
0012df20 0af0b7b5 00000000 0012df5c 5bdf0b21 mscorwks!COMInterfaceMarshaler::CreateObjectRef+0x45
0012df6c 0ae892a8 5bdf3065 0012e6c8 0012e6c8 mscorwks!COMInterfaceMarshaler::FindOrCreateObjectRef+0xac
0012e428 0ae89444 001df658 11a11014 00000001 mscorwks!GetObjectRefFromComIP+0x1ec
0012e448 0ae894ab 05b3b0a8 001df658 0e896204 mscorwks!UnmarshalObjectFromInterface+0x19
0012e464 0af164d1 0012e6c8 0012e6ac 0af164c1 mscorwks!InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30
0012e470 0af164c1 0012e748 0012e738 5bdf32e1 mscorwks!DefaultMarshalOverrides<InterfaceMarshalerBase>::ReturnCLRFromNativeRetval+0xb
0012e6ac 0aeb4bff 11741a76 0012e734 0012e74c mscorwks!RunML+0x9ac
0012e780 11740172 05ae5c80 0012e7d4 501b6046 mscorwks!CLRToCOMWorker+0x25f
...
... Stack begins down here in our main COM application.

编辑1： 阅读其他论坛帖子后我的一些想法。在我看来，挂起是在将数据类型从 .NET 编组到 COM 之后引入的。现在我读到了另一个问题，它似乎源于传递给 COM 方法的局部变量被垃圾收集的事实，因此 VB6 运行时在处理释放的内存时遇到了问题。另一个帖子不完全是这个问题，但它让我思考。

在调用 COM 的 .NET 代码中，我们有这种类型的代码

void SomeNETMethod(MyObject obj, bool doIt) {
    string someString = obj.SomeString;
    this.myComComponent.DoItInCOM(ref someString, ref doIt); // This is where it hangs.
}

以及ref bool直接从方法到方法传递的参数是否与任何事情有关？如您所见，我在这里的黑暗中跌跌撞撞...

4

1 回答 1

0

检查您的“DoItInCOM”方法，因为内核转储表明正在显示模式对话框（可能是由于 COM 方法调用中的错误。）

.NET 参数被正确编组到 COM 端。如果您使用一些非标准的 C# 类型，您可能会遇到序列化问题，但这里不是这种情况。

如果您在 VB 代码中放置“On Error Goto”处理程序，您可能会抑制会在 UI 线程上生成消息的错误。如果错误是较低级别的（VB 运行时抛出它），您将需要通过直接修复 COM 组件来解决该问题。另请查看 Windows 事件查看器以获取 VB 运行时原始消息以获取更多信息。

于 2017-01-19T15:59:51.107 回答