Boot from USB Looping

[Its-TeeJay]

Running into a strange issue after my most recent builds where selecting to boot from the FFU USB just reopens the boot menu. It only does this until you turn Secure Boot off, but it was not doing this prior to the most recent main branch build that I ran last week, and I rebuilt today to try again on 2604.1 and had the same issue. Issue occurs on multiple computer models (HP ProBook 460 G11 and 4 G1i, Lenovo ThinkPad X1 Carbon Gen 12/13).

[astavitsky]

I suspect the Secure Boot certificates on those models were not updated, and the new boot image does not recognize them. Update the BIOS/UEFI firmware on those devices and see if the boot succeeds with Secure Boot on. Alternatively, you can turn Secure Boot off, install the OS, run the updates that will, hopefully, update the certs in the firmware, and then turn Secure Boot back on. This worked for me on the Surface tablets.

[Its-TeeJay]

After some further testing it actually seems to be the opposite. It only seems to happen on devices that have been updated to the latest Windows 11 Security Update (in this case 2026-06). Any on 2026-05 or earlier don't have this issue, but once updated past this they start hitting the boot loop again.

[rbalsleyMSFT]

Are you using updated deployment media, or are you using an older version? If you updated to 2604.1 and just created a new FFU but kept your old media (e.g. just copied in new FFU files to your deploy partition but left the boot partition), then you're likely using the old BootBCD.

If that's not the case, then I'd look at the ADK version you have installed. If you're using 10.1.28000.1, then you're likely running into the issue described in these release notes - https://github.com/rbalsleyMSFT/FFU/releases#release-v2603.2. Downgrade the ADK and that should work.

If neither of those items are the issue, then I'd start to look at whether the older certificates are in the DBX on these devices. There's a https://github.com/rbalsleyMSFT/FFU/tree/SecureBootTesting branch which is older, but has some logging that could be useful to understand what's in the DB/DBX, etc. I used this branch to gather logging that helped understand the issue that was ultimately fixed in 2603.2, but decided to not collect all of those additional logs moving forward.

I'd also double check that the devices in question have the latest BIOS/UEFI firmware updates.

[Its-TeeJay]

I think you may have nailed it with the old boot files. I'll fully rebuild a flash drive tomorrow and give it another shot, but I do know that I haven't updated the boot files in a couple months. Will update once I test that out.

[rbalsleyMSFT]

If you have a copy of the scriptlog.txt file, that would tell me what version of the boot files you have.

[Its-TeeJay]

I did confirm that I had old boot files, but I've run into another issue. On trying to rebuild a USB today to fix the boot file issue, none of my msstore apps will download. All have the same error code (DownloadError System.Runtime.InteropServices.COMException (0x8A150081)) which seems to point to an inability to connect with the Microsoft Store for package info. I'm able to download the individual apps via winget in a separate PowerShell instance just fine, but when running an FFU build all of the msstore app downloads fail.

[rbalsleyMSFT]

I don't see the same thing on msstore app downloads via winget.

Did you try with the UI? Same error?

[Its-TeeJay]

Yes, the error is actually only in the UI. Msstore app installs via winget normally work as expected, but I get the download errors when trying to build an FFU through either PowerShell or the UI. I also get the error in the UI apps menu when trying to pre-download apps. Winget apps work fine, but anything with the msstore as a source fails.

[rbalsleyMSFT]

Can you try to download calculator? This should use winget to download the app and license file. You can just copy/paste this right into your PowerShell 7 console.

$appId = '9WZDNCRFHVN5'

winget --info
Get-Module -ListAvailable Microsoft.WinGet.Client |
    Select-Object Name, Version, Path

winget download --id $appId --source msstore --exact `
    --download-directory "$env:TEMP\FFU-StoreTest" `
    --authentication-mode interactive `
    --accept-source-agreements --accept-package-agreements `
    --verbose-logs

If that download succeeds, try to use the Winget module manually, which is what FFU Builder uses. Use the same PowerShell 7 console window.

Import-Module Microsoft.WinGet.Client -Force
Export-WinGetPackage -Id $appId -Source msstore `
    -DownloadDirectory "$env:TEMP\FFU-StoreTest-Module" -Verbose

I suspect there might be an issue with the PowerShell module. But seeing this work via CLI vs the Module will help narrow it down.

[Its-TeeJay]

I've left work for the day, but I'll do this first thing in the morning.

For what it's worth, I uninstalled/reinstalled Snipping Tool (it's in my app list for FFUs) via the standard "winget install --id" commands in an elevated PowerShell 7 window with no issues, but the same app would fail in the UI.

I'll give the Calculator installs a shot in the morning and let you know what happens.

[rbalsleyMSFT]

Thanks. Install and download are different operations, so I'm curious if download via the winget CLI works.

[zehadialam]

I've been experiencing the same issue for msstore apps. The download command using the winget cli causes this error:

[rbalsleyMSFT]

Did you run the commands I posted? If so, what's the winget info show?

[zehadialam]

Here's the output from those commands:

[Its-TeeJay]

Exact same output here