Windows 11 26H2 Insider update keeps failing and saying “Undoing changes”

Hi, I’m having a problem upgrading Windows 11 Insider Preview.

My current version is:

Windows 11 Pro
Version 26H2
Build 10.0.26300.9550

I’m trying to install a newer Insider build, but the update keeps failing after it actually starts installing.

It downloads the update, starts the installation, and then at some point the PC reboots and shows:

Undoing changes made to your computer

After that finishes, Windows starts normally again and I’m back on build 26300.9550.

This has happened multiple times.

I started investigating because I wanted to figure out why Windows keeps rolling the update back instead of just failing during the download.

I checked SFC, DISM, CBS logs, Windows Update logs, WinSxS, manifests, Windows Update staging files, and multiple Windows ISO files.

SFC does not find any corrupted system files.

I also investigated some suspected file corruption that showed up during the earlier checks, including the files that were being referred to as “photon” corruption. SFC confirmed that those system files are fine, so that does not appear to be the issue.

The thing that stood out was a specific bootmanager-efi component:

amd64_microsoft-windows-b..ore-bootmanager-efi_31bf3856ad364e35_10.0.26100.1746_none_2325d0cc4c7bebb0

I found these files associated with it in the Windows Update staging folder:

boot.stl
bootmgfw.efi
bootmgfw_ex.efi
bootmgr.efi
bootmgr_ex.efi
securebootrecovery.efi
winsipolicy.p7b

So the files themselves are there in the update staging area.

The strange part is that I could not find the corresponding properly registered component in the actual WinSxS location.

I also checked the WinSxS manifests and could not find the manifest for this exact component in the normal registered location.

I tried the normal repair methods first, including Windows Update repair, DISM and SFC, but none of them fixed the upgrade.

I also checked multiple Windows ISOs to see whether I could get this exact component from installation media, but I could not find the 10.0.26100.1746 version there either.

Then I checked another completely separate, healthy Windows installation that is already running a much newer Windows build.

That PC has other bootmanager-efi versions, including newer ones, but it also does not have:

10.0.26100.1746

I also noticed a difference in the WinSxS backup structure. On the healthy installation, the files have the normal servicing structure and naming, while the files I found in my Windows Update staging folder are just the normal file names without that same registered component structure.

That made me wonder whether these are just update payload files that were downloaded but never properly registered into the component store.

I also tried to see whether I could manually restore them into WinSxS, but Windows blocks direct writes to the protected WinSxS location.

I understand that simply copying the seven files into WinSxS would not necessarily fix the problem anyway, because Windows also needs the component's servicing metadata and registration.

So I have not treated copying the files as a real repair.

The part I am trying to understand is why Setup seems to care about this exact component/version in the first place.

The version is:

10.0.26100.1746

but I cannot find that version on the other healthy Windows installation, and I cannot find it in the Windows ISOs I checked either.

At the same time, my own Windows Update staging folder contains the seven files belonging to it.

The upgrade behavior is always the same:

Update downloads
        ↓
Installation starts
        ↓
Windows goes through the upgrade/servicing process
        ↓
Something fails
        ↓
PC restarts
        ↓
“Undoing changes made to your computer”
        ↓
Windows rolls everything back
        ↓
I return to build 26300.9550

So I’m trying to figure out whether I actually have a corrupted/missing component, or whether Setup is incorrectly looking for an old component version that should no longer be required.

I also want to make clear that I’m not claiming that 10.0.26100.1746 is definitely the cause. This is simply the one thing that stood out during the investigation, and I want to know whether it is actually related to the upgrade failure.

Could someone from Microsoft help confirm:

1. Is this bootmanager-efi component and version 10.0.26100.1746 supposed to exist on my upgrade path?
2. Is this component actually required for the newer Insider build?
3. If it is required, what is the proper Microsoft-supported way to restore it and its registration?
4. Why would the seven files be present in Windows Update staging if the corresponding registered component is missing?
5. Could Setup be incorrectly referencing this older component version during the upgrade?
6. Can the CBS/Setup logs confirm whether this component is actually what is causing the rollback?
7. Is there a known Insider issue with this component or with upgrading from build 26300.9550 to the newer build?

I can provide the relevant parts of CBS.log, setupact.log, setuperr.log, DISM output, SFC output, and the exact setup error codes.

I’m trying to fix the existing installation and get the Insider update working without doing a clean Windows installation.

Thanks.