在試圖解決process hanging on CoUninitialize()時，我遇到了許多項目共享的一段代碼。當一個程序要退出時，首先調用CoFreeUnusedLibraries()，然後立即OleUninitialize()。爲什麼在OleUninitialize（）之前調用CoFreeUnusedLibraries（）？
儘管OleUninitialize()的影響非常明顯，但我無法找到爲什麼在撥打OleUnitialize()之前想要撥打CoFreeUnusedLibraries()。在這個具體點上使用這個調用可能是什麼？
Docs表明
此功能提供了 兼容16位Windows。
嗯...
你見過this problem report？這個調用對我來說似乎是多餘的 - 也許這會讓一個或多個DLL處於OleUninitialize無法正常工作的狀態 - 等待由於先前的調用而導致的某些狀態更改。然而，這並不暗示需要等待的呼叫之間，而...
CoFreeUnusedLibraries不 立即釋放那些沒有 活動對象的DLL。多線程公寓 （MTA）和中立公寓（NAs）有10分鐘延遲。 對於單線程套件（STA）， 沒有任何延遲。 CoFreeUnusedLibraries延遲的十分鐘 是 避免因卸載組件DLL而導致多線程競爭條件 。
還有其他地方的評論6 -minute closedown timeout when using DCOM - 是否適用於您？
對於導出此函數的每個進程內COM DLL，CoFreeUnusedLibraries（）將觸發對DllCanUnloadNow的調用。不確定線程問題或與此API有關的進程外COM組件。
據推測，編寫在OleUnitialize之前調用DllCanUnloadNow的代碼的人正試圖減少工作集並確保清理。
我認爲在應用程序關閉之前調用CoFreeUnusedLibraries沒有太大的價值（DLL無論如何都會被卸載）。
我的經驗是，調用CoFreeUnusedLibraries會導致崩潰並掛起到第三方COM DLL中，這些DLL在發佈之前從未進行過DllCallUnloadNow實現測試。 （因爲沒有太多的應用程序調用這個函數）。
您沒有提供關於掛起發生的位置的調用堆棧或提示（是否打入調試器以查看堆棧頂部的DLL？）。我的猜測是，如果你無法修復有問題的DLL，你很可能會接受這個調用。