DLL Hell

In computing, DLL Hell is a term for the complications that arise when working with dynamic link libraries (DLLs) used with Microsoft Windows operating systems,[1] particularly legacy 16-bit editions which all run in a single memory space.

DLL Hell can manifest itself in many different ways; typically when applications do not launch or work correctly.

DLL Hell is the Windows ecosystem specific form of the general concept dependency hell.

Problems

There are a number of problems commonly encountered with DLLs – especially after numerous applications have been installed and uninstalled on a system. The difficulties include conflicts between DLL versions, difficulty in obtaining required DLLs, and having many unnecessary DLL copies.

Incompatible versions

A particular version of a library can be compatible with some (and incompatible with other) programs that use it. Windows has been particularly vulnerable to this because of its emphasis on dynamic linking of C++ libraries and Object Linking and Embedding (OLE) objects. C++ classes export many methods, and a single change to the class (such as a new virtual method) can make it incompatible with programs that were built against an earlier version. Object Linking and Embedding has some very strict rules to prevent this—interfaces are required to be stable and memory managers are not shared. But this is not enough, for the semantics of a class can change. A "bug fix" for one application may be the removal of a "feature" from another. Before Windows 2000, Windows was vulnerable to this because the COM class table was shared across all users and processes. Only one COM object in one DLL/EXE could be declared as having a specific global COM Class ID on a system. If any program needed to create an instance of that class, it got whatever was the current centrally registered implementation. As a result, an installation of a program that installs a new version of a common object may inadvertently break other programs that were previously installed.

DLL stomping

A common and troublesome problem occurs when a newly installed program overwrites a working system DLL with an earlier, incompatible version. An early example of this were the ctl3d.dll and ctl3dv2.dll libraries for Windows 3.1: Microsoft-created libraries that third party publishers would distribute with their software, but each distributing the version they developed with rather than the most recent version. [2] DLL stomping occurs because:

Incorrect COM registration

In COM and other parts of Windows, prior to the introduction of side-by-side Registry-free assemblies,[5] the Registry was used for determining which underlying DLL to use. If a different version of a module was registered, this DLL would be loaded instead of the expected one. This scenario could be caused by conflicting installations that register different versions of the same libraries, in which case the last installation would prevail.

Shared in-memory modules

16-bit versions of Windows (and Windows on Windows) load only one instance of any given DLL; all applications reference the same in-memory copy, until no applications are using it and it is unloaded from memory. (For 32-bit and 64-bit versions of Windows, inter-process sharing occurs only where different executables load a module from exactly the same directory; the code but not the stack is shared between processes through a process called "memory mapping".) Thus, even when the desired DLL is located in a directory where it can be expected to be found, such as in the system directory or the application directory, neither of these instances will be used if another application has started with an incompatible version from a third directory. This issue can manifest itself as a 16-bit application error that occurs only when applications are started in a specific order.

Lack of serviceability

In direct conflict with the DLL stomping problem: If updates to a DLL do not affect all applications which use it, then it becomes much harder to "service" the DLL — that is, to eliminate problems which exist in the current versions of the DLL. (Security fixes are a particularly compelling and painful case.) Instead of fixing just the latest version of the DLL, the implementor must ideally make their fixes, and test them for compatibility, on every released version of the DLL.

Causes

DLL incompatibility has been caused by:

DLL Hell was a very common phenomenon on pre-Windows NT versions of Microsoft operating systems, the primary cause being that the 16-bit operating systems did not restrict processes to their own memory space, thereby not allowing them to load their own version of a shared module that they were compatible with. Application installers were expected to be good citizens and verify DLL version information before overwriting the existing system DLLs. Standard tools to simplify application deployment (which always involves shipping the dependent operating system DLLs) were provided by Microsoft and other 3rd party tools vendors. Microsoft even required application vendors to use a standard installer and have their installation program certified to work correctly, before being granted use of the Microsoft logo. The good citizen installer approach did not mitigate the problem, as the rise in popularity of the Internet provided more opportunities to obtain non-conforming applications.

Use by malware

The ambiguity with which DLLs that are not fully qualified can be loaded in the Windows operating system has been exploited by malware in recent years, opening a new class of vulnerability that affects applications from many different software vendors, as well as Windows itself.[6]

Solutions

Various forms of DLL hell have been solved or mitigated over the years.

Static linking

One of the simplest solutions to DLL Hell in an application is to statically link against all the libraries.[7] This is common in C/C++ applications, where, instead of having to worry about which version of MFC42.DLL is installed, the application is compiled to be statically linked against the same libraries. This eliminates the DLLs entirely, and is viable for standalone applications which only use libraries which offer a static option, like Microsoft Foundation Class Library does. The main purpose of DLLs (runtime library sharing between programs to reduce memory overhead) is sacrificed, however, creating more software bloat and complicating the deployment of security fixes or newer versions of dependent software.

Windows File Protection

The DLL overwriting problem (referred to as DLL Stomping inside Microsoft) was somewhat reduced with Windows File Protection (WFP)[8] which was introduced in Windows 2000.[9] This prevents unauthorized applications from overwriting system DLLs, unless they use the specific Windows APIs that permit this. There may still be a risk that updates from Microsoft are incompatible with existing applications, but this risk is typically reduced in current versions of Windows through the use of side-by-side assemblies.

Third-party applications cannot stomp on OS files unless they bundle legitimate Windows updates with their installer, or if they disable the Windows File Protection service during installation, and on Windows Vista or later also take ownership of system files and grant themselves access. The SFC utility could revert these changes at any time.

Running conflicting DLLs simultaneously

The solutions here consist of having different copies of the same DLLs for each application, both on-disk and in memory.

An easy manual solution to conflicts was placing the different versions of the problem DLL into the applications' folders, rather than a common system-wide folder. This works in general as long as the application is 32-bit or 64-bit, and that the DLL does not use shared memory. In the case of 16-bit applications, the two applications cannot be executed simultaneously on a 16-bit platform, or in the same 16-bit virtual machine under a 32-bit operating system. OLE prevented this before Windows 98 SE/2000, because earlier versions of Windows had a single Registry of COM objects for all applications.

Windows 98 SE/2000 introduced a solution called Side-by-side assembly,[10] which loads separate copies of DLLs for each application that requires them (and thus allows applications that require conflicting DLLs to run simultaneously). This approach eliminates conflicts by allowing applications to load unique versions of a module into their address space, while preserving the primary benefit of sharing DLLs between applications (i.e. reducing memory use) by using memory mapping techniques to share common code between different processes that do still use the same module. Yet DLLs using shared data between multiple processes cannot take this approach.[11] One negative side effect is that orphaned instances of DLLs may not be updated during automated processes.

Portable applications

Depending on the application architecture and runtime environment, portable applications may be an effective way to reduce some DLL problems, since every program bundles its own private copies of any DLLs it requires.[9] The mechanism relies on applications not fully qualifying the paths to dependent DLLs when loading them, and the operating system searching the executable directory before any shared location.[12] However this technique can also be exploited by malware,[13] and the increased flexibility may also come at the expense of security if the private DLLs are not kept up to date with security patches in the same way that the shared ones are.

Application virtualization can also allow applications to run in a "bubble", which avoids installing DLL files directly into file system of the operating system.

Other countermeasures

There are other countermeasures to avoid DLL Hell, some of which may have to be used simultaneously: Some other features that help to mitigate the problem are

See also

References

  1. ↑ "Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework". Microsoft. October 2000.
  2. ↑ "A summary of CTL3D.DLL articles in Microsoft Support Knowledge Base". Microsoft.
  3. ↑ Redistribution of the shared C runtime component in Visual C++ 2005 and in Visual C++ .NET
  4. ↑ KB 830490: HP Color LaserJet printer prints only in grayscale or in black-and-white on your Windows 2000 SP4-based computer
  5. ↑ "Registration-Free Activation of COM Components: A Walkthrough". Leslie Muller/Steve White. July 2005.
  6. ↑ "Secure Loading of Libraries to Prevent DLL Preloading Attacks". Microsoft. 2011-06-11. Retrieved 2011-07-19.
  7. ↑ Pfeiffer, Tim (1998-06-01). "Windows DLLs: Threat or Menace?". Dr. Dobbs Journal. Archived from the original on 2006-06-20. Retrieved 2010-07-07.
  8. ↑ Windows File Protection and Windows
  9. 1 2 Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2010-07-07.
  10. ↑ "Implementing Side-by-Side Component Sharing in Applications (Expanded)". Microsoft. Archived from the original on 10 December 2006. Retrieved 3 January 2013.
  11. ↑ "How do I share data in my DLL with an application or with other DLLs?". Microsoft. Retrieved 2008-11-11.
  12. ↑ Desitter, Arnaud (2007-06-15). "Using static and shared libraries across platforms; Row 9: Library Path". ArnaudRecipes. Archived from the original on 2008-06-01. Retrieved 2010-07-07.
  13. ↑ "Secure loading of libraries to prevent DLL preloading attacks". Microsoft. Retrieved 16 Feb 2013.
  14. ↑ Side-by-side Assemblies (Windows)

External links

This article is issued from Wikipedia - version of the Tuesday, December 22, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.