在 Win 10 而非 Win 7 中卸载 DLL 时调试崩溃
Debugging a crash while unloading DLL in Win 10, but not Win 7
不完全确定我是否已经解决了这个问题，但这是我所看到的以及我认为正在发生的事情。
我有一个主要用 C 编写的 Win32 程序，用于加载 C++ DLL。该 DLL 通过 COM 对象将数据从 C 程序传递到另一个应用程序——一个可能由 DLL 本身实例化的对象。所有这一切在至少 Windows XP 和 Windows 7 中显然都运行良好（可能是 Win95 和 Win98，我需要更深入地回顾代码历史以找出引入此接口的时间） , 但在 Windows 10 中程序在为此 DLL 调用 FreeLibrary() 期间崩溃。
在调试器中检查时，DLL_DETACH_PROCESS 似乎已成功处理（处理该消息时未执行任何代码）。崩溃发生在（或同时）离开入口点的代码。
如果我继续 Step In，我最终会看到一个名为 utilcls.h 的头文件，它似乎是 Borland C Builder 6 头文件之一。我相信其中的模板代码与被拆除的 COM 对象有关。 Unbind() 调用通过，这是崩溃前我可以单步执行的最后一行代码。
如果我使用调试器的 CPU window 并继续单步执行，剩下的所有内容似乎都与在崩溃发生前释放内存有关，但它相当多 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 called more times than 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.
所以我猜 - 在你的 DLL 卸载过程中一些代码调用 CoDecrementMTAUsage（当你调用 FreeLibrary）
你的DLL不能直接调用CoIncrementMTAUsage / CoDecrementMTAUsage 因为这个新的API, exist begin from win 8 (also check your 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 return TRUE 是否正确（这个 api 从 DecrementMTAUsageHelper 开始调用。
在任何情况下 post 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 没有直接列在这里，但正如你的情况所示 - 这是非法调用（即使我们在同一个线程上调用，这个 window 是在该线程上创建的） - 而你的 window 是销毁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 编写的 Win32 程序，用于加载 C++ DLL。该 DLL 通过 COM 对象将数据从 C 程序传递到另一个应用程序——一个可能由 DLL 本身实例化的对象。所有这一切在至少 Windows XP 和 Windows 7 中显然都运行良好（可能是 Win95 和 Win98，我需要更深入地回顾代码历史以找出引入此接口的时间） , 但在 Windows 10 中程序在为此 DLL 调用 FreeLibrary() 期间崩溃。
在调试器中检查时，DLL_DETACH_PROCESS 似乎已成功处理（处理该消息时未执行任何代码）。崩溃发生在（或同时）离开入口点的代码。
如果我继续 Step In，我最终会看到一个名为 utilcls.h 的头文件，它似乎是 Borland C Builder 6 头文件之一。我相信其中的模板代码与被拆除的 COM 对象有关。 Unbind() 调用通过，这是崩溃前我可以单步执行的最后一行代码。
如果我使用调试器的 CPU window 并继续单步执行，剩下的所有内容似乎都与在崩溃发生前释放内存有关，但它相当多 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 called more times than 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.
所以我猜 - 在你的 DLL 卸载过程中一些代码调用 CoDecrementMTAUsage（当你调用 FreeLibrary）
你的DLL不能直接调用CoIncrementMTAUsage / CoDecrementMTAUsage 因为这个新的API, exist begin from win 8 (also check your 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 return TRUE 是否正确（这个 api 从 DecrementMTAUsageHelper 开始调用。
在任何情况下 post 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 没有直接列在这里，但正如你的情况所示 - 这是非法调用（即使我们在同一个线程上调用，这个 window 是在该线程上创建的） - 而你的 window 是销毁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 将不叫