在64位操作系统上，以进程内方式加载32位本地dll的WMI提供程序（32位）。

Question

我正在开发一个进程内的WMI提供程序，使用[DllImport]加载本地第三方库。dll文件位置固定在c：\ mydllpath。在加载dll之前，在提供程序的Bind（）方法中将当前目录设置为dll位置。

Environment.CurrentDirectory = Environment.ExpandEnvironmentVariables（“％SystemDrive％”）+“\ mydllpath”;

提供程序是为“Any CPU”构建的，使用gacutil和installexe进行安装。

gacutil.exe /if myprovider.dll

installutil.exe myprovider.dll

它在所有32位Windows平台上都可以正常工作。但在64位平台上（尝试过Windows 7 64位），当我从WMIC测试时，它不起作用。但是当我使用WMI Code creator进行测试时，它可以正常工作。

调试后，我发现它会抛出以下错误。

System.BadImageFormatException 附加信息：尝试加载格式不正确的程序。（HRESULT异常：0x8007000B）

在互联网上搜索帮助后，建议将提供程序构建为x86。但是使用x86构建的提供程序会产生另一个错误，如下所示...

错误： 代码= 0x80041013 描述= 提供程序加载失败 设施= WMI

我还尝试使用/linkref命令行开关加载本地dll（实际上有2个dll和一个sys文件），但由于无法使用/linkref加载sys文件而失败。

我编写了一个测试C＃客户端应用程序，并将所有文件保留在同一路径中，它可以正常工作。 我希望我错过了64位安装的某些配置。

非常感谢您提供任何帮助！

- Muthukkumaran

---

还有其他可能性吗...？:( - Muthukkumaran

Answer 1

您需要代码是64位的吗？您可以告诉Visual Studio将您的C#代码编译为32位可执行文件，然后使用32位本机DLL。这在64位操作系统上也能正常工作。

默认情况下，.NET将.NET IL编译为本机指令集。在项目设置的“生成”选项卡上，如果构建目标设置为“任何CPU”，则它将在32位平台上编译为32位，在64位平台上编译为64位。

如果您更改并强制进行32位编译（将其设置为x86），则它将即使在64位平台上也会编译为32位，允许您使用32位DLL。

更新：在重新阅读您的问题时，您表示正在构建进程内WMI提供程序。这表明提供程序在64位平台上可能需要是64位的（我不知道是否是这种情况）。如果是这样，那么...您就没办法了。

更新2：此文章似乎表明，在“罕见情况”以外的64位操作系统上，WMI提供程序无需是64位的，因此您可能可以使用32位提供程序。

- Erik Funkenbusch

---

非常感谢你，神秘的人。我正在使用进程内提供程序。我也尝试为x86构建我的提供程序，但没有成功。现在我正在等待我的客户提供的64位本机dll。 - Muthukkumaran

最终我的客户提供了一个64位的dll文件，解决了这个问题。 - Muthukkumaran

Answer 2

抱歉，朋友，这里运气不佳。如果您的进程（即主进程，所有启动的进程）正在运行64位，则无法加载32位本机dll。

这里是一篇描述一些困难的文章。

- ralf.w.

---

谢谢Ralf。我们会尝试从客户那里获取64位的dll并进行尝试。 - Muthukkumaran

最后我的客户提供了一个64位的dll解决了这个问题。谢谢ralf.v。 - Muthukkumaran