Training
Learning path
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
It's common for multiple versions of the same dynamic-link library (DLL) to exist in different file system locations within an operating system (OS). You can control the specific location from which any given DLL is loaded by specifying a full path. But if you don't use that method, then the system searches for the DLL at load time as described in this topic. The DLL loader is the part of the operating system (OS) that loads DLLs and/or resolves references to DLLs.
Tip
For definitions of packaged and unpackaged apps, see Advantages and disadvantages of packaging your app.
Here are some special search factors that are discussed in this topic—you can consider them to be part of the DLL search order. Later sections in this topic list these factors in the appropriate search order for certain app types, together with other search locations. This section is just to introduce the concepts, and to give them names that we'll use to refer to them later in the topic.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
.If a DLL has dependencies, then the system searches for the dependent DLLs as if they were loaded by using only their module names. That's true even if the first DLL was loaded by specifying a full path.
When a packaged app loads a packaged module (specifically, a library module—a .dll
file) by calling the LoadPackagedLibrary function, the DLL must be in the package dependency graph of the process. For more information, see LoadPackagedLibrary. When a packaged app loads a module by other means, and doesn't specify a full path, the system searches for the DLL and its dependencies at load time as described in this section.
When the system searches for a module or its dependencies, it always uses the search order for packaged apps; even if a dependency is not packaged app code.
The system searches in this order:
<PackageDependency>
in the <Dependencies>
section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.%SystemRoot%\system32
).If a DLL has dependencies, then the system searches for the dependent DLLs as if they were loaded with just their module names (even if the first DLL was loaded by specifying a full path).
If a module changes the standard search order by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH, then the search order is the same as the standard search order except that in step 7 the system searches the folder that the specified module was loaded from (the top-loading module's folder) instead of the executable's folder.
When an unpackaged app loads a module and doesn't specify a full path, the system searches for the DLL at load time as described in this section.
Important
If an attacker gains control of one of the directories that's searched, then it can place a malicious copy of the DLL in that folder. For ways to help prevent such attacks, see Dynamic-link library security.
The standard DLL search order used by the system depends on whether or not safe DLL search mode is enabled.
Safe DLL search mode (which is enabled by default) moves the user's current folder later in the search order. To disable safe DLL search mode, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode
registry value, and set it to 0. Calling the SetDllDirectory function effectively disables safe DLL search mode (while the specified folder is in the search path), and changes the search order as described in this topic.
If safe DLL search mode is enabled, then the search order is as follows:
<PackageDependency>
in the <Dependencies>
section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.PATH
environment variable. This doesn't include the per-application path specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.If safe DLL search mode is disabled, then the search order is the same except that the current folder moves from position 11 to position 8 in the sequence (immediately after step 7. The folder from which the application loaded).
To change the standard search order used by the system, you can call the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH. You can also change the standard search order by calling the SetDllDirectory function.
Note
The standard search order of the process will also be affected by calling the SetDllDirectory function in the parent process before the start of the current process.
If you specify an alternate search strategy, then its behavior continues until all associated executable modules have been located. After the system starts processing DLL initialization routines, the system reverts to the standard search strategy.
The LoadLibraryEx function supports an alternate search order if the call specifies LOAD_WITH_ALTERED_SEARCH_PATH, and the lpFileName parameter specifies an absolute path.
That's the only way in which they differ.
If safe DLL search mode is enabled, then the alternate search order is as follows:
Steps 1-6 are the same as the standard search order.
PATH
environment variable. This doesn't include the per-application path specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.If safe DLL search mode is disabled, then the alternate search order is the same except that the current folder moves from position 11 to position 8 in the sequence (immediately after step 7. The folder specified by lpFileName).
The SetDllDirectory function supports an alternate search order if the lpPathName parameter specifies a path. The alternate search order is as follows:
Steps 1-6 are the same as the standard search order.
PATH
environment variable.If the lpPathName parameter is an empty string, then the call removes the current folder from the search order.
SetDllDirectory effectively disables safe DLL search mode while the specified folder is in the search path. To restore safe DLL search mode based on the SafeDllSearchMode registry value, and restore the current folder to the search order, call SetDllDirectory with lpPathName as NULL.
You can specify a search order by using one or more LOAD_LIBRARY_SEARCH flags with the LoadLibraryEx function. You can also use LOAD_LIBRARY_SEARCH flags with the SetDefaultDllDirectories function to establish a DLL search order for a process. You can specify additional directories for the process DLL search order by using the AddDllDirectory or SetDllDirectory functions.
The directories that are searched depend on the flags specified with SetDefaultDllDirectories or LoadLibraryEx. If you use more than one flag, then the corresponding directories are searched in this order:
If you call LoadLibraryEx with no LOAD_LIBRARY_SEARCH flags, or you establish a DLL search order for the process, then the system searches for DLLs using either the standard search order or the alternate search order.
Training
Learning path
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
Documentation
Dynamic-link library redirection - Win32 apps
If your application depends on a specific version of a shared DLL, and another application is installed with a newer or older version of that DLL, then that can cause a problem; it can cause your app to start to fail. Another use case for DLL redirection is to load a private build of a DLL.
SetDllDirectoryA function (winbase.h) - Win32 apps
Adds a directory to the search path used to locate DLLs for the application. (ANSI)
Dynamic-Link Library Security - Win32 apps
When an application dynamically loads a dynamic-link library without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories in a particular order, as described in Dynamic-Link Library Search Order. If an attacker gains control of one of the directories on the DLL search path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading attack or a binary planting attack.