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

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

花山ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！

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

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

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

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

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

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

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

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

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

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

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

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

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

总结

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

当前文章：为什么动态链接库以"错误"的方式被卸载？
分享网址：http://www.hantingmc.com/qtweb/news49/69499.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联