Thanks for W10UI. I switched to it a while ago from doing this by hand with DISM and it's saved me a lot of maintenance, so I appreciate you keeping it up.
I'm running into a problem with checkpoint cumulative updates (24H2/25H2) on boot.wim. Integrating the 2026-06 CU for Windows 11 25H2 (KB5094126, 26100.8655), which has a checkpoint prerequisite, KB5043080 (26100.1742). My media is from May 2026, so boot.wim is already at 26100.8457, past that checkpoint. install.wim and winre.wim are fine. boot.wim fails on the checkpoint:
Installing updates...
Processing 1 of 1 - Adding package Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
[==========================100.0%==========================]
An error occurred - Package_for_RollupFix Error: 0x80073712
Error: 14098
DISM failed. No operation was performed.
...
Processing 1 of 1 - Adding package Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8655.1.20
[==========================100.0%==========================]
The operation completed successfully.
The checkpoint (26100.1742) errors out, but the LCU delta (26100.8655) still gets applied after it, so boot.wim ends up with the delta on a base that doesn't match. The ISO then won't boot, WinPE doesn't start. Happens on both boot.wim indexes. install.wim takes the exact same packages without complaint.
This isn't specific to my setup. It should hit anyone slipstreaming a checkpoint CU into media that's already newer than the checkpoint, and I don't think you can just leave the checkpoint out when Net35=1 (more on that below).
Since boot.wim is already at 26100.8457, the 26100.1742 checkpoint is superseded and shouldn't need to go on at all. Looking at the :cuboot path, the checkpoint and the LCU get expanded and added to boot.wim as separate standalone packages, regardless of what the image already contains. install.wim swallows that, the stripped-down WinPE image won't take the standalone checkpoint.
Microsoft's checkpoint method handles the same boot.wim fine. Point /Add-Package at the target LCU msu, keep the checkpoint msu in the same folder, and DISM figures out what's needed:
dism /Mount-Image /ImageFile:C:\bwtest\boot.wim /Index:1 /MountDir:C:\bwtest\mnt
dism /Image:C:\bwtest\mnt /Add-Package /PackagePath:C:\bwtest\cu\windows11.0-kb5094126-x64.msu
(C:\bwtest\cu holds only kb5094126 + kb5043080)
Processing 1 of 1 - Expand
[==========================100.0%==========================]
The operation completed successfully.
Processing 1 of 1 - DISM applied a single package. It decided the checkpoint wasn't needed (image already past it) and skipped it. No 0x80073712.
On why I don't think the checkpoint can just be dropped: Net35=1 is the default, so .NET 3.5 gets enabled, and the way I read the docs, enabling a feature wants the target LCU plus all the preceding checkpoints (Example 1, same doc). If that reading's right, install.wim really does need the checkpoint, which would fit with it taking the package without complaint. It's only boot.wim that breaks.
Could the boot.wim path either use that discovery approach, or skip a checkpoint the image already supersedes? Right now it force-applies it and that's what breaks WinPE.
Environment:
- W10UI v10.59b
- Source: de-de_windows_11_consumer_editions_version_25h2_updated_may_2026_x64_dvd_ceef8999.iso, boot.wim at 26100.8457
- LCU KB5094126 (26100.8655) + checkpoint KB5043080 (26100.1742)
- DISM 10.0.26100.8521
Thanks for W10UI. I switched to it a while ago from doing this by hand with DISM and it's saved me a lot of maintenance, so I appreciate you keeping it up.
I'm running into a problem with checkpoint cumulative updates (24H2/25H2) on boot.wim. Integrating the 2026-06 CU for Windows 11 25H2 (KB5094126, 26100.8655), which has a checkpoint prerequisite, KB5043080 (26100.1742). My media is from May 2026, so boot.wim is already at 26100.8457, past that checkpoint. install.wim and winre.wim are fine. boot.wim fails on the checkpoint:
The checkpoint (26100.1742) errors out, but the LCU delta (26100.8655) still gets applied after it, so boot.wim ends up with the delta on a base that doesn't match. The ISO then won't boot, WinPE doesn't start. Happens on both boot.wim indexes. install.wim takes the exact same packages without complaint.
This isn't specific to my setup. It should hit anyone slipstreaming a checkpoint CU into media that's already newer than the checkpoint, and I don't think you can just leave the checkpoint out when Net35=1 (more on that below).
Since boot.wim is already at 26100.8457, the 26100.1742 checkpoint is superseded and shouldn't need to go on at all. Looking at the
:cubootpath, the checkpoint and the LCU get expanded and added to boot.wim as separate standalone packages, regardless of what the image already contains. install.wim swallows that, the stripped-down WinPE image won't take the standalone checkpoint.Microsoft's checkpoint method handles the same boot.wim fine. Point
/Add-Packageat the target LCU msu, keep the checkpoint msu in the same folder, and DISM figures out what's needed:Processing 1 of 1- DISM applied a single package. It decided the checkpoint wasn't needed (image already past it) and skipped it. No 0x80073712.On why I don't think the checkpoint can just be dropped: Net35=1 is the default, so .NET 3.5 gets enabled, and the way I read the docs, enabling a feature wants the target LCU plus all the preceding checkpoints (Example 1, same doc). If that reading's right, install.wim really does need the checkpoint, which would fit with it taking the package without complaint. It's only boot.wim that breaks.
Could the boot.wim path either use that discovery approach, or skip a checkpoint the image already supersedes? Right now it force-applies it and that's what breaks WinPE.
Environment: