This article describes what a dynamic link library (DLL) is and the various issues that may occur when you use DLLs.

Then, this article describes some advanced issues that you should consider when you develop your own DLLs. In describing what a DLL is, this article describes dynamic linking methods, DLL dependencies, DLL entry points, exporting DLL functions, and DLL troubleshooting tools.

This article finishes with a high-level comparison of DLLs to the Microsoft .NET Framework assemblies.


For the Microsoft Windows operating systems that are listed in the "Applies to" section, much of the functionality of the operating system is provided by dynamic link libraries (DLL). Additionally, when you run a program on one of these Windows operating systems, much of the functionality of the program may be provided by DLLs. For example, some programs may contain many different modules, and each module of the program is contained and distributed in DLLs.

The use of DLLs helps promote modularization of code, code reuse, efficient memory usage, and reduced disk space. Therefore, the operating system and the programs load faster, run faster, and take less disk space on the computer.

When a program uses a DLL, an issue that is called dependency may cause the program not to run. When a program uses a DLL, a dependency is created. If another program overwrites and breaks this dependency, the original program may not successfully run.

With the introduction of the Microsoft .NET Framework, most dependency problems have been eliminated by using assemblies.

More Information

What is a DLL?


By using a DLL, a program can be modularized into separate components. For example, an accounting program may be sold by module. Each module can be loaded into the main program at run time if that module is installed. Because the modules are separate, the load time of the program is faster, and a module is only loaded when that functionality is requested.


  • ActiveX Controls (.ocx) files
  • Control Panel (.cpl) files
  • Device driver (.drv) files

DLL advantages

The following list describes some of the advantages that are provided when a program uses a DLL:
  • Uses fewer resources
    When multiple programs use the same library of functions, a DLL can reduce the duplication of code that is loaded on the disk and in physical memory. This can greatly influence the performance of not just the program that is running in the foreground, but also other programs that are running on the Windows operating system.
  • Promotes modular architecture
    A DLL helps promote developing modular programs. This helps you develop large programs that require multiple language versions or a program that requires modular architecture. An example of a modular program is an accounting program that has many modules that can be dynamically loaded at run time.
  • Eases deployment and installation
    When a function within a DLL needs an update or a fix, the deployment and installation of the DLL does not require the program to be relinked with the DLL. Additionally, if multiple programs use the same DLL, the multiple programs will all benefit from the update or the fix. This issue may more frequently occur when you use a third-party DLL that is regularly updated or fixed.

DLL dependencies

  • A dependent DLL is upgraded to a new version.
  • A dependent DLL is fixed.
  • A dependent DLL is overwritten with an earlier version.
  • A dependent DLL is removed from the computer.
These actions are generally known as DLL conflicts. If backward compatibility is not enforced, the program may not successfully run.

The following list describes the changes that have been introduced in Microsoft Windows 2000 and in later Windows operating systems to help minimize dependency issues:
  • Windows File Protection
    In Windows File Protection, the operating system prevents system DLLs from being updated or deleted by an unauthorized agent. Therefore, when a program installation tries to remove or update a DLL that is defined as a system DLL, Windows File Protection will look for a valid digital signature.
  • Private DLLs

DLL troubleshooting tools

Several tools are available to help you troubleshoot DLL problems. The following tools are some of these tools.

Dependency Walker

The Dependency Walker tool can recursively scan for all dependent DLLs that are used by a program. When you open a program in Dependency Walker, Dependency Walker performs the following checks:
  • Dependency Walker checks for missing DLLs.
  • Dependency Walker checks for program files or DLLs that are not valid.
  • Dependency Walker checks that import functions and export functions match.
  • Dependency Walker checks for circular dependency errors.
  • Dependency Walker checks for modules that are not valid because the modules are for a different operating system.
By using Dependency Walker, you can document all the DLLs that a program uses. This may help prevent and correct DLL problems that may occur in the future. Dependency Walker is located in the following directory when you install Microsoft Visual Studio 6.0:
drive\Program Files\Microsoft Visual Studio\Common\Tools

DLL Universal Problem Solver

The DLL Universal Problem Solver (DUPS) tool is used to audit, compare, document, and display DLL information. The following list describes the utilities that make up the DUPS tool:
  • Dlister.exe
    This utility enumerates all the DLLs on the computer and logs the information to a text file or to a database file.
  • Dcomp.exe
    This utility compares the DLLs that are listed in two text files and produces a third text file that contains the differences.
  • Dtxt2DB.exe
    This utility loads the text files that are created by using the Dlister.exe utility and the Dcomp.exe utility into the dllHell database.
  • DlgDtxt2DB.exe
    This utility provides a graphical user interface (GUI) version of the Dtxt2DB.exe utility.
For more information about the DUPS tool, click the following article number to view the article in the Microsoft Knowledge Base:
247957 Using DUPS.exe to resolve DLL compatibility problems

DLL Help database

The DLL Help database helps you locate specific versions of DLLs that are installed by Microsoft software products. For more information about the DLL Help database, visit the following Microsoft Web site:

DLL development

This section describes the issues and the requirements that you should consider when you develop your own DLLs.

Types of DLLs

When you load a DLL in an application, two methods of linking let you call the exported DLL functions. The two methods of linking are load-time dynamic linking and run-time dynamic linking.
Load-time dynamic linking
In load-time dynamic linking, an application makes explicit calls to exported DLL functions like local functions. To use load-time dynamic linking, provide a header (.h) file and an import library (.lib) file when you compile and link the application. When you do this, the linker will provide the system with the information that is required to load the DLL and resolve the exported DLL function locations at load time.
Run-time dynamic linking
In run-time dynamic linking, an application calls either the LoadLibrary function or the LoadLibraryEx function to load the DLL at run time. After the DLL is successfully loaded, you use the GetProcAddress function to obtain the address of the exported DLL function that you want to call. When you use run-time dynamic linking, you do not need an import library file.

The following list describes the application criteria for when to use load-time dynamic linking and when to use run-time dynamic linking:
  • Startup performance
    If the initial startup performance of the application is important, you should use run-time dynamic linking.
  • Ease of use
    In load-time dynamic linking, the exported DLL functions are like local functions. This makes it easy for you to call these functions.
  • Application logic
    In run-time dynamic linking, an application can branch to load different modules as required. This is important when you develop multiple-language versions.

The DLL entry point

HANDLE hModule,// Handle to DLL module
DWORD ul_reason_for_call,// Reason for calling function
LPVOID lpReserved ) // Reserved
switch ( ul_reason_for_call )
// A process is loading the DLL.
// A process is creating a new thread.
// A thread exits normally.
// A process unloads the DLL.
return TRUE;



Exporting DLL functions



// SampleDLL.def


Sample DLL and application

MFC AppWizard (dll) project type.

Win32 Dynamic-Link Library project type.
// SampleDLL.cpp

#include "stdafx.h"
#include "sampleDLL.h"

DWORD ul_reason_for_call,
LPVOID lpReserved
return TRUE;

void HelloWorld()
// File: SampleDLL.h
#ifndef INDLL_H
#define INDLL_H

extern __declspec(dllexport) void HelloWorld() ;
extern __declspec(dllimport) void HelloWorld() ;

// SampleApp.cpp 

#include "stdafx.h"
#include "sampleDLL.h"

int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
return 0;

DLLPROC HelloWorld;

hinstDLL = LoadLibrary("sampleDLL.dll");
if (hinstDLL != NULL)
if (HelloWorld != NULL)

fFreeDLL = FreeLibrary(hinstDLL);
  1. The application folder
  2. The current folder
  3. The Windows system folder

    Note The GetSystemDirectory function returns the path of the Windows system folder.
  4. The Windows folder

    Note The GetWindowsDirectory function returns the path of the Windows folder.

The .NET Framework assembly

With the introduction of Microsoft .NET and the .NET Framework, most of the problems that are associated with DLLs have been eliminated by using assemblies. An assembly is a logical unit of functionality that runs under the control of the .NET common language runtime (CLR). An assembly physically exists as a .dll file or as an .exe file. However, internally an assembly is very different from a Microsoft Win32 DLL.

An assembly file contains an assembly manifest, type metadata, Microsoft intermediate language (MSIL) code, and other resources. The assembly manifest contains the assembly metadata that provides all the information that is required for an assembly to be self-describing. The following information is included in the assembly manifest:
  • Assembly name
  • Version information
  • Culture information
  • Strong name information
  • The assembly list of files
  • Type reference information
  • Referenced and dependent assembly information
The MSIL code that is contained in the assembly cannot be directly executed. Instead, MSIL code execution is managed through the CLR. By default, when you create an assembly, the assembly is private to the application. To create a shared assembly requires that you assign a strong name to the assembly and then publish the assembly in the global assembly cache.

The following list describes some of the features of assemblies compared to the features of Win32 DLLs:
  • Self-describing
    When you create an assembly, all the information that is required for the CLR to run the assembly is contained in the assembly manifest. The assembly manifest contains a list of the dependent assemblies. Therefore, the CLR can maintain a consistent set of assemblies that are used in the application. In Win32 DLLs, you cannot maintain consistency between a set of DLLs that are used in an application when you use shared DLLs.
  • Versioning
    In an assembly manifest, version information is recorded and enforced by the CLR. Additionally, version policies let you enforce version-specific usage. In Win32 DLLs, versioning cannot be enforced by the operating system. Instead, you must make sure that DLLs are backward compatible.
  • Side-by-side deployment
    Assemblies support side-by-side deployment. One application can use one version of an assembly, and another application can use a different version of an assembly. Starting in Windows 2000, side-by-side deployment is supported by locating DLLs in the application folder. Additionally, Windows File Protection prevents system DLLs from being overwritten or replaced by an unauthorized agent.
  • Self-containment and isolation
    An application that is developed by using an assembly can be self-contained and isolated from other applications that are running on the computer. This feature helps you create zero-impact installations.
  • Execution
    An assembly is run under the security permissions that are supplied in the assembly manifest and that are controlled by the CLR.
  • Language independent
    An assembly can be developed by using any one of the supported .NET languages. For example, you can develop an assembly in Microsoft Visual C#, and then use the assembly in a Microsoft Visual Basic .NET project.


For more information about DLLs and the .NET Framework assemblies, visit the following Microsoft Web sites:
DLL conflicts

Implementing side-by-side component sharing in applications

How to build and service isolated applications and side-by-side assemblies for Windows XP

Simplifying deployment and solving DLL conflicts with the .NET Framework

The .NET Framework developer's guide: Assemblies

Run-time dynamic linking

Thread local storage

Article ID: 815065 - Last Review: 15 Feb 2017 - Revision: 2