不完全确定我是否已经解决了这个问题，但这是我所看到的以及我认为正在发生的事情。

我有一个主要用 C 编写的 Win32 程序，它加载一个 C++ DLL。该 DLL 通过 COM 对象将数据从 C 程序传递到另一个应用程序——一个可能由 DLL 本身实例化的对象。所有这一切显然至少在 Windows XP 和 Windows 7 中运行良好(可能是 Win95 和 Win98，我需要更深入地回顾代码历史以找出引入此接口(interface)的时间)，但在 Windows 10 中程序崩溃在 FreeLibrary() 调用此 DLL 期间。

在调试器中检查时，DLL_DETACH_PROCESS 似乎已成功处理(处理该消息时未执行任何代码)。崩溃发生在(或同时)从入口点离开代码。

如果我继续 Step In，我最终会看到一个名为 utilcls.h 的头文件，它似乎是 Borland C Builder 6 头文件之一。我相信其中的模板代码与被拆除的 COM 对象有关。 Unbind() 调用通过，这是崩溃前我可以单步执行的最后一行代码。

如果我使用调试器的 CPU 窗口并继续步进，剩下的一切似乎都与在崩溃发生前释放内存有关，但要达到那里需要大量的 CPU 步进。

崩溃引发 APPCRASH 异常 0xc0000602，返回 Combase.dll。

只要不为该 DLL 调用 FreeLibrary 即可使应用程序成功关闭，但我的假设是 FreeLibrary 调用很重要。

COM 对象在 FreeLibrary() 调用之前由数据共享应用程序释放，这允许该应用程序关闭。我目前的假设是，某些取消链接在较新的操作系统中发生的情况有所不同，这导致了崩溃，但我不知道如何确定。

我的问题:

• 如果其他人更清楚自己在做什么，那么导致崩溃的原因是什么？

• 尝试调试它的下一步是什么？我已经用尽了我对正在使用的调试环境的了解，并且对 COM 或 DLL 的了解不够深，不知道下一个要问的问题是什么。

RbMm 请求的一些调试器输出:

0:000:x86> t
ntdll_77b40000!RtlIsCriticalSectionLockedByThread+0x1b:
77b7256b c20400          ret     4
0:000:x86> t
combase!DecrementMTAUsageHelper+0x5b:
7527a2d6 85c0            test    eax,eax
0:000:x86> r eax
eax=00000001
0:000:x86> t
combase!DecrementMTAUsageHelper+0x5d:
7527a2d8 0f859a000000    jne     combase!DecrementMTAUsageHelper+0xfd (7527a378) [br=1]
0:000:x86> t
combase!DecrementMTAUsageHelper+0xfd:
7527a378 e89e9e0f00      call    combase!CrashProcessWithWERReport (7537421b)

此时，堆栈大致如下所示:

ChildEBP RetAddr  Args to Child              
0019f9b8 7527a37c 063f4248 753d8448 00000000 combase!CrashProcessWithWERReport+0x35
0019f9e8 75292bfc 753d8448 7529257e 00000000 combase!DecrementMTAUsageHelper+0x101
(Inline) -------- -------- -------- -------- combase!DecrementMTAUsage+0x9
0019f9f0 7529257e 00000000 00000000 00000000 combase!CDllHost::MTAUninitializeApartmentOnly+0xe
0019fa08 7527543a 00000000 063f4248 00712410 combase!CDllHost::ClientCleanupFinish+0x4d
0019fa30 75276361 00000000 0019fa8c 00000000 combase!DllHostProcessUninitialize+0xa0
0019fa58 7527a452 000d06f6 00712410 00000000 combase!ApartmentUninitialize+0xe4
0019fa70 752c2a1e 000d06f6 00712e18 00712e80 combase!wCoUninitialize+0xd0
0019fa94 74ed3e58 00000003 74c17ff1 a6d0e607 combase!CoUninitialize+0x7e
0019fa9c 74c17ff1 a6d0e607 000b0792 74ed48f0 imm32!CtfImmCoUninitialize+0x48
0019fb7c 74809ea6 00050004 000d06f6 00000000 msctf!TF_Notify+0x581
0019fb98 748080dc 00050004 000d06f6 00000000 user32!CtfHookProcWorker+0x36
0019fbe0 74807fa6 0019fc34 0019fc24 00000000 user32!CallHookWithSEH+0x5c
0019fc08 77bb0006 0019fc24 00000018 0019fc80 user32!__fnHkINDWORD+0x26
0019fc38 710623fb 000b0792 04ff11aa 05480e70 ntdll!KiUserCallbackDispatcher+0x36
0019fc50 050364e4 000b0792 050376d8 05480e70 apphelp!DWM8AND16BitHook_DestroyWindow+0x2b
0019fc8c 05051007 00000000 05055034 00000001 myDLL!myCOMObject_tlbFinalize+0x408a4
0019fcb4 050511c6 0019fcd0 00000001 04ff1318 myDLL!myCOMObject_tlbFinalize+0x5b3c7
0019fcd8 04ff13d3 05055034 77badcce 04ff0000 myDLL!myCOMObject_tlbFinalize+0x5b586
0019fd00 77b807c6 04ff1318 04ff0000 00000000 myDLL+0x13d3
0019fd50 77b6aa5e 00000000 00000000 259704e5 ntdll!LdrpCallInitRoutine+0x43
0019fdb8 77b6e6c8 00000000 0071dd60 00000000 ntdll!LdrpProcessDetachNode+0xbb
0019fdd8 77b6e5af 25970745 0071e560 c000022d ntdll!LdrpUnloadNode+0x100
0019fe18 77b6e4f6 004afcc4 004ae3a4 04ff0000 ntdll!LdrpDecrementModuleLoadCountEx+0xa7
0019fe38 746e9d56 04ff0000 006e33c5 00000000 ntdll!LdrUnloadDll+0x86
0019fe4c 0049261c 04ff0000 00000000 00493034 KERNELBASE!FreeLibrary+0x16
0019fe64 00441895 004afc98 fffffffe 0019fee8 rpopdbg!_GetExceptDLLinfo+0x914bf

现在正在处理其余部分，但我想我需要弄清楚如何正确地对 COM 对象进行清理？也许是为了响应 DLL_DETACH_PROCESS？

最佳答案

The crash raises APPCRASH with exception 0xc0000602, referring back to Combase.dll

combase.dll 使用 0xc0000602 (STATUS_FAIL_FAST_EXCEPTION) 代码仅来自

void CrashProcessWithWERReport();

(使用此代码调用了 RaiseFailFastException)

CrashProcessWithWERReport 仅在 2 个条件下从 DecrementMTAUsageHelper 调用 - CoDecrementMTAUsage调用次数超过 CoIncrementMTAUsage或者(我几乎可以肯定是因为这个原因)DecrementMTAUsageHelper 在调用线程时调用保持 Loader 临界区 - 因此在 DLL 加载或卸载过程中。来自MSDN

Don't call CoDecrementMTAUsage during process shutdown or inside dllmain. You can call CoDecrementMTAUsage before the call to start the shutdown process.

所以我猜 - 一些代码调用 CoDecrementMTAUsage在你的 DLL 卸载过程中(当你调用 FreeLibrary 时)

你的DLL不能直接调用CoIncrementMTAUsage/CoDecrementMTAUsage因为这个新的 API 从 win 8 开始就存在(还要检查你在 win 8.1 上的代码——我想也会崩溃)，但是这个 api 可以从其他系统组件间接调用。

我可以假设您的 DLL 不直接释放一些已用资源，或者您在 DLL 仍持有一些资源时调用 FreeLibrary(因此您调用 FreeLibrary 时没有对 DLL 进行适当的清理调用) 并且因此该资源在卸载过程中开始释放 (CoDecrementMTAUsage)

what are the next steps in trying to debug this?

您需要使用符号文件进行调试(比如使用 winDbg)。在 DecrementMTAUsageHelper、CoDecrementMTAUsage 处设置断点并且可能是 CoIncrementMTAUsage - 我调用RtlIsCriticalSectionLockedByThread 是否正确返回 TRUE(此 api 从 DecrementMTAUsageHelper 开始调用)。

在任何情况下，在 DecrementMTAUsageHelper 调用点(就在崩溃之前)发布线程调用堆栈，也可能在 CoIncrementMTAUsage 上发布

-------------------- 编辑 -------------------- ----

通过查看堆栈跟踪可见，您的 DLL 从 DllMain 调用 DestroyWindow。

apphelp!DWM8AND16BitHook_DestroyWindow

这是错误的两个原因 - 首先 - 阅读 this article -

The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification. You can't do anything with thread affinity in your DLL_PROCESS_ATTACH or DLL_PROCESS_DETACH handler since you have no guarantee about which thread will be called upon to handle these process notifications. The classic example of this, which I'm told the Developer Support team run into with alarming frequency, is a DLL that creates a window in its DLL_PROCESS_ATTACH handler and destroys it in its DLL_PROCESS_DETACH handler.

但您的崩溃是由于其他原因造成的，未在文章中列出 - DllMain 有很多 restrictions ，里面不能叫什么。尽管 DestroyWindow 没有直接在此处列出，但正如您的情况所示 - 这是非法调用(即使我们在创建此窗口的同一线程上调用) - 当您的窗口被销毁时 imm32 .CtfImmNotify(msctf!TF_Notify) 被调用

0019fa9c 74c17ff1 a6d0e607 000b0792 74ed48f0 imm32!CtfImmCoUninitialize+0x48
0019fb7c 74809ea6 00050004 000d06f6 00000000 msctf!TF_Notify+0x581
0019fb98 748080dc 00050004 000d06f6 00000000 user32!CtfHookProcWorker+0x36
0019fbe0 74807fa6 0019fc34 0019fc24 00000000 user32!CallHookWithSEH+0x5c

结果CoUninitialize 从 DllMain 调用 !

来自 MSDN

do not call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.

这里是FINAL CoUninitialize称为 DecrementMTAUsage，它通过调用 RtlIsCriticalSectionLockedByThread 和调用的 CrashProcessWithWERReport 确定我们在加载程序锁内。

解决方案？

当然最好的办法是修复 DLL，但如果这不可能 - 考虑下一个“hack”就可以了

HRESULT hr = CoInitialize(0); // asume that we in STA
FreeLibrary(hDLL); 
if (0 <= hr) CoUninitialize();

有了这个CoUninitialize当然无论如何都会从 imm32!CtfImmCoUninitialize 调用，但这将是 NOT FINAL 未初始化，因此 DecrementMTAUsage 将不会被调用

关于c - 在 Win 10 而非 Win 7 中卸载 DLL 时调试崩溃，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41008037/