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\as开发者_运维知识库sembly\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.
a.dll is probably using runtime dynamic linking as a last resort http://msdn.microsoft.com/en-us/library/ms686944%28VS.85%29.aspx
精彩评论