abbodi1406's Batch Scripts Repo

You're right - it's the same old problem (setup binaries in boot.wim index 2 vs \sources on the media getting out of sync). But it's back with MumX v2 media:

In W10UI 10.66m, the `WinPE-Setup-Package~*.mum` existence check is false on a MumX-serviced boot.wim - only the .cat is materialized in the image, the manifest lives inside Windows\servicing\MumX\Package_for_RollupFix~...mumx.esd. So uupboot is wrongly set to 1, and the later :igdvd branch copies the expanded Setup DU's setuphost.exe over the one :boots just synced from boot.wim. Result: setuphost.exe 10.0.26100.9808 (media) vs 10.0.26100.9818 (boot.wim) - mismatch, and setup fails again.

Same old problem, different trigger: the .mum-based branch detection breaks on MumX media. Changing that existence check to .cat makes W10UI take the sync path again and the ISO installs fine.

 

@ananhaid , @abbodi1406 clarified it for me, i missed the cause is the source used for updating, my source ISOs for 11 are MVS, 26100.1742 and 28000.1450, so that's why there are no problems for me.

Apologies for the confusion at my side.

 

Hi abbodi,

A follow-up to the MumX v2 issue I reported earlier (KB5127936 / 26100.9818, LTSC media failing at the disk page).

I made a small local change to W10UI 10.66m and the ISOs I build with it are fine again — setup.exe and setuphost.exe in sources\ are identical to boot.wim index 2, and the media no longer hits the mismatch.

What I changed (small and local):
- added one helper mumx_try) that looks for Windows\servicing\MumX\*.mumx.esd after an image is mounted and, if present, extracts the needed .mum entries from it into a cache with MumxPack (https://github.com/Adavak/MumxPack);
- call it once before the update (source image) and once after the LCU is applied (new image); the cache is reused when the container name and size are the same, so all install.wim indices and boot.wim only cost one extraction;
- in the checks, try the loose .mum first and fall back to the cache when it is missing: :boot_lcu / roclcu (Baseline), :cuboot (Rejuv), :boots and :igoffline (WinPE-Setup), and the :cuinstall / cleanup comparisons;
- for the WinPE-Setup existence test I also accept the .cat on 26052+, since it is still materialized. No change to the DISM add-package flow itself.

The important part is not the setup files themselves, but whether every place where W10UI looks for a .mum file (existence) and every place where it reads something from inside a .mum (content) still makes sense on MumX v2 media:
- After a MumX v2 LCU is applied, WinPE-Setup-Package~*.mum is not present in the image (only .cat), so :boots takes the wrong branch and the SetupDU overwrites setuphost.exe.
- WinPE-Rejuv-Package~*.mum is also gone, so the Rejuv cleanup is skipped.
- Package_for_RollupFix*.mum is still there but stale (it stays at the old base version, e.g. 26100.1742), while the real 9818 manifest is inside Windows\servicing\MumX\...mumx.esd. So findstr Baseline, the version scan and the superseded-package comparison read the wrong data.

This is almost certainly not the right way to do it. For existence checks the .cat is still materialized, so maybe a two-word change is enough; for content reads you probably have a much better way — the servicing stack obviously knows how to read these containers. I would really appreciate it if you could take this further and do it properly; I'm sure you have a simpler and more robust approach.

Happy to share the patched W10UI.cmd and the tool if useful.

https://drive.google.com/file/d/1h9TZRxAA7PLbz_4Imofc2ncfdBaxZfqu/view?usp=drive_link

 

I tried both 157d8365a517c40afeb3106fdd74d0836e1025debbc343f2080e1a8687607f51 *en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00.iso and 4f59662a96fc1da48c1b415d6c369d08af55ddd64e8f1c84e0166d9e50405d7a *en-us_windows_11_iot_enterprise_ltsc_2024_x64_dvd_f6b14814.iso. Both ran thru and updated successfully with no errors but resulting ISO boots to dead end "install driver to show hardware" .... "a media driver your computer needs is missing" and is not installable". This is on VBox. What ISO should we be starting with?

 

The LCU component manifests are materialized normally: after applying 9818, boot.wim index 2 has 992 files matching *_10.0.26100.9818_* under Windows\WinSxS\Manifests (the 9725 image has 0).

But amd64_microsoft-windows-winpe-oc-setup_*.manifest is present in both 9725 and 9818 and stays at 10.0.26100.1, so it does not tell whether the WinPE-Setup package was applied.

The SOFTWARE hive does: the 9818 image's hive contains WinPE-Setup-Package~31bf3856ad364e35~amd64~~10.0.26100.9818 and Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9818.1.42, while the 9725 hive has the 9725/1742 identities. Note that the bare WinPE-Setup-Package~...0.0.0.0 key exists in both, so CurrentState (0x70) or the versioned key is needed.

So the load/query/unload SOFTWARE hive route looks like the right one. The SxS manifest route works only if the manifest version tracks the LCU.

 

v1:
https://drive.google.com/file/d/1wrTACaXelNgqQ7u7YhOBJ2YY2oLYoszR/view?usp=sharing

v2:
https://drive.google.com/file/d/1HKHqWKLUezrlZ8wAnAutJ67Zp3uFPa3z/view?usp=sharing

Thanks — the hive route works much better for me. I made a hive-based version of the patch and would appreciate your feedback.

What it does:
- after an image is mounted (and again after the LCU is applied), load Windows\System32\config\SOFTWARE, query Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages for CurrentState=0x70, write the installed package names to a small temp list, then unload the hive;
- the checks use that list for WinPE-Setup / WinPE-Rejuv existence and for the Package_for_RollupFix Baseline flag; loose .mum/.cat are still checked first where they exist, and the hive is authoritative for Baseline on 26052+.

What I measured on 9725 vs 9818:
- the LCU manifests are materialized normally: boot.wim index 2 has 992 *_10.0.26100.9818_* manifests after applying 9818, and 0 in the 9725 image;
- but amd64_microsoft-windows-winpe-oc-setup_*.manifest exists in both and stays at 10.0.26100.1, so it cannot tell whether WinPE-Setup was applied;
- the hive does: the 9818 hive has WinPE-Setup-Package~...10.0.26100.9818 and Package_for_RollupFix~...26100.9818.1.42 with CurrentState=0x70; the 9725 hive has the 9725/1742 identities. Note the bare WinPE-Setup-Package~...0.0.0.0 key is present in both, so CurrentState or the versioned key is needed.

The dump is only about 1 KB per image, so it is much lighter than extracting the container. I have not run a full media build with this version yet, but the dump and the three checks (WinPE-Setup, Rejuv, Baseline) behave correctly on the real 9818/9725 hives.

If you prefer the SxS manifest route, which manifest would you use? I could not find one for WinPE-Setup that tracks the LCU version. Happy to share the patched W10UI.cmd/zip if useful.