为什么动态链接库以“错误“的方式被卸载?

当程序启动或加载 DLL 时，加载器将生成该程序/DLL 引用的所有 DLL、该 DLL 的依赖项等的依赖项树。然后，它确定初始化这些 DLL 的正确顺序，以便在初始化它所依赖的所有 DLL 之前，不会初始化任何 DLL。
（当然，如果你有一个循环依赖关系，那么它就会崩溃。众所周知，从 DLL 的DLL_PROCESS_ATTACH 通知中调用加载库函数或 LoadLibraryEx 函数也会弄乱这些依赖项的计算过程。)

同样，当卸载 DLL 或程序终止时，将进行反初始化，以便在 DLL 的所有依赖项之后反初始化该 DLL。

但是，当你手动加载 DLL 时，关键信息会丢失：即调用 LoadLibrary 的 DLL 取决于正在被加载的 DLL。因此，如果 A.DLL 手动加载 B.DLL，则不能保证 A.DLL 将在 B.DLL 之前卸载。这意味着，例如，像下面这样的代码是不可靠的：

>> 请移步至 topomel 以查看图片 <<

在标记为 “oops” 的行中，不能保证 B.DLL 仍在内存中，因为 B.DLL 不会出现在 A.DLL 的依赖项列表中，即使存在由对 LoadLibrary 的调用导致的运行时生成的动态依赖项。

为什么加载器无法跟踪此动态依赖项？换句话说，当A.DLL调用LoadLibrary(“B.DLL”) 时，为什么加载器不能自动说“好吧，现在A.DLL依赖于B.DLL”？

首先，因为正如我在之前的文章中所指出的，你不能相信返回地址。

其次，即使你可以相信返回地址，你仍然不能相信返回地址。我们看看下面的代码：

>> 请移步至 topomel 以查看图片 <<

在这种情况下，B.DLL 的加载不是直接从A.DLL发生的，而是通过中间（在本例中为中间函数）发生的。即使你可以相信返回地址，依赖项也会分配给 MID.DLL 而不是A.DLL。

你可能会问，”什么样的人会写出像中函数这样的函数呢？”。这种中间函数在帮助函数/包装器函数很常见，或者为了提供额外的生存期管理功能（尽管它现在不再这样做了，但是它曾经这样做过）。

第三，有调用 GetModuleHandle 函数的情况。我们看看下面的代码：

>> 请移步至 topomel 以查看图片 <<

我们对 GetModuleHandle 的调用，是否应创建依赖项呢？

另请注意，DLL 之间存在的依赖关系不仅仅是对 LoadLibrary 的调用。
例如，如果将回调函数指针传递给另一个 DLL，则就会创建一个反向依赖项。

最后要注意的是，这种隐式依赖关系，就像上面写的那样很难看到，一旦你把全局析构函数扔进去，情况就更糟了。例如下面的代码：

>> 请移步至 topomel 以查看图片 <<

DLL 依赖项现在隐藏在 SomethingHolder 类中，当 A.DLL 卸载时，g_SomethingHolder的析构函数将运行并尝试与 B.DLL 通信。
随之而来的，是程序的不可预知的行为。

总结

尽量不对系统运行行为做出过多的假设，严格按照 MSDN 所说的，老老实实写你的代码，基本不会有大错误。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Why are DLLs unloaded in the “wrong” order?》