Question about DLL search directories

[Guest]

In recent versions of Windows, the following order is used to search
for a DLL that an application wants to load:

1) the directory from which the application loaded
2) the system directory
3) the 16-bit system directory
4) the Windows directory
5) the current directory
6) the directories that are listed in the PATH environment variable

Prior to Windows XP SP2, the current directory was searched second
(before the system directory), but that was changed for security
purposes.

But can someone explain to me how the current directory could ever
contain DLLs that the program needs, if the current directory is
different from the other directories listed above? Seems like if a
program needs DLLs, then they will be located in either the
application directory (or one of its subdirectories) or in the system
directories. Why would the current directory need to be searched at
all?

 

[Dave Patrick]

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
set the value of 'SafeDllSearchMode' to 1 to alter this behavior.

http://msdn2.microsoft.com/en-us/library/ms682586.aspx

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

 

[Guest]

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
set the value of 'SafeDllSearchMode' to 1 to alter this behavior.

http://msdn2.microsoft.com/en-us/library/ms682586.aspx

Yes, but I'm trying to learn why an application would ever need to
search the current directory. Wouldn't any DLL that an application
would need be located in either its application directory (or a subdir
of that) or one of the system directories?

 

[Dave Patrick]

May also depend on DLL registrations. Really a question for the application
developer.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

 

[cquirke (MVP Windows shell/user)]

On Wed, 11 Jul 2007 10:15:06 -0700, "(e-mail address removed)"

In recent versions of Windows, the following order is used to search
for a DLL that an application wants to load:

0) In-memory copy (i.e. if the .DLL is already loaded)

1) the directory from which the application loaded
2) the system directory
3) the 16-bit system directory
4) the Windows directory
5) the current directory
6) the directories that are listed in the PATH environment variable

Prior to Windows XP SP2, the current directory was searched second
(before the system directory), but that was changed for security
purposes.

The same concern might apply to order of elements in %Path%.

But can someone explain to me how the current directory could ever
contain DLLs that the program needs, if the current directory is
different from the other directories listed above?

I think it depends on how you define "the directory from which the
application loaded". A formal installation may populate the registry
with such settings, which may be absent if the app is one that has
been scraped over, distributed as an un-automated "extract and run"
..ZIP, or otherwise does not need integration.

But I agree with you; the dir I'd look in is the dir where the primary
executable was located, not the directory that was current.

For example, I may launch C:\SomePath\RunMe.exe via a shortcut that
sets the current folder to C:\Somewhere\Else, or I may invoke the
program via a file association to process C:\Somewhere\Else\Data.xyz

In both cases, the dir to expect related .DLL would be C:\SomePath,
and not C:\Somewhere\Else - and it is really hard to think of a
context where one would want to find and use .DLL in the latter.

Seems like if a program needs DLLs, then they will be located in
either the application directory (or one of its subdirectories) or in
the system directories. Why would the current directory need to
be searched at all?

One clue suggests itself; "(or one of its subdirectories)". There is,
or should be, no searching in subdirectories for .DLLs, and yet you
could contrive the situation where common .DLLs are in a base
directory set as "current", while the actual programs being launched
are in subdirectories of this, or elsewhere.

In practice, you may find most .DLL are explicitly pathed via registry
settings - which is another potential can of worms.

--------------- ---- --- -- - - - -

"We have captured lightning and used
it to teach sand how to think."