How the DXE Dispatcher Coordinates UEFI Drivers

The Driver Execution Environment (DXE) Dispatcher is the core engine within the UEFI DXE phase responsible for discovering, evaluating, and executing DXE drivers. It coordinates driver execution by traversing Firmware Volumes (FVs), evaluating individual driver Dependency Expressions (DEPEX) against a dynamic protocol database, and executing valid drivers in iterative passes until all boot dependencies are satisfied. This mechanism guarantees that hardware initialization and architectural services occur in the correct, deterministic order regardless of the physical storage order of the drivers in flash memory.

Firmware Volume Discovery and the A Priori List

Before dynamic dependency resolution begins, the DXE Dispatcher scans available Firmware Volumes for executable PE32/PE32+ driver images.

If a Firmware Volume contains an optional file known as the A Priori list, the Dispatcher processes it first. The A Priori file contains an explicit, hardcoded list of driver GUIDs. The Dispatcher executes these listed drivers strictly in the sequence defined by the file, bypassing their normal dependency expressions. This ensures that fundamental architectural components—such as CPU architectural protocols, memory allocation services, and system timer infrastructure—are initialized before the general dispatch algorithm commences.

Dependency Expressions (DEPEX)

Drivers not governed by an A Priori list must declare their prerequisites using a Dependency Expression (DEPEX). Embedded in a specific section of the driver's executable binary (EFI_SECTION_DXE_DEPEX), a DEPEX is a small bytecode sequence composed of boolean logic operators (AND, OR, NOT) and protocol GUIDs.

A DEPEX dictates the environmental conditions required before the driver can safely run. For example, a PCI host controller driver might require the CPU I/O Protocol and Metronome Architectural Protocol to exist before its entry point can be invoked. If a driver has no dependencies, its DEPEX section evaluates unconditionally to TRUE.

The Dispatch Loop Execution Model

The DXE Dispatcher employs an iterative state machine to process non-A Priori drivers:

1. Discovery and State Tracking: The Dispatcher maintains an internal database of all discovered drivers across all accessible Firmware Volumes. Each driver is assigned a state, typically progressing from Unprocessed to Scheduled, Initialized, or Failed.
2. Evaluation Pass: The Dispatcher iterates through the list of uninitialized drivers and evaluates each driver's DEPEX bytecode against the current UEFI Protocol Database.
3. Execution: When a driver's DEPEX evaluates to TRUE, the Dispatcher:
   • Loads the driver image into system memory via the LoadImage() boot service.
   • Invokes the driver's entry point using the StartImage() boot service.
   • Monitors the return status. As the driver executes, it typically installs new protocols into the protocol database using InstallProtocolInterface() or InstallMultipleProtocolInterfaces().
4. Re-evaluation (Iterative Loop): The addition of new protocols to the database changes the system state. Consequently, the Dispatcher restarts or continues the evaluation pass, as previously unsatisfied DEPEX expressions for other pending drivers may now evaluate to TRUE.

Termination and Hand-off to BDS

The dispatch loop repeats until a "fixed point" is reached—a complete pass over all remaining drivers yields no new DEPEX evaluations that evaluate to TRUE.

Once no further drivers can be dispatched:

• Firmware Volume Extensions: If a newly dispatched driver produces a protocol that exposes an additional Firmware Volume (such as a compressed payload or external storage), the Dispatcher mounts the volume, discovers the newly accessible drivers, and resumes the dispatch loop.
• Hand-off: When all discovered Firmware Volumes are fully processed and all solvable drivers have executed, the DXE Dispatcher invokes the architectural protocol that launches the Boot Device Selection (BDS) phase, transferring control to the platform boot manager. Any drivers with unsatisfied dependencies remain unexecuted.