Windows Confidential: Getting Out of DLL Hell

Article
09/08/2016

Windows ConfidentialGetting Out of DLL Hell

Raymond Chen

DLL HELL. A problem so insidious it has its own pejorative nickname. You install one program and suddenly some seemingly unrelated program stops working. This is because, unknown to you, the two programs are connected via a shared DLL file. The two programs might have different ideas of what version of the MSVCRT.DLL file should be in the system directory. Or the first program may upgrade an ActiveX® control that the second program uses-an upgrade that the second program is not entirely compatible with.

If both programs are essential to your company's day-to-day operations, it doesn't really matter which program is to blame. The important thing is that you need to get them up and running. There isn't much difference between "We're losing money" and "We're losing money because of Bob." Either way, your company is losing money and it's your job to fix the problem right away.

It used to be that you had to choose which program won and which program lost. Starting with Windows® 2000, bandages were made available to help you patch over these conflicts. These bandages, however, are only temporary solutions, allowing you to get your system back on its feet while you investigate a more permanent resolution to the conflict.

Windows 2000 implemented a rudimentary version of what now goes by the fancy name of Dynamic-Link Library Redirection. To enable DLL redirection, create a file with the same name as the program whose DLLs you wish to redirect, but with .local appended to the name. For example, to apply redirection to C:\Program Files\Litware Inc\Invoice.exe, create the file C:\Program Files\Litware Inc\Invoice .exe.local. The contents of the file aren't important; what's important is that the file exists.

Once you've enabled redirection for a program, all attempts by that program to load a DLL will first look in the directory that contains the program before the usual search locations. Therefore, in the case of the conflicting MSVCRT.DLL file, you can enable redirection in each program and put a private copy of MSVCRT.DLL into each program's installation directory. Each program then receives its own version of MSVCRT.DLL-the version of the DLL with which the program was tested.

The magic of this technique is that it works even if the program uses a full path to load the DLL. For example, suppose the program tries to load C:\Program Files\Common Files\Proseware Inc\taxplugin.dll. After upgrading to Proseware 2.0, you discover that its tax plug-in is incompatible with your invoice program. What you can do is copy an old version of the tax plug-in to C:\Program Files\Litware Inc\taxplugin.dll. Even though the program uses a full path to load the tax plug-in, DLL redirection will still look in the current directory and use the local override instead of the one in the Proseware Inc directory.

In Windows XP and Windows Vista™, the rules for DLL redirection are a little different, but the general principle remains the same. In addition to creating a .local file, you can also create a .local directory. In that case, the .local directory is searched rather than the program's install directory. This allows you to apply redirection to multiple programs in the same directory without conflict.

Note that you cannot apply redirection to programs that contain an application manifest, and so-called known DLLs are also exempt from redirection. (For further details, see "Dynamic-Link Library Redirection".)

DLL redirection won't entirely get you out of DLL Hell, but at least it gives you some first-aid techniques for tending the wound while you sort out the problem.

Figure 1

Raymond Chen writes about both Windows history and Win32 programming on his Web site, The Old New Thing, as well as in his new book also titled The Old New Thing (Addison-Wesley, 2007). He does not, however, have a pet cat named The Old New Thing.

Additional resources