What Is the PEI to DXE Handoff?

Explains the PEI to DXE handoff, HOB list, DXE IPL, discovered memory, and common cases where DXE does not start.

October 28, 2025 Updated June 19, 2026 3 min read

The PEI to DXE handoff is the point where firmware moves from the PEI phase to the DXE phase. At this point, PEI has prepared enough memory and HOB information for DXE Core to run.

In short: PEI to DXE handoff is where PEI hands the initial system map to DXE.

A simple flow looks like this:

SEC
  -> PEI Core
  -> PEIM dispatch
  -> Memory discovered
  -> HOB list built
  -> DXE IPL
  -> DXE Core

What does PEI prepare for DXE?

PEI does more than initialize DRAM. It collects platform information and packages it into HOBs. DXE uses the HOB list to understand memory layout, firmware volumes, boot mode, resources, ACPI/NVS regions, and other platform data.

Important HOBs often include:

Memory allocation HOB
Resource descriptor HOB
Firmware volume HOB
CPU HOB
Boot mode HOB
GUID HOB for platform data

If a HOB is missing or wrong, DXE may still start but later behavior can be wrong. A driver may not find an FV, a memory type may be wrong, or BDS may miss required resources.

What is DXE IPL?

DXE IPL is the PEIM that finds DXE Core and transfers control to it. It is the bridge from the end of PEI into DXE. If DXE IPL cannot find DXE Core, or the firmware volume containing DXE Core is wrong, DXE will not start.

Common failures include:

DXE Core is not in the expected FV
FV HOB was not created
HOB list is corrupted
memory is insufficient or has the wrong type
DXE IPL is not dispatched
jump to DXE Core fails

This is not ExitBootServices

PEI to DXE handoff happens early in firmware, before BDS and before the OS loader. ExitBootServices() happens much later, when the OS loader is already running and wants to take memory management away from firmware.

PEI to DXE: PEI transfers control to DXE Core
ExitBootServices: OS loader terminates Boot Services

These two concepts should not be used interchangeably.

Debugging when DXE does not start

If logs stop at the end of PEI, check in this order:

Did PEI memory initialization succeed?
Was the HOB list created?
Is there an FV HOB that contains DXE Core?
Was DXE IPL dispatched?
How does DXE IPL find DXE Core?
Is the stack/memory used for jumping into DXE valid?

If DXE Core has already started, the problem may be in the DXE dispatcher, DEPEX, or driver placement, not in the handoff itself.

Source-reading checklist

When reading the PEI to DXE handoff path, check:

1. Where is memory discovered and which HOBs are created?
2. Are resource descriptor HOBs correct?
3. How is the firmware volume containing DXE Core described?
4. Is the DXE IPL PEIM included in the firmware image?
5. What DEPEX allows DXE IPL to be dispatched?
6. How does DXE IPL locate DXE Core?
7. Is the HOB list pointer passed to DXE valid?
8. Where is the first DXE Core log?

Conclusion

The PEI to DXE handoff is important because it connects PEI memory initialization and HOB creation with the driver world of DXE. If a machine has PEI logs but no DXE logs, focus on discovered memory, HOB list, FV HOBs, and DXE IPL before debugging drivers or BDS.