找不到LoadLibrary模块 - Office 2007安装后的DLL Hell [英] LoadLibrary Module Not Found - DLL Hell After Office 2007 Install

问题描述

不幸的是，这将是一个非常开放的问题，但是我在机智的目的，我想我会提出一些建议。

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

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

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

1. 验证文件存在，目前的工作目录指向它。


2. 运行依赖关系Walker并验证其依赖是否正确加载。除了此问题之外，它们都正常加载说可以失败。


3. 在代码中的相同位置加载一些不同的DLL。一些简单的stubDLL成功，但大多数都失败了。


4. 尝试加载单独测试应用程序失败的DLL - 在空控制台应用程序和准系统MFC应用程序，所有的DLL都正在加载！


5. 尝试使用LoadLibraryEx和LOAD_LIBRARY_AS_DATAFILE标志加载DLL，这样做成功，但不能让我们非常远，除非指出它可能是一个依赖问题。

在这一点上，我真的不知道还有什么要做的。就像我说的那样，Office 2007是我们问题中的常见线索，但我不知道它可以创建什么样的问题。我真的不知道下一步要采取什么步骤。任何想法？

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

edit2：当前构建将可执行文件转储到工作目录以外的目录中。由于某些原因，当我尝试加载一个DLL，然后尝试加载ANOTHER DLL时，不再搜索当前的工作目录。通过将可执行文件放入我正在尝试加载的所有DLL的目录中，问题就会消失。基于所有这一切，通过加载器捕捉的输出，我98％肯定这是一些奇怪的Visual Studio错误，我将只需要解决它。

解决方案

Office 2007在注册表中打开SafeDllSearchMode。

http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

使用SafeDlLSearchMode，不再搜索当前目录。要禁用它，他们声称您可以进入regedit并将HKLM / System / CurrentControlSet / Control / SessionManager / SafeDllSearchMode设置为0，但这对我来说无效。调用SetDllDirectory到当前目录DID可以为我工作，虽然这只适用于您的目标XP SP1 +。

我的具体应用程序导致问题的原因是，当我们从调试器运行可执行文件，我们将可执行文件保留在与目前所有其他构建文件相同的目录中。当我们在Visual Studio之外运行时，我们首先将可执行文件复制到所有其他DLL的目录中。调用原始可执行文件的目录是搜索路径中的所有目录，所以如果您将可执行文件和dll保存在一起，则不会遇到此问题。

不过，对于微软来说，改变我们下面的dll搜索路径是非常困惑的。

Unfortunately this is going to be a pretty open-ended question, but I am at my wit's ends and I thought I would reach out for some advice.

This is a Visual C++ MFC app using Visual Studio 2008 SP1.

A coworker and I both had Office 2007 installed and we have both had strange DLL loading problems with our app since. Specifically, LoadLibrary is failing to load one our DLLs ( the first one it loads ) and returning error code 126 ( module not found ). What's really strange is that if I just run the executable from the windows explorer it works fine.

I took the usual steps to diagnose the problems:

1. Verify that the file existed and that the current working directory was pointed at it.
2. Run dependency walker and verify that it's dependencies are loading correctly. They are all loading ok except the ones this question says are ok to fail.
3. Experiment with loading some different DLLs at the same location in the code. Some of the simple 'stub' dlls succeed, but most of them fail.
4. Experiment with loading the DLLs that are failing from separate test apps - in an empty console app and a barebone MFC app, all the DLLs are loading fine!
5. Try to load the DLLs with LoadLibraryEx and the LOAD_LIBRARY_AS_DATAFILE flag, which does succeed but doesn't get us very far except to point out it's probably a dependency problem.

I really don't know what else to do at this point. Like I said, Office 2007 is a common thread in our problem but I don't know what kind of problems it could create. I really don't know even what steps to take next. Any ideas?

edit: I'm pretty sure the current working directory is not in the DLL path for some reason. It seems the DLLs that are failing are ones that need any other DLLs. If I turn on Loader Snaps debug output the current working directory does not appear to be in the DLL loading path. Any idea what could cause this?

edit2: The current build dumped the executable into a directory other than the working directory. For some reason, when I tried to load a DLL which then tried to load ANOTHER DLL, the current working directory is no longer searched. By putting the executable into the directory with all of the DLLs I am trying to load, the problems go away. Based on all of this, and the output by loader snaps, I am 98% sure this is some bizarre Visual Studio bug and I will simply have to work around it.

解决方案

Office 2007 turns on SafeDllSearchMode in the registry.

http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

With SafeDlLSearchMode, the current directory is no longer searched. To disable it, they claim you can go into regedit and set HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode to 0, but this did not work for me. Calling SetDllDirectory to the current directory DID work for me, although this only works if you are targeting XP SP1+.

The reason this caused problems in my specific app is that when we run the executable from the debugger, we keep the executable in a different directory than the current directory with all the other build files. When we run outside of Visual Studio, we first copy the executable into the directory with all of the other DLLs. The directory that the original executable is called from is ALWAYS in the search path, so if you keep your executable and your dlls together, you would never run into this problem.

Still, it's quite confusing for Microsoft to change the dll search path under us like this.

这篇关于找不到LoadLibrary模块 - Office 2007安装后的DLL Hell的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！