What is the DXE Dispatcher?
Explains the DXE Dispatcher in BIOS/UEFI: DEPEX, protocol dependencies, FV discovery, and how to debug a driver that never runs.
DXE Dispatcher is the part of DXE Core that finds DXE drivers in firmware volumes, evaluates their dependencies, and calls their entry points. If PEI brings the system into DXE Core, the dispatcher is what starts DXE modules in a controlled order.
In short, DXE Dispatcher answers this question: which driver is ready to run, and when should it run?
Where it sits in firmware flow
A simplified flow looks like this:
Reset Vector
SEC
PEI
PEI to DXE Handoff
DXE Core
DXE Dispatcher
Driver EntryPoint
Protocol Database
BDS
TSL
RuntimeDXE Dispatcher is not BDS. It runs before BDS and builds the driver, protocol, and service environment that BDS later uses to select a boot option.
What does the dispatcher depend on?
A DXE driver does not run just because its source file exists in the repository. Usually these conditions must be true:
The module is selected by DSC
The module is placed into the firmware image by FDF
The Firmware Volume containing the module is visible to DXE
The module DEPEX is satisfied
DXE Dispatcher calls the EntryPoint
The EntryPoint returns a valid statusA common mistake is to assume that a module in the source tree or build output is also present in the real BIOS image. Another mistake is to assume that a module present in an FV must be dispatched. If its DEPEX is not satisfied, it can stay pending.
How DEPEX affects dispatch
DEPEX means dependency expression. It tells the dispatcher which protocols or conditions must exist before a driver can run. A storage driver may depend on PCI I/O Protocol, while a network driver may depend on a controller handle created by a bus driver.
If the dependency is missing, the dispatcher keeps the driver waiting. When a new protocol is installed, the dispatcher may re-evaluate pending drivers.
EntryPoint is different from Start()
DXE Dispatcher calls the module entry point. For a UEFI Driver Binding driver, that entry point usually only installs EFI_DRIVER_BINDING_PROTOCOL. The driver actually binds to a controller when ConnectController() calls Supported() and Start().
So split the failure into two layers:
EntryPoint never runs: check DSC, FDF, FV, DEPEX, dispatcher
EntryPoint runs but the device is missing: check Driver Binding, Supported, Start, ConnectControllerCommon debug case
A practical failure looks like this:
Storage driver builds successfully
FV dump shows the driver
Shell does not show fs0:
BDS does not see the boot diskDo not jump directly into the storage algorithm. First check whether the driver was dispatched, whether the entry point logged anything, whether DEPEX is stuck, whether Driver Binding Protocol was installed, and whether Start() was called.
What to log
When debugging DXE Dispatcher, log by layer:
Was the Firmware Volume discovered?
Is the driver File GUID present in the FV?
What does the DEPEX section contain?
Was the dependency protocol installed?
Was EntryPoint called?
What status did EntryPoint return?
Was Driver Binding Protocol installed?Logs near the dispatcher help avoid debugging the wrong device-driver layer.
Source-reading checklist
When reading source around DXE Dispatcher, I usually follow this order:
1. INF: module type, file GUID, entry point, depex
2. DSC: whether the module is built
3. FDF: whether the module is placed into an FV
4. FV dump: whether the real BIOS image contains the module
5. DEPEX: whether dependencies are satisfied
6. EntryPoint: whether there is a log or side effect
7. Driver Binding: if entry point ran but the device is not readyConclusion
DXE Dispatcher turns DXE modules in a firmware image into code that actually runs. When a driver does not work, separate three layers: whether the module is in the image, whether the dispatcher called its entry point, and whether the driver successfully bound to a controller.
Found this article useful?
Share it with someone learning firmware, BIOS/UEFI, or embedded systems, or support the author.
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.
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.
What is Driver Binding Flow?
Explains UEFI DXE Driver Binding Flow: Supported, Start, Stop, ConnectController, protocol ownership, and debugging bind failures.
What is Start() in the UEFI Driver Model?
Start() is where a driver binds to a controller: open BY_DRIVER, install protocols, create child handles. Understand the cleanup fail path and dirty handle database anti-patterns.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.