Windows under DLL Lookup order

Windows under DLL Lookup order

Tocy Time: 2014-10-18

First, the purpose of writing

There may be several different versions of a single DLL under Windows, and if you do not specifically specify the absolute path of the DLL or use other means to specify it, you may find the wrong version when the application loads the DLL, which leads to a variety of inexplicable problems. This article mainly considers the following two aspects:

A. Refer to MSDN for the sequence of DLL lookups under Windows

B. Simple use of Processmonitor to verify the DLL lookup order

Second, DLL lookup order

(Most of this section refers to the Dynamic-link Library Search Order article on MSDN, which is linked as follows http://msdn.microsoft.com/en-us/library/ms682586 (v=vs.85 ). aspx. Most of them are translations, some of which are modified. This article focuses only on the search order for desktop applications, and for Windows Store apps, refer to the MSDN original. ）

1. DLL Lookup Path Basics

An application can control the load path of a DLL by using full path loading, using DLL redirection, and using the manifest file. If none of the above three methods are specified, the order in which the system looks for the DLLs will be in the order described in this section.

For the following two cases of DLLs, the system will not find, but directly load:

A. For DLLs that have been loaded into memory with the same name, the system uses DLLs that have already been loaded and ignores the path to the DLL to be loaded. (Note that for a process, a DLL already loaded by the system must be unique in a directory.) ）

B. If the DLL exists in a list of known DLLs for a Windows version (the unkown DLL), the system uses a copy of the known DLL (including dependencies for known DLLs). The list of known DLLs can be seen from the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\knowndlls.

There's a hole here. For DLLs that have dependencies, even if you use full paths to specify DLL locations, the way the system looks for its dependent DLLs is based on the actual module name, so if the loaded DLL is not in the system lookup order directory, Then dynamically loading the DLL (LoadLibrary) returns a "module not found" error.

2. System Standard DLL Lookup order

The standard DLL lookup order used by the system depends on whether "secure DLL lookup Mode" is set (safe DLL search modes). Secure DLL Lookup mode places the user's current directory behind the lookup order.

The secure DLL lookup mode is enabled by default, and if disabled, the registry key can be HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ SafeDllSearchMode is set to 0. Call the setdlldirectory function to disable secure DLL lookup mode and modify the DLL lookup order.

Under Windows XP, the "secure DLL Lookup mode" is disabled by default, and if you need to enable it, create a new SafeDllSearchMode subkey in the registry and assign a value of 1. The secure DLL lookup mode starts with Windows XP SP2 and is enabled by default.

When secure DLL lookup mode is enabled, the lookup order is as follows:

A. The directory where the application resides;

B. System directory. getsystemdirectory Returns the directory, usually the system disk \Windows\System32;

C. 16-bit system directory. The item is only for forward-compatible processing and can not be considered;

d. Windows directory. getwindowsdirectory Returns the directory, usually the system disk \ windows;

E. Current directory. GetCurrentDirectory the returned directory;

F. Environment variable all directories in path.

If safe DLL lookup mode is disabled, the lookup order is as follows:

A. The directory where the application resides;

B. Current directory. GetCurrentDirectory the returned directory;

C. system directory. getsystemdirectory Returns the directory, usually the system disk \Windows\System32;

D. 16-bit system directory. The item is only for forward-compatible processing and can not be considered;

E. Windows directory. getwindowsdirectory Returns the directory, usually the system disk \ windows;

F. Environment variable all directories in path.

3. Modify the System DLL lookup order

The standard DLL lookup order used by the system can be adjusted in the following two ways:

3.1 Call the LoadLibraryEx function using the LOAD_WITH_ALTERED_SEARCH_PATH flag;

In this way, the LoadLibraryEx function is called, and the lpFileName parameter (absolute path) needs to be set. Unlike the standard lookup strategy, the DLL lookup order of the LoadLibraryEx function is called with the LOAD_WITH_ALTERED_SEARCH_PATH flag to modify the directory where the lookup application is located to lpfilename the specified directory.

3.2 Call the setdlldirectory function.

Note: Thesetdlldirectory function is supported at the beginning of Windows XP SP1.

The function setdlldirectory can support modifying the DLL search path when calling the parameter lppathname is a path . The search order after modification is as follows:

A. The directory where the application resides;

B. function setdlldirectory parameter lppathname the given directory ;

C. system directory. getsystemdirectory Returns the directory, usually the system disk \Windows\System32;

D. 16-bit system directory. The item is only for forward-compatible processing and can not be considered;

E. Windows directory. getwindowsdirectory Returns the directory, usually the system disk \ windows;

F. Environment variable all directories in path.

If the lppathname argument is an empty string , this will remove the current directory from the DLL search path.

If you call the setdlldirectory function with a null parameter, you can recover the DLL by following the system registry's safe DLL lookup mode.

Of course Win8 or Windows Server 2012 provides more customizable methods, which you can refer to on MSDN. For example:setdefaultdlldirectories, adddlldirectory,removedlldirectory.

Third, the use of Processmonitor

Processmonitor can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb896645.

The official website provides the following information:

Process Monitor is a system progress monitoring software, in general, the process monitor equivalent to Filemon+regmon, wherein the Filemon is specifically used to monitor the system of any file operation process, The Regmon is used to monitor the read and write operations of the registry. With Process Monitor, users can simultaneously monitor and record any file and registry operations in the system, and changes in registry and file reads and writes are useful for diagnosing system failures or discovering malware, viruses, or Trojans.

After the software is downloaded, the decompression can be run directly. Process Monitor By default enables recording of all operations of the "File System", "Registry", and "Process" for the true current system, similar to the Wireshark card grabber software, except that the information is crawled differently. If you are only interested in the events of a process, you can select Filter-filiter from the toolbar or menu to bring up the dialog box shown:

For example, we only care about the process named "Qwe.exe", can do the following: Select ProcessName from the first drop-down list box, fill in the process name into the input box, then click "Add" button, click "OK" (if you have already started monitoring, You can click the Apply button directly).

Other about the use of the process Monitor can refer to the Help document, the overall comparison of details, here do not repeat.

Iv. verifying that the DLL loading sequence is correct under windows

Then we can consider under Win7 to verify the DLL loading order, the idea is simple, casually write a non-existent DLL in the system, with Loadlibray dynamic loading under the view, with Process Monitor record the current process operation record.

The code is as follows:

1#include <windows.h>2#include <iostream>3 4 intMainintargcChar**argv)5 {6     usingstd::cout;7     usingStd::endl;8     9     //arbitrarily set a DLL name that does not existTenHmodule hmod = LoadLibrary ("123.dll"); One  A     if(NULL! =hmod) - FreeLibrary (hmod); -          thecout <<"LoadLibrary Test"<<Endl; -      -     return 0; -}

After compiling with MinGW, run the program at the command line. The Process monitor outputs the following information (only information about 123.dll loading is intercepted here):

You can see that the path searched here is consistent with the system standard DLL search path. My environment variable path starts at D:\software\Subversion\Apache2\bin and ends at D:\software\tortoiseGit\bin.

V. Summary

This article mainly introduces the Windows DLL lookup order, to clarify this lookup order can basically find LoadLibrary return null, the reason "cannot find the specified module". You can usually consider the following:

A. Is the DLL file to be loaded correct and complete? Is there any damage? is the full path loaded correctly?

B. Does the dependency on the DLL to be loaded exist? (Dependency Walker can see dependencies) are these dependencies in the directory that the system can find?

In addition, this article briefly describes the use of the Process Monitor Analyzer to run the file system, registry, process/thread operation, the tool is good, to be developed.

Another problem that needs special attention is the current directory, because in many cases the current directory will change due to setcurrentdirectory or openfile operations, which in some cases can cause unexpected problems loading DLLs.

Note: All rights reserved, do not use for commercial purposes, please specify the original address reproduced. I reserve all rights.

Windows under DLL Lookup order