在尝试解析 process hanging on CoUninitialize() 时，我发现了一段由我们的许多项目共享的代码。当程序要退出时，它首先调用CoFreeUnusedLibraries()，然后立即调用OleUninitialize()。
虽然OleUninitialize() 的效果很明显，但我不明白为什么要在调用OleUnitialize() 之前先调用CoFreeUnusedLibraries()。在这个特定的时刻，这个调用可能有什么用？
【问题讨论】：
标签： windows visual-c++ winapi com
CoFreeUnusedLibraries() 将为导出此函数的每个进程内 COM DLL 触发对 DllCanUnloadNow 的调用。不确定与此 API 相关的线程问题或进程外 COM 组件。
据推测，在 OleUnitialize 之前编写调用 DllCanUnloadNow 的代码的人试图减少工作集并确保清理。
我认为在应用程序关闭之前调用 CoFreeUnusedLibraries 没有多大价值（DLL 无论如何都会被卸载）。
我的经验是，调用 CoFreeUnusedLibraries 会导致崩溃并挂起 3rd 方 COM DLL，这些 DLL 在发布前从未测试过其 DllCallUnloadNow 实现。 （因为没有太多应用调用这个函数）。
您没有提供调用堆栈或有关挂起发生位置的提示（您是否闯入调试器以查看堆栈顶部的 DLL 是什么？）。我的猜测是，如果您无法修复有问题的 DLL，您可能会取消此调用。
【讨论】：
Docs表示
此功能是为 与 16 位 Windows 兼容。
嗯……
你见过this problem report吗？这个调用对我来说似乎是多余的——也许这会使一个或多个 DLL 处于 OleUninitialize 无法正常工作的状态——等待由于早期调用而导致的某些状态更改。然而，这确实暗示需要在通话之间等待一段时间......
CoFreeUnusedLibraries 不 立即释放没有 活动对象。有十分钟 多线程公寓的延迟 (MTA) 和中性公寓 (NA)。 对于单线程单元 (STA)， 没有延迟。十分钟 CoFreeUnusedLibraries 的延迟是 避免多线程竞争条件 由卸载组件 DLL 引起。
其他地方也有 cmets 回复 6 -minute closedown timeout when using DCOM - 这适用于您吗？
【讨论】：