What is the BDS to TSL Handoff?

Explains the BDS to TSL handoff in BIOS/UEFI: BootOrder, Boot####, Device Path, ConnectController, LoadImage, and StartImage.

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

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

BDS to TSL handoff is the point where firmware moves from Boot Device Selection to Transient System Load. The Boot Manager selects a boot option, connects the device path, loads the bootloader with LoadImage(), and then calls StartImage() so the bootloader can start running.

In short, BDS to TSL handoff is when firmware runs the .efi file selected by the boot option.

Where it sits in firmware flow

A simplified flow is:

DXE
  Drivers and protocols are ready
BDS
  Read BootOrder, BootNext, Boot####
  Select boot option
  Connect device path
  LoadImage()
  StartImage()
TSL
  OS loader or boot application runs
  GetMemoryMap()
  ExitBootServices()
Runtime

BDS is not the OS loader. BDS is the firmware component that selects and starts the loader. TSL is the phase where the loader is running while Boot Services still exist.

What a boot option contains

A Boot#### usually contains:

Attributes
Description
Device Path
OptionalData or LoadOptions

The Device Path may point to an ESP and a loader file such as:

HD(...) / File(\EFI\Microsoft\Bootootmgfw.efi)
HD(...) / File(\EFI\BOOT\BOOTX64.EFI)

If the Device Path becomes stale after cloning a disk, replacing an SSD, changing a slot, or editing partitions, BDS may select the right Boot#### but still fail to find the real file.

Connecting the device path

Before loading the file, BDS often needs to connect the controllers on the Device Path. If the storage driver did not bind, the filesystem did not appear, or the path is missing an important node, LoadImage() may return EFI_NOT_FOUND even though the file exists from another viewpoint.

Separate the failure like this:

Was Boot#### selected?
Is the Device Path still correct?
Were the controllers connected?
Did Simple File System appear?
Did LoadImage load the file?
Did StartImage run the loader successfully?

LoadImage and StartImage are different

LoadImage() reads the .efi file, applies policy such as Secure Boot if enabled, and creates an image handle. StartImage() is what transfers control to that image.

The failures are different:

LoadImage fails: suspect file path, filesystem, architecture, Secure Boot, image format
StartImage fails: the loader was loaded but returned an error or crashed early

If the log only says “boot failed” without separating LoadImage and StartImage, debugging becomes much harder.

Common debug case

A practical failure looks like this:

BootOrder is correct
Boot0001 is Windows Boot Manager
Shell can see fs0:
But the machine boots directly to Setup

Check these points:

Does BootNext override the normal order?
Does Boot0001 still have the ACTIVE bit?
Does the Device Path in Boot0001 match the disk and partition GUID?
Did BDS call ConnectController for that path?
What status did LoadImage return?
What status did StartImage return?
Did Secure Boot reject the image?

Seeing fs0: in the Shell does not guarantee that Boot#### is correct. The Shell may map the current filesystem, while Boot#### still uses an old Device Path.

Source-reading checklist

When reading BDS to TSL handoff code, I usually follow this order:

1. Variables: BootOrder, BootNext, Boot####
2. EFI_LOAD_OPTION: attribute, description, FilePathList, OptionalData
3. Device Path: HD node, FilePath node, full text output
4. ConnectController or ConnectDevicePath path
5. Simple File System and file open
6. LoadImage status
7. StartImage status
8. Fallback boot path for removable media
9. Secure Boot or image verification log

Conclusion

BDS to TSL handoff is where firmware selects a boot option and starts the bootloader. When boot fails, separate Boot#### selection, Device Path connection, LoadImage(), and StartImage(). Looking only at BootOrder or Shell fs0: is usually not enough to find the real cause.