不幸的是,这将是一个非常开放式的问题,但我在我的智慧结束,我想我会伸手去寻求一些建议。
这是使用Visual Studio 2008 SP1的Visual C ++ MFC应用程序。
一位同事和我都安装了Office 2007,因为我们的应用程序都有奇怪的DLL加载问题。具体来说,LoadLibrary无法加载我们的DLL(它加载的第一个)并返回错误代码126(找不到模块)。真正奇怪的是,如果我只是从Windows资源管理器运行可执行文件,它工作正常。
我采取了通常的步骤来诊断问题:
我真的不知道此时还有什么可做的。就像我说的,Office 2007是我们问题中的一个共同点,但我不知道它可以创建什么样的问题。我真的不知道接下来会采取什么步骤。有什么想法吗?
编辑:我很确定当前工作目录由于某种原因不在DLL路径中。似乎失败的DLL是需要任何其他DLL的DLL。如果我打开Loader Snaps调试输出,则当前工作目录似乎不在DLL加载路径中。知道是什么原因造成的吗?
edit2:当前版本将可执行文件转储到工作目录以外的目录中。出于某种原因,当我尝试加载一个然后尝试加载另一个DLL的DLL时,不再搜索当前的工作目录。通过将可执行文件放入我正在尝试加载的所有DLL的目录中,问题就会消失。基于所有这些,以及加载程序快照的输出,我98%确定这是一些奇怪的Visual Studio错误,我只需要解决它。
答案 0 :(得分:1)
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搜索路径。
答案 1 :(得分:0)
失败的DLL是否依赖于MSVCRT80?如果是,最可能的原因是Office 2007已覆盖MSVCR80.dll