What Are DLL Imports and Exports?
DLL imports and exports describe how Windows binaries connect to each other. Imports are the external libraries and functions a DLL expects to use. Exports are the functions or symbols a DLL makes available to other software.
Together, they explain much of the relationship between an application and its libraries.
This guide explains DLL imports and exports, how the import and export tables work, what names and ordinals mean, and how these structures help with troubleshooting and static DLL analysis.
Imports tell you what a DLL needs from other modules. Exports tell you what the DLL offers to other modules. Both can be inspected without running the file.
On this page
Imports vs Exports at a Glance
| Feature | Imports | Exports |
|---|---|---|
| Meaning | Functions and DLLs the binary depends on | Functions or symbols the binary exposes |
| Main PE structure | Import directory | Export directory |
| Typical use | Dependency analysis | Public API analysis |
| Can use names? | Yes | Yes |
| Can use ordinals? | Yes | Yes |
What Is a DLL Import?
An import is a function or symbol that the current binary expects another module to provide.
For example, a DLL may need Windows APIs for file access, memory allocation, or user-interface work.
This tells you that the DLL expects those functions to be available when loaded.
What Is a DLL Export?
An export is a function, variable, or symbol a DLL makes available to callers.
For example:
Another program can call those exported functions if it knows the names or ordinals and uses the correct calling convention and parameters.
A Simple Mental Model
Think of a DLL as a small service counter.
The DLL asks other libraries for functions it needs.
Other software asks this DLL for functions it exposes.
Where Are Imports Stored?
Windows PE files can contain an Import Directory.
This directory points to structures describing imported DLL names and imported functions.
At a high level, the import information answers two questions:
- Which DLLs does this binary depend on?
- Which functions does it need from each DLL?
For a more focused guide, read How to View DLL Imports and Dependencies.
Where Are Exports Stored?
Exports are described by the PE Export Directory.
The export table can contain:
- Exported function addresses
- Exported names
- Ordinals
- Forwarded exports
This data lets other software locate functions that the DLL intentionally makes public.
What Is the Import Address Table?
The Import Address Table, often shortened to IAT, is an important part of Windows DLL loading.
Before the binary runs normally, Windows resolves imported functions and places their addresses into slots the program can use.
The program can then call through those resolved addresses.
What Is the Export Address Table?
The Export Address Table is part of the export-directory structure.
It maps export ordinals to RVAs that identify where exported code or forwarded targets are located.
Names, ordinals, and function addresses work together to let a caller resolve an export.
Named Exports
A named export is the easiest kind to understand.
Example:
A caller can look up the function by that name.
This makes troubleshooting easier because an error message can tell you exactly which procedure is missing.
Ordinal Exports
An export can also be identified by an ordinal number.
Ordinals are compact and can be stable if the developer controls them carefully.
But they are harder for humans to understand because the number alone does not describe the function’s purpose.
Can a Function Be Exported by Both Name and Ordinal?
Yes.
A DLL can expose a function with a readable name while also assigning it an ordinal.
That lets callers resolve it either way, depending on how the API is designed.
What Are Forwarded Exports?
A forwarded export does not point directly to code inside the current DLL.
Instead, it points to an export in another DLL.
Conceptually:
This lets one DLL expose an API that is actually implemented elsewhere.
Static Imports vs Dynamic Loading
The normal import table does not always show every DLL a program can load.
Software can load libraries dynamically at runtime using APIs such as LoadLibrary and resolve functions with GetProcAddress.
This is why static imports are useful but not a complete list of every possible dependency.
Delay-Loaded Imports
Some Windows binaries use delay loading.
Instead of resolving a DLL immediately during normal startup, the application can defer loading until a function is actually needed.
Delay-load information is stored separately from the ordinary import directory.
A dependency viewer that understands PE delay imports can show these too.
Why Imports Matter for Troubleshooting
Imports are useful when Windows says a DLL cannot be loaded.
Imagine:
If vendor_runtime.dll is missing, Windows may fail while loading plugin.dll.
The top-level DLL is present, but its dependency chain is incomplete.
Why Exports Matter for Troubleshooting
Exports are especially important when an application reports:
That means the caller expected a function the loaded DLL does not expose under the expected name or ordinal.
For this error, read “Entry Point Not Found” DLL Error: Causes and Fixes.
Imports Do Not Tell You What the DLL Definitely Does
An imported API is only evidence that the binary may use that function.
It does not tell you:
- When the function is called
- How often it is called
- What parameters are used
- Whether a particular code path is reached
Imports are useful context, not a full behavior trace.
Exports Do Not Reveal Every Internal Function
The export table only shows the public interface.
A DLL can contain hundreds or thousands of internal functions that are not exported.
Those functions may still be used internally by the DLL but remain invisible in the export table.
Native DLL Exports vs .NET Methods
Native PE exports and managed .NET public methods are different concepts.
A normal .NET class library may expose public classes and methods through CLR metadata without listing those methods in the traditional native PE export table.
| Type | Public interface usually found in |
|---|---|
| Native DLL | PE export table |
| .NET DLL | CLR metadata, types, methods, assemblies |
See Native DLL vs .NET DLL: What Is the Difference?.
Can a DLL Have No Exports?
Yes.
Some DLLs exist primarily for internal loading, resources, managed assemblies, COM behavior, or other mechanisms.
A DLL with no traditional named exports is not automatically broken.
Can a DLL Have No Imports?
Yes.
A very small or unusual DLL can have few or no normal static imports.
It may resolve functions dynamically, contain self-contained code, or use a different loading model.
So an empty import table is not automatically suspicious or invalid.
C++ Export Names Can Look Strange
C++ compilers may decorate function names to encode type information and calling conventions.
You may see exports like:
This is normal for many C++ binaries.
Developers often use C-style exports when they want a simpler stable external API.
Imports and Exports During DLL Loading
A simplified native load sequence looks like this:
↓
Validate PE image
↓
Map sections
↓
Resolve imports
↓
Apply relocations if needed
↓
Run initialization
↓
Caller can use exported API
If imports cannot be resolved, loading can fail before the application’s normal use of exports begins.
How to Inspect DLL Imports and Exports Safely
You do not need to execute a DLL to view its normal import and export tables.
A static PE viewer can read both directly from the file.
Useful information to record includes:
- Imported DLL names
- Imported function names
- Imported ordinals
- Exported function names
- Export ordinals
- Forwarded exports
A Practical Example
Imagine a DLL named imageengine.dll.
From static analysis alone, you can reasonably say that the DLL depends on Windows file and graphics APIs and exposes an image-processing style API.
You still cannot determine every runtime behavior from these tables alone.
Frequently Asked Questions
What are DLL imports?
Imports are external functions and libraries a DLL expects to use.
What are DLL exports?
Exports are functions or symbols a DLL makes available to other software.
Can imports use ordinals?
Yes. Imports can be resolved by function name or ordinal.
Can exports use ordinals?
Yes. A DLL can export by name, ordinal, or both.
Do imports show every DLL loaded at runtime?
No. Dynamically loaded libraries may not appear in the normal import table.
Can I view imports and exports without running the DLL?
Yes. A static PE viewer can read both tables directly from the file.
The Key Difference Between DLL Imports and Exports
Imports describe dependencies. Exports describe the public interface.
If you are troubleshooting a missing dependency, start with imports. If you are troubleshooting an “Entry Point Not Found” error, start with exports.
Together, these two PE structures are among the most useful parts of a DLL for static analysis.
View DLL imports and exports online
Inspect dependencies, exported functions, architecture, PE sections, SHA-256, and basic .NET indicators without executing the DLL.
View DLL Imports and Exports
