BIOS Terms Stable

What is the DXE Dispatcher?

The DXE Dispatcher loads and runs drivers based on DEPEX and protocol dependencies. Understanding the dispatch loop helps debug drivers that do not run despite a clean build.

June 10, 2026 Updated June 11, 2026 6 min read

Đọc bằng English Tiếng Việt 日本語

A DXE driver does not run simply because its .c file was compiled. Inside the firmware image, drivers live in firmware volumes. The DXE Dispatcher scans DXE drivers, evaluates their dependency expression (DEPEX), and only then calls the entry point — and it does not run in file order, but in dependency order.

How the dispatch loop works

01 Scan FV

Find drivers in firmware volumes

Read FFS files, find the PE32 section and DEPEX section of each driver.

02 Eval DEPEX

Check dependency

Have the protocols in DEPEX been installed? If not — hold the driver and retry in the next dispatch round.

03 Dispatch

Call entry point

Driver runs, locates and installs protocols, publishes abstractions.

04 Loop

Repeat

Newly installed protocols may unlock other waiting drivers. Dispatcher begins a new round.

The dispatcher runs multiple rounds. Each round it tries to dispatch all drivers not yet run. If a driver installs a new protocol, the next round may unlock other drivers waiting on that dependency. The loop ends when no more drivers can be dispatched.

Example dispatch loop:

Round 1:
  Driver A: DEPEX satisfied → dispatch → installs Protocol X
  Driver B: DEPEX needs Protocol X → not satisfied → skip
  Driver C: DEPEX satisfied → dispatch → installs Protocol Y

Round 2:
  Driver B: Protocol X now exists → DEPEX satisfied → dispatch
  Driver D: DEPEX needs Protocol Z → not satisfied → stays held
            If no driver installs Protocol Z during the loop,
            Driver D will never be dispatched in this boot.

What is DEPEX and how is it written?

DEPEX (Dependency Expression) is the condition that allows the dispatcher to run a driver. Declared in the [Depex] section of the .inf file:

# Driver only runs when both protocols are already installed
[Depex]
  gEfiPciIoProtocolGuid AND gEfiDevicePathProtocolGuid

# Driver runs when either protocol exists
[Depex]
  gEfiBlockIoProtocolGuid OR gEfiBlockIo2ProtocolGuid

# Driver is always dispatched immediately — no dependencies
[Depex]
  TRUE

During the build, EDK II compiles [Depex] into a binary DEPEX section inside the firmware file. The DXE Dispatcher reads that section at runtime — it does not read the INF file.

Three common reasons a driver does not run

Item	Value	Note
In DSC but missing from FDF	Builds successfully but is not in the FV	The ROM image does not contain the driver — the dispatcher never sees it.
DEPEX not yet satisfied	Dispatcher is waiting for a protocol	Entry point has not been called. A protocol dependency may not have been installed by any driver.
Wrong DEBUG level	Driver ran but logs are invisible	Do not conclude too early based only on logs. Check the map file or add an unambiguous debug print.
Wrong MODULE_TYPE or file type	Driver is not handled as expected	DXE_DRIVER, DXE_RUNTIME_DRIVER, and UEFI_DRIVER have different entry points and lifecycles. If the module type, INF, or packaging is wrong, the dispatcher may not behave as intended.

Tracing the dependency chain

When Driver B does not run because its DEPEX is not satisfied, the right question is not “what is wrong with Driver B?” but “who is supposed to install the protocol B is waiting for?”

Driver B does not run
  → B needs Protocol X
  → Who installs Protocol X?
  → Driver A
  → Did Driver A run?
  → A needs Protocol Y
  → Who installs Protocol Y?
  → ...

If you trace to the end of the chain without finding anyone who installs the root protocol, that is where the bug is — typically a driver missing from the FDF, or a DEPEX error in the root driver.

Checklist when debugging the DXE Dispatcher

Does the INF have the correct MODULE_TYPE and file type (DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER, ...)?
Is the INF in the DSC to be built?
Is the INF in the FDF/FV to be packaged into the image?
Which protocols does DEPEX require — have they been installed?
Did the driver that installs those protocols run — trace the dependency chain backwards.
Enable the relevant debug level for dispatch, or use the map file/FV dump to confirm the driver is in the image.
Are logs hidden by log level — try adding a DEBUG_ERROR print or checking with a breakpoint/map file.

Common misconceptions

A successful build does not mean the driver will run. The driver must be in the FDF, DEPEX must be satisfied, and MODULE_TYPE must be correct. These three conditions are independent of whether the build succeeded.

A driver not running does not mean the driver is wrong. It is very common for a correct driver to not run because its dependency has not been installed — because another driver is missing from the FDF.

The dispatcher does not restart after finishing. If a protocol is never installed during the dispatch loop, the driver waiting for it will never run — there is no retry mechanism after BDS has started.

DEPEX in DXE depends on Protocols installed in the handle database — unlike PEI, where DEPEX depends on PPIs. The dispatchers for the two phases are also completely separate.

Self-check questions

What does the DXE Dispatcher use DEPEX to decide?
Why might a driver fail to run despite a successful build?
What happens to a driver that is in the DSC but missing from the FDF?
Does DXE DEPEX depend on PPIs or Protocols?
Why can a driver that installs a new Protocol cause another driver to be dispatched in the next round?
If Driver B does not run because Protocol X is missing, how do you trace the dependency chain?
When suspecting a driver has not been dispatched, what should you check?
Why should you not rely on the order of files in the FDF to control driver execution order?

Public references

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác