DLL 未从记录的搜索路径加载
我有一个进程正在从记录的搜索顺序中未列出的位置加载 DLL（下面链接的文档）。我想知道为什么。
这是我的设置的描述：
- 我有一个文件夹“c:\foo”，其中包含 a.dll 和 b.dll。
- 我有一个 python 脚本也存储在 c:\foo 中。
- python 脚本执行 LoadLibrary('c:/foo/a.dll') （通过 ctypes）
- 将 a.dll 链接到 b.dll 的导入库（即使用隐式链接）。
- 我使用当前目录（例如 c:）运行 python 脚本。它可以是任何东西。
- b.dll 是从 c:\foo 加载的，即使它不在搜索路径上。
- 查看进程监视器跟踪，我可以看到首先尝试了所有记录的搜索路径，并且全部失败了。然后python进程尝试打开“C：\ WINDOWS \ assembly \ GAC \ Microsoft.VC80.CRT.mui \ 8.0.50727.4053_en-US_1fc8b3b9a1e18e3b \ Microsoft.VC80.CRT.mui.DLL”失败，然后它打开 c:\foo\b.dll。
所以，似乎 a.dll 的正在搜索 b.dll 目录，尽管文档没有说明应该这样做。另外，在查看系统路径后会发生这种情况，这很疯狂。任何人都可以阐明这一点吗？
同样的情况也发生在同样使用 a.dll 的 MatLab 脚本上。
我运行的是 Windows XP SP 3。
此 MSDN文章 解释了默认搜索顺序。我引用：
- lpFileName指定的目录。
- 系统目录。使用 GetSystemDirectory 函数获取该目录的路径。
- 16位系统目录。没有函数获取这个目录的路径，但是会搜索。
- Windows 目录。使用 GetWindowsDirectory 函数获取该目录的路径。
- 当前目录。
- PATH 环境变量中列出的目录。请注意，这不包括应用程序路径注册表项指定的每个应用程序路径。计算 DLL 搜索路径时不使用 App Paths 键。
I have a process which is loading a DLL from a place not listed in the documented search order (docs linked below). I want to know why.
Here's the description of my setup:
- I have a folder 'c:\foo' containing a.dll and b.dll.
- I have a python script also stored in c:\foo.
- The python script does a LoadLibrary('c:/foo/a.dll') (via ctypes)
- a.dll is linked against the import library for b.dll (ie using implicit linking).
- I run the python script with a current directory of, say, c:. It could be anything.
- b.dll is loaded from c:\foo, even though that isn't on the search path.
- Looking at the process monitor trace, I can see that all the documented search paths were tried first, and all failed. Then the python process tried and failed to open "C:\WINDOWS\assembly\GAC\Microsoft.VC80.CRT.mui\8.0.50727.4053_en-US_1fc8b3b9a1e18e3b\Microsoft.VC80.CRT.mui.DLL", then it opened c:\foo\b.dll.
So, it seems to be that the a.dll's directory is being searched for b.dll even though the docs don't say it should be. Also, this happens after looking on the system path, which is mad. Can anyone shed any light on this?
The same thing happens with a MatLab script that also uses a.dll.
I'm running Windows XP SP 3.
This MSDN article explains the default search order. I quote:
- The directory specified by lpFileName.
- The system directory. Use the GetSystemDirectory function to get the path of this directory.
- The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
- The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
- The current directory.
- The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
a.dll 可能使用运行时动态链接作为最后的手段
http://msdn.microsoft.com/en-us /library/ms686944%28VS.85%29.aspx
a.dll is probably using runtime dynamic linking as a last resort
http://msdn.microsoft.com/en-us/library/ms686944%28VS.85%29.aspx