Share via

BCDBOOT, from the latest Windows ADK, enforces usage of the BootEX binaries.

Noah Kaltvedt 85 Reputation points
2026-01-05T07:21:10.8433333+00:00

Recently, I have been trying to deploy a Windows To Go (WTG) media for testing and I have come across a problem with the latest release of the Windows ADK (December 2024). Even if Windows To Go is currently unsupported, there are still ways to manually create the media.

While I was trying to stage the proper files to the EFI System Partition (size 256MiB), it has occurred that the utility BCDBOOT had enforced usage of the EX binaries that were rolled out with their corresponding Secure Boot (SB) certificates. However, Windows media pre-2023 do not contain the EX binaries, resulting in a common error that cannot be toggled on or off.

Environment and logs

Host Version - Windows 11 26H1 (Build 28020.1362, Canary)

Windows image attempting to be deployed - Windows 10 22H2 (via Microsoft's official download source)

Windows ADK version - ADK 10.1.26100.2454 (December 2024)

Secure Boot - Disabled on host.

Host - Legacy Compatibility Support Module (CSM) is not enabled.

Logs taken: (using pulled bootsect.exe from boot.wim)
PS C:\W10UTILS> bcdboot.exe G:\Windows /s Z: /f UEFI /v

BFSVC: ServiceBootFiles MuiOnly:n Res:y Fonts:y BootMgrOvw:n BootStatOvw:n DbgTrn:y SuspendBDE:n BootEx:y Offline:n

BFSVC: Failed to check UEFI DbDefault variable. Error code = 0xcb

BFSVC: BfspShouldUseExFiles - IsSbOn:n Has2023PCAinDb:y Has2023PCAinDbDefault:n BFSVC_USE_EX_BINS:y

BFSVC: Using Ex bins because SB is off and BFSVC_USE_EX_BINS is set.

BFSVC: Using source OS version a00004a610001

BFSVC: Unable to open file G:\Windows\boot\EFI_EX\bootmgfw_EX.efi for read because the file or path does not exist

BFSVC Error: Failed to validate boot manager checksum (G:\Windows\boot\EFI_EX\bootmgfw_EX.efi)! Error code = 0xc1

BFSVC Error: ServicingBootFiles failed. Error = 0xc1

Failure when attempting to copy boot files.

PS C:\W10UTILS>

Logs taken from using the Windows ADK's bcdboot: BFSVC: ServiceBootFiles MuiOnly:n Res:y Fonts:y BootMgrOvw:n BootStatOvw:n DbgTrn:y SuspendBDE:n BootEx:y Offline:n

BFSVC: Failed to check UEFI DbDefault variable. Error code = 0xcb

BFSVC: BfspShouldUseExFiles - IsSbOn:n Has2023PCAinDb:y Has2023PCAinDbDefault:n BFSVC_USE_EX_BINS:y

BFSVC: Using Ex bins because SB is off and BFSVC_USE_EX_BINS is set.

BFSVC: Using source OS version a00004a610001

BFSVC: Unable to open file G:\Windows\boot\EFI_EX\bootmgfw_EX.efi for read because the file or path does not exist

BFSVC Error: Failed to validate boot manager checksum (G:\Windows\boot\EFI_EX\bootmgfw_EX.efi)! Error code = 0xc1

BFSVC Error: ServicingBootFiles failed. Error = 0xc1

Failure when attempting to copy boot files.

I have also tried using bcdboot.exe from the second index of boot.wim, yet that fails.

My request:

I know that many users, including myself, would appreciate a dedicated and documented flag for this feature in a new ADK patch (such as bootex:n/bootex:y or /noex) or to fall back and use classic binaries when the EX binaries are not found. If there are workarounds, I would like to hear of them, as it would be greatly appreciated.

  • Expected: The expected behavior is for bcdboot.exe to fall back to classic binaries when Secure Boot is disabled or EX binaries are not present.
  • Reality: Because of the 2023 PCA, which enforces these binaries to be used, the operation simply halts and returns an error stating it cannot find these binaries.

Why this is an issue for many audiences of people

My main argument is how this can be handled in real-world deployment scenarios. Many enterprises and businesses still use older operating systems in embedded systems and workspace computers, such as Windows 10 (with the ESU), Windows 8.0/8.1, or other Windows OSes that function as expected.

Because of this error, businesses would often have trouble attempting to deploy Windows media to the system manually rather than using Setup media, as it most likely involves BCDBOOT usage. Some may use UEFI, some may not. But because UEFI is becoming standard in the modern systems we use today, these errors can not only be problematic but also can become more common and long before a fix can be created.

Conclusion

I hope my message can be seen and understood by Microsoft, but it ensures compatibility for many systems that consumers to even large enterprises rely on for everyday usage in their usual environments, from hobbyist environments to datacenters. Best regards, NK.

Windows for business | Windows Client for IT Pros | Devices and deployment | Set up, install, or upgrade
0 comments

Answer accepted by question author

VPHAN 33,910 Reputation points Independent Advisor
2026-01-05T09:00:22.71+00:00

Hello Noah Kaltvedt,

The previous suggestion to change your OS image was incorrect for your specific constraints. You are hitting a version mismatch between your servicing tool (ADK Dec 2024 / Windows 11 Canary Host) and your target OS (Windows 10 22H2).

The error BFSVC Error: ServicingBootFiles failed with code 0xc1 happens because the modern bcdboot.exe (from the new ADK or your Canary host) contains hardcoded logic enforcing the "2023 PCA" security mitigations (related to the BlackLotus bootkit patches). The tool is explicitly looking for "EX" binaries (e.g., bootmgfw_EX.efi) inside the \EFI_EX\ directory. Since Windows 10 22H2 predates this structure, the path lookup fails, and the tool refuses to proceed.

To fix this, you must downgrade the tool, not the OS. You need to use a bcdboot version that matches the generation of the OS you are deploying.

Solution 1: Use the Windows 10 ADK (Version 2004)

The cleanest "best practice" solution is to use the toolset designed for your target OS.

  1. Download the Windows ADK for Windows 10, version 2004.
  2. Install only the Deployment Tools feature (or extract them).
  3. Run the command using the full path to that specific legacy binary. Do not just type bcdboot as it will default to your system's Canary version.
    • Command: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\BCDBoot\bcdboot.exe G:\Windows /s Z: /f UEFI

Solution 2: using the boot.wim binary

You mentioned you tried extracting bcdboot.exe from boot.wim and it failed. This likely happened because you extracted only the .exe. When you ran it, it loaded the shared libraries (bcd.dll, bcdsrv.dll) from your Host OS (Windows 11 Canary), which reinjected the incompatible logic.

To make this method work, you must isolate the dependencies:

Mount your Windows 10 boot.wim (Index 2).

Create a local folder (e.g., C:\Temp\Win10Tools).

Copy the following files from \Windows\System32 of the mounted image into your temp folder:

bcdboot.exe

  `bcd.dll`
  
     `bcdsrv.dll`
     
     Run the command pointing to this local folder:
     
        `C:\Temp\Win10Tools\bcdboot.exe G:\Windows /s Z: /f UEFI`

This forces the executable to use its native DLLs, bypassing the 2023 PCA checks found in the Canary build's system files.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-01-05T07:21:22.8966667+00:00

    The issue you're experiencing with BCDBOOT enforcing the use of EX binaries is related to the changes introduced in the 2023 PCA (Platform Certificate Authority). This enforcement occurs even when Secure Boot is disabled, leading to errors when the required EX binaries are not present in the Windows media you are using for deployment.

    Currently, there is no documented flag in the ADK that allows you to bypass this requirement or to fall back to classic binaries when the EX binaries are missing. The expected behavior you described, where BCDBOOT would revert to using classic binaries under these conditions, is not supported in the current implementation of the tool.

    As a workaround, you might consider the following options:

    1. Using a different Windows image: If possible, try using a Windows image that includes the necessary EX binaries or is compatible with the current BCDBOOT requirements.
    2. Rebuilding the Windows media: If you have access to a Windows build that includes the EX binaries, you could recreate your Windows To Go media using that build.
    3. Monitoring for updates: Keep an eye on future updates to the Windows ADK, as Microsoft may address this issue in subsequent releases based on user feedback.

    For now, the limitations of the current BCDBOOT implementation mean that you will need to ensure that the media you are deploying contains the required files to avoid these errors.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.