Dynamic-Link Library Redirection

Applications can depend on a specific version of a shared DLL and start to fail if another application is installed with a newer or older version of the same DLL. There are two ways to ensure that your application uses the correct DLL: DLL redirection and side-by-side components. Developers and administrators should use DLL redirection for existing applications, because it does not require any changes to the application. If you are creating a new application or updating an application and want to isolate your application from potential problems, create a side-by-side component.

To enable DLL redirection machine-wide, you must create a new registry key. Create a new DWORD key called DevOverrideEnable at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options and set it to 1. After this, you must restart your computer to see the effects.

To use DLL redirection, create a redirection file for your application. The redirection file must be named as follows: App_name.local. For example, if the application name is Editor.exe, the redirection file should be named Editor.exe.local. You must install the .local file in the application directory. You must also install the DLLs in the application directory.

The contents of a redirection file are ignored, but its presence causes Windows to check the application directory first whenever it loads a DLL, regardless of the path specified to LoadLibrary or LoadLibraryEx. If the DLL is not found in the application directory, then these functions use their usual search order. For example, if the application c:\myapp\myapp.exe calls LoadLibrary using the following path:

c:\program files\common files\system\mydll.dll

And, if both c:\myapp\myapp.exe.local and c:\myapp\mydll.dll exist, LoadLibrary loads c:\myapp\mydll.dll. Otherwise, LoadLibrary loads c:\programВ files\commonВ files\system\mydll.dll.

Alternatively, if a directory named c:\myapp\myapp.exe.local exists and contains mydll.dll, LoadLibrary loads c:\myapp\myapp.exe.local\mydll.dll.

If the application has a manifest, then any .local files are ignored.

If you are using DLL redirection and the application does not have access to all drives and directories in the search order, LoadLibrary stops searching as soon as access is denied. (If you are not using DLL redirection, LoadLibrary skips directories that it cannot access and then continues searching.)

It is good practice to install application DLLs in the same directory that contains the application, even if you are not using DLL redirection. This ensures that installing the application does not overwrite other copies of the DLL and cause other applications to fail. Also, if you follow this good practice, other applications do not overwrite your copy of the DLL and cause your application to fail.

.extpath (Set Extension Path)

The .extpath command sets or displays the extension DLL search path.

Parameters

+
Signifies that the debugger should append new directories to the previous extension DLL search path (instead of replacing the path).

Directory
Specifies one or more directories to put in the search path. If you do not specify Directory, the current path is displayed. You can separate multiple directories with semicolons.

Environment

User mode, kernel mode

Live, crash dump

Additional Information

For more information about the extension search path and loading extension DLLs, see Loading Debugger Extension DLLs.

Remarks

The extension DLL search path is reset to its default value at the start of each debugging session.

During live kernel-mode debugging, a reboot of the target computer results in the start of a new debugging session. So any changes that you make to the extension DLL search path during kernel-mode debugging will not persist across a reboot of the target computer.

The default value of the extension DLL search path contains all the extension paths known to the debugger and all the paths in the %PATH% environment variable. For example, suppose your %PATH% environment variable has a value of C:\Windows\system32;C:\Windows . Then the default value of the DLL extension search path might look like this.

Is it possible to add a directory to DLL search path from a batch file or cmd script?

MSDN says that the function SetDllDirectory() can be used to insert a directory into the DLL Search Path. Can this function be accessed from a batch file or cmd script, perhaps using via cscript?

The aim is to have our development version of a dll found before a pre-existing older one in %WINDIR% etc. without having to write a program just for that.

Thanks in advance for your time and thoughts.

3 Answers 3

You can place the DLL in the same path as the executable, which is searched first before %WINDIR%. There’s no way to call SetDllDirectory from a batch file directly.

But, you can insert your DLL directory in the %PATH% variable, and Windows will then find the DLL there.

The aim is to have our development version of a dll found before a pre-existing older one in %WINDIR% etc. without having to write a program just for that.

If the DLL is not in the same folder as the executable Windows will search for the file in the folders specified in the system path. So all you need to do is put your folder at the start of the path.

You can do this using the following batch command:

If your path contains white space you need to use the following batch command:

But remember this path change is only made to the PATH of the current console session. If you close and reopen the console these path changes will be lost.

To clear up dispute on the dll search order (in the comments on @jussij’s answer), here’s the list, drawn from Microsoft’s doc:

If SafeDllSearchMode is enabled, the search order is as follows:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. 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.

If SafeDllSearchMode is disabled, the search order is as follows:

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. 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.

cannot use PATH/LD_LIBRARY_PATH for Windows binaries #2167

Comments

darealshinji commented May 28, 2017

Microsoft Windows: Version 10.0.15063

On command prompt I can set PATH to make binaries search for DLLs in other directories. But doing the same in bash doesn’t work. Setting LD_LIBRARY_PATH doesn’t work either. It can’t find the required DLLs unless I change the working directory.

Here’s an example:

The same in bash:

In this example I was expecting ./cl.exe to find the DLLs from the other directory and to run properly.

The text was updated successfully, but these errors were encountered:

sunjoong commented May 28, 2017 •

@darealshinji — Try like this if cl.exe is in «C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\bin\amd64» ;

$ export PATH=’/mnt/c/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64′:$PATH
djcj@DESKTOP-J6KIB79:

UPDATE: After more deep search, I think, it looks like not just a simple PATH problem; https://stackoverflow.com/questions/366928/invoking-cl-exe-msvc-compiler-in-cygwin-shell . You might need to rewrite contents of vcvars32.bat to shell script.

darealshinji commented Jun 8, 2017 •

Let me give you a better example: I have yasm.exe which requires yasm.dll and yasmstd.dll .
Let’s assume I put the DLLs into the sub-directory dlls :
in command prompt I can add this directory to PATH with set PATH=%CD%\dlls;%PATH% and then yasm.exe will work.
However, when I try the same in Bash with export PATH=»$PWD/dlls:$PATH» or export LD_LIBRARY_PATH=»$PWD/dlls» it won’t work.

Appearently I can use cmd.exe in Bash to set the PATH and then run the command:
cmd.exe /C ‘set PATH=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/Hostx64/x64;%PATH% & «C:/Program Files (x86)/M icrosoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/Hostx64/x86/cl.exe»‘

However I wish there was an easier solution.

sunjoong commented Jun 8, 2017 •

However, when I try the same in Bash with export PATH=»$PWD/dlls:$PATH» or export LD_LIBRARY_PATH=»$PWD/dlls» it won’t work.

@darealshinji — Yes, I could not find the way how to set windows PATH environment variable within WSL too. In this condition, the most simplest way is to set windows PATH environment variable on windows using control pannel-user account-user account-environment variable before launching WSL.

I coppied C:\msys64\usr\bin\bsdtar.exe to C:\Users\sunjoong\Desktop directory, and bsdtar.exe need msys-2.0.dll (and more dlls) but there were no such dlls in that directory.

I could run C:\Users\sunjoong\Desktop\bsdtar.exe becasue I had appended C:\msys64\usr\bin to windows Path environment variable.

EDIT: You know, bsdtar.exe is a Msys2 binary, in other words, it’s a windows binary that needs msys2-2.0.dll. I tested weither it could be run on WSL in the directory that does not have that dll.

UPDATE: I hit upon why @darealshinji raised this issue could be related to #1494 and/or #1363.

Is there any way to simulate LD_LIBRARY_PATH in Windows?

I have a program do so some graphics. When I run it interactively, I want it to use OpenGL from the system to provide hardware accelerated graphics. When I run it in batch, I want to be able to redirect it to use the Mesa GL library so that I can use OSMesa functionality to render to an offscreen buffer. The OSMesa functionality is enabled by doing a LoadLibrary/GetProcAddress if the batch start up option is selected.

On Linux, its fairly easy to make this work. By using a wrapper script to invoke the program, I can do something like this:

It is possible to do something this in Windows?

When I try adding a directory to the PATH variable, the program continues to go to the system opengl32.dll. The only way I can get the program to use the Mesa GL/OSMesa shared libraries is to have them reside in the same directory as my program. However, when I do that, the program will never use the system opengl32.dll.

4 Answers 4

If I’ve understood what you’re saying correctly, the wrong version of opengl32.dll is being loaded when your process starts up, i.e., load-time dynamic linking. There is probably no good way to solve your problem without changing this.

You say you can’t use conveniently use run-time dynamic linking (LoadLibrary/GetProcAddress) for opengl32.dll because the calls to it are coming from the Qt library. I presume that the Qt library is itself dynamically linked, however, so you should be able to solve your problem by using run-time linking for it. In this scenario, provided you load opengl32.dll before you load the Qt library, you should be able to explicitly choose which version of opengl32.dll you want to load.

You might want to consider using delayed loading in order to simplify the process of moving from load-time to run-time linking. In this scenario, the first call into the Qt library causes it to be loaded automatically, and you’ll just need to explicitly load opengl32.dll first.

There are a few ways you could handle this, depending on the libraries and their names/locations:

If both have the same name (opengl32.dll), then you need to add the Mesa DLL location to the search path such that it is searched before the system directory. The order directories are checked in is detailed here. As you can see, $PATH comes last, after system, so you can’t just add the directory to that. However, you can make use of the second step («The current directory») by setting the working directory to a path containing the mesa files. Generally this means starting the application using an absolute path while in the directory containing the files.

That’s still not particularly pleasant, though. If you can, you should use LoadLibrary and check for an environment variable ( OPENGL_LIBRARY_PATH ) when your app starts up. Assuming the exports from opengl32.dll and Mesa’s DLL are the same, you can do something like:

This will work perfectly fine, doing almost exactly what you want.

However, if you want to do that, you can’t import opengl32.dll , which you’re probably doing, you have to dynamically link throughout. Make sure not to link against opengl32.lib and you should be fine. Depending on how many functions you use, it may be a pain to set up, but the code can easily be scripted and only needs done once, you can also use static variables to cache the results for the lifetime of the program. It’s also possible to use different function names for different libraries, although that takes a bit more logic, so I’ll leave the details to you.