问题标签 [loadlibrary]

这是我的问题：我想为同一个 DLL 创建两个单独的实例。

以下不起作用，因为 Handle1 和 Handle2 将获得相同的地址

以下工作，但我必须制作 DLL 的副本并将其重命名为其他名称（这似乎有点傻）

有没有办法只有一个 DLL 文件，但加载它的几个实例？

多年来，我们一直受到客户偶尔报告关于在我们的应用程序启动时出现的非描述性错误消息“无法设置分配”的困扰。到目前为止，我们从未能够在我们自己的测试环境中重现该问题。我现在已经没有尝试追查此事的想法了。以下是随时间积累的一系列观察结果：

• 错误消息文本为“无法设置分配”（注意没有标点符号）。
• 窗口标题只是读取“错误”（或本地化等效项）。
• 无论操作系统区域设置如何，“无法设置分配”文本始终为英文。

• 到目前为止，我无法找到包含消息文本的 DLL 或 EXE。

• 谷歌充斥着各种不同产品的此错误报告- 但没有解决方案。

• 到目前为止，我可以确定的受影响产品之间唯一统一的方面是它们似乎都以加载到第三方进程（例如 Visual Studio 的插件或 Windows Explorer shell 扩展）的 DLL 的形式出现。

• 我们的应用程序实际上是一个用于 MS Outlook 的共享软件 COM 插件，用 Delphi 编写（即本机代码 - 没有 .NET）。

• 在我们的案例中，主要嫌疑人是我们正在使用的第三方许可包装器，它可以即时解密和解压缩我们的 DLL 到内存中。显然，我不能简单地将我们应用程序的未受保护版本提供给受影响的客户来验证这种怀疑。也许被报告的其他供应商正在使用类似的产品。

• 许可供应商提供给我们的保护包装的调试版本没有产生任何结果：日志文件看起来与未发生错误的会话完全相同。显然，“内部”DLL 被解密并解压缩，但由于某种原因仍然无法被主机进程加载。

• 通过创建一个未受保护的“加载器”DLL，我们能够查明在调用之后某处发生的错误，该LoadLibrary调用应该将我们的 DLL 加载到内存中。

• 我们自己的代码（不受保护的加载程序和受保护的“核心”-DLL）中的大量日志记录和全局异常挂钩根本没有产生任何结果。该错误显然是在其他地方提出的。

• 我之前的这个问题中描述的问题很可能是由同一问题引起的。这是在我们创建不受保护的加载程序存根之前。

• 该错误仅发生在大约 1-2% 的客户身上——而通常任何受影响客户现场的所有安装都会受到同样的影响。

• 有时错误会在我们发布新版本后消失，但通常会在几周或几个月后再次出现。
• 一旦错误开始在机器上发生，它就会始终如一地发生。

• 通过远程访问（例如 VNC、RDP、TeamViewer 等）连接到受影响的机器时，该错误永远不会发生，并且受影响的客户都不在我们的旅行距离内，所以我们只需要查看日志文件和“eye-证人报告”。

• 一位客户报告说错误消息对话框显然是非模态的，即他能够简单地将对话框移到一边并继续使用应用程序（减去我们的 DLL 将提供的功能）。不确定这是否在所有其他事件中也普遍适用。

• 在某些情况下，客户可以通过禁用或卸载与我们自己的产品共享主机应用程序的其他供应商的其他插件来永久摆脱错误。

• 到目前为止，该错误已在 Windows XP、Vista 和 7 上观察到。

• 在过去的几周里，我们收到了大量来自 Outlook 2003 / Windows 7 用户的报告。最近的 Windows/Office 更新会使情况变得更糟吗？

有没有人有这个错误的经验？

或者有更多的想法来调查这个？

背景
我正在维护一个应用程序的插件。我正在使用 Visual C++ 2003。

该插件由多个 DLL 组成 - 主 DLL，即应用程序使用 LoadLibrary 加载的主 DLL，以及主 DLL 和彼此使用的多个实用程序 DLL。
依赖项通常如下所示：

• plugin.dll -> utilA.dll、utilB.dll
• utilA.dll -> utilB.dll
• utilB.dll -> utilA.dll、utilC.dll

你得到图片。

DLL 之间的一些依赖关系是加载时间和一些运行时间。

所有 DLL 文件都存储在可执行文件的目录中（不是必需的，只是它现在的工作方式）。

问题
有一个新要求——在应用程序中运行插件的多个实例。
应用程序在其自己的线程中运行插件的每个实例，即每个线程调用由plugin.dll 导出的函数。然而，插件的代码不是线程安全的——大量的全局变量等。

不幸的是，修复整个事情目前不是一个选项，所以我需要一种在同一进程中加载​​插件 DLL 的多个（最多 3 个）副本的方法。

选项 1：不同的名称方法
为每个 DLL 文件创建 3 个副本，以便每个文件都有一个不同的名称。例如plugin1.dll、plugin2.dll、plugin3.dll、utilA1.dll、utilA2.dll、utilA3.dll、utilB1.dll等。应用程序将加载plugin1.dll、plugin2.dll和plugin3.dll。这些文件将位于可执行文件的目录中。

对于每组 DLL 通过名称相互了解（因此相互依赖关系起作用），需要在编译时知道名称 - 这意味着 DLL 需要编译多次，只有每次使用不同的输出文件名。

不是很复杂，但我讨厌拥有 3 个 VS 项目文件的副本，并且不喜欢一遍又一遍地编译相同的文件。

选项 2：并行程序集方法
创建 DLL 文件的 3 个副本，每个组在其自己的目录中，并通过将程序集清单文件放入目录中来将每个组定义为程序集，列出插件的 DLL。
每个 DLL 都有一个指向程序集的应用程序清单，以便加载程序找到位于同一目录中的实用程序 DLL 的副本。需要嵌入清单，以便在使用 LoadLibrary 加载 DLL 时找到它。我将使用更高版本的 VS 中的 mt.exe 来完成这项工作，因为 VS2003 没有内置的清单嵌入支持。

我已经尝试了这种方法并取得了部分成功——在 DLL 的加载期间发现了依赖关系，但在调用加载另一个 DLL 的 DLL 函数时却没有。根据这篇文章
，这似乎是预期的行为- DLL 的激活上下文仅在 DLL 的加载时使用，之后它被停用并使用进程的激活上下文。

编辑：按预期工作ISOLATION_AWARE_ENABLED- DLL 的运行时加载使用加载 DLL 的原始激活上下文。

有
任何其他选择吗？任何快速而肮脏的解决方案都可以。:-)

ISOLATION_AWARE_ENABLED甚至可以与 VS2003 一起使用吗？编辑：确实如此。

评论将不胜感激。

谢谢！

我在 C++ 上编程，我使用的是 Visual Studio 2008、Windows XP，但我遇到了以下问题：我的应用程序是一个可以从 Python 使用的 DLL，它加载了一个外部 dll，使用了所需的方法，并且然后卸载这个外部 Dll。它工作正常，但经过 1000 多次循环后，方法“LoadLibraryA”返回一个 NULL 引用。

主要步骤是：

得到的错误是：

使用以下命令卸载 Dll：

mDLL 的定义如下：

尝试的第一个替代方案：只需加载一次 Dll，并在应用程序结束时将其卸载。这解决了问题，但引入了一个新问题。

当应用程序结束时，不是首先执行我的应用程序的 DllMain 方法，它卸载外部 DLL，而是首先执行另一个 Dll 的 DllMain 方法。这会导致以下错误，因为我的应用程序正在尝试卸载以前自行卸载的 Dll。

“Python.exe 中 0x04a00d07 (DllName.DLL) 处的未处理异常：0xC0000005：访问冲突读取位置 0x0000006b”。

任何建议都将受到欢迎。提前致谢。问候。

问题1：

有没有办法在运行时而不是在 C++/CLI 中的编译时显式加载库。目前我在编译时使用.NET“添加引用”。我想显式加载托管 dll。是否有 LoadLibrary 的 .NET 等价物？

更新：感谢 Randolpho

来自MSDN的 Assembly::LoadFrom 示例

问题2：

如果 Assembly::LoadFrom 是 LoadLibrary 的 .NET 等效项。GetProcAddress 的等价物是什么？如何为方法创建 FunctionPointers？

更新：来自MSDN的 MethodBase.Invoke

我目前正在为 .NET Compact Framework 开发项目，该项目使用 DotNetZip 读取 ZIP 文件。该项目分为两部分。一个独立于平台的库，应该可用于 CF 项目和桌面项目。这个公共库包含用于提取 ZIP 文件的代码。问题在于 DotNetZip 库有两种不同的 DLL，一种用于 .NET CF，一种用于 .NET Desktop Framework。不能在桌面框架上使用库的 CF 版本，反之亦然，但它们共享相同的界面。

如何在 Visual Studio 中组织我的项目，以便能够使用公共邮政编码并动态加载适当的 DLL（然后由邮政编码使用）？也应该可以在 PC 上执行 CF 应用程序，那么有没有办法在运行时选择 DLL？

LoadLibrary 函数向我返回错误代码 182。来自 MSDN：

ERROR_INVALID_ORDINAL：“操作系统无法运行 %1”

有没有人更好地描述这个错误是什么？

如果我使用 Win32 API LoadLibrary连续 3 次加载相同的 DLL，它应该返回 3 个不同的句柄，并且每个库中的函数都应该有不同的地址，对吗？（或者它是否做了一些“聪明”的事情并检测是否已经为进程加载了 dll 并只是指向同一个模块？）

不幸的是，这将是一个非常开放的问题，但我无能为力，我想我会寻求一些建议。

这是一个使用 Visual Studio 2008 SP1 的 Visual C++ MFC 应用程序。

我和一位同事都安装了 Office 2007，从那以后我们的应用程序都遇到了奇怪的 DLL 加载问题。具体来说，LoadLibrary 未能加载我们的一个 DLL（它加载的第一个）并返回错误代码 126（未找到模块）。真正奇怪的是，如果我只是从 Windows 资源管理器运行可执行文件，它就可以正常工作。

我采取了通常的步骤来诊断问题：

1. 验证文件是否存在以及当前工作目录是否指向它。
2. 运行dependency walker 并验证它的依赖项是否正确加载。除了这个问题说可以失败的那些之外，它们都加载正常。
3. 尝试在代码中的同一位置加载一些不同的 DLL。一些简单的“存根”dll 成功了，但大多数都失败了。
4. 尝试从单独的测试应用程序加载失败的 DLL - 在空的控制台应用程序和准系统 MFC 应用程序中，所有 DLL 都可以正常加载！
5. 尝试使用 LoadLibraryEx 和 LOAD_LIBRARY_AS_DATAFILE 标志加载 DLL，这确实成功但并没有让我们走得太远，除了指出它可能是一个依赖问题。

我真的不知道在这一点上还能做什么。就像我说的，Office 2007 是我们问题中的一个常见问题，但我不知道它会产生什么样的问题。我真的不知道接下来要采取什么步骤。有任何想法吗？

编辑：我很确定当前工作目录由于某种原因不在 DLL 路径中。似乎失败的 DLL 是需要任何其他 DLL 的 DLL。如果我打开 Loader Snaps 调试输出，当前工作目录似乎不在 DLL 加载路径中。知道是什么原因造成的吗？

edit2：当前构建将可执行文件转储到工作目录以外的目录中。出于某种原因，当我尝试加载一个 DLL 然后尝试加载另一个 DLL 时，不再搜索当前工作目录。通过将可执行文件放入包含我要加载的所有 DLL 的目录中，问题就消失了。基于所有这些，以及加载程序快照的输出，我 98% 确信这是一些奇怪的 Visual Studio 错误，我将不得不解决它。

Microsoft 发布了安全公告 (2269637) 不安全的库加载可能允许远程执行代码。

该注释提到了一个有助于检测此问题的工具以及有关Dynamic-Link Library Security 的编程指南。

这些指南如何转化为 .NET 开发？我认为这只会影响平台调用。

这仍然是导入系统库的推荐方式吗？