未找到 LoadLibrary 模块 - 安装 Office 2007 后出现 DLL Hell
不幸的是，这将是一个非常开放式的问题，但我已经无计可施，我想我应该寻求一些建议。
这是一个使用 Visual Studio 2008 SP1 的 Visual C++ MFC 应用程序。
我和一位同事都安装了 Office 2007，从那以后我们的应用程序都遇到了奇怪的 DLL 加载问题。具体来说，LoadLibrary 无法加载我们的 DLL（它加载的第一个）并返回错误代码 126（未找到模块）。真正奇怪的是，如果我只是从 Windows 资源管理器运行可执行文件，它就可以正常工作。
我采取了通常的步骤来诊断问题：
- 验证该文件是否存在以及当前工作目录是否指向该文件。
- 运行 dependency walker 并验证其依赖项是否正确加载。除了这个问题之外，它们都加载正常说失败也没关系。
- 尝试在代码中的同一位置加载一些不同的 DLL。一些简单的“存根”DLL 会成功，但大多数都会失败。
- 尝试加载从单独的测试应用程序失败的 DLL - 在空控制台应用程序和准系统 MFC 应用程序中，所有 DLL 都加载良好！
- 尝试使用 LoadLibraryEx 和 LOAD_LIBRARY_AS_DATAFILE 标志加载 DLL，这确实成功了，但并没有让我们走得太远，除了指出这可能是一个依赖性问题。
我现在真的不知道还能做什么。正如我所说，Office 2007 是我们问题中的一个常见问题，但我不知道它会产生什么样的问题。我真的不知道下一步该采取什么步骤。有什么想法吗？
编辑：我很确定由于某种原因当前工作目录不在 DLL 路径中。似乎失败的 DLL 需要任何其他 DLL。如果我打开 Loader Snaps 调试输出，当前工作目录似乎不在 DLL 加载路径中。知道什么可能导致这种情况吗？
edit2：当前版本将可执行文件转储到工作目录以外的目录中。由于某种原因，当我尝试加载一个 DLL，然后又尝试加载另一个 DLL 时，不再搜索当前工作目录。通过将可执行文件放入包含我尝试加载的所有 DLL 的目录中，问题就会消失。基于所有这些，以及加载器快照的输出，我 98% 确定这是一些奇怪的 Visual Studio 错误，我只需解决它即可。
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:
- Verify that the file existed and that the current working directory was pointed at it.
- 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.
- 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.
- 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!
- 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
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 到当前目录确实对我有用，尽管这只在您的目标是 XP SP1+ 时才有效。
这在我的特定应用程序中导致问题的原因是，当我们从调试器运行可执行文件时，我们将可执行文件保存在与所有其他构建文件的当前目录不同的目录中。当我们在 Visual Studio 之外运行时，我们首先将可执行文件复制到包含所有其他 DLL 的目录中。调用原始可执行文件的目录始终位于搜索路径中，因此如果将可执行文件和 dll 放在一起，则永远不会遇到此问题。
尽管如此，微软这样改变我们下面的dll搜索路径还是很令人困惑的。
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.
失败的 DLL 是否有 MSVCRT80 依赖项？如果是，最可能的原因是 Office 2007 覆盖了 MSVCR80.dll
Does the DLL which fails has MSVCRT80 in dependencies? If yes, the most likely reason is that Office 2007 has overridden MSVCR80.dll