Win11 23H2 22631.3007 findings

[Pater]

Captured a WIn11 23h2 image from sysprep VM, updated to 22631.3007. Used the same preset to lite-n it using NTLite v2023.12.9553 --here are some findings:

Resulting install.wim (not .esd) is 0.03 bigger than Dec 2023 build state. -- not much, but then I removed a few additional components in this current build vs the Dec one. The difference in size lies mainly in \Program Files\WindowsApps. It appears there are some additional runtimes present in the .3007 build. On the Dec build it retained Microsoft.UI.Xaml.2.7.x (one instance, x64 only), whereas in this current .3007 build it retained both arches for .Xaml.2.7x AND 2.8.x as you can see in the screenshot below (Dec build left; .3007 build right). Again same for the VCLibs.140 which also occurs dual arch. I don't know whether the inclusion of x86 runtimes there is new since I did not specify removal of these for the Dec build, and yet x86 runtimes are absent in the NTLite'd Dec image. See:



Perhaps this will be useful. Attached is my preset.

 

[Pater]

I liked keeping modern Calc in there plus the Webp and other format support is handy because certain image viewers rely on it, etc. Resulting .3007 NTLite'd image install.esd size: 1.33gb. My Dec build was about the same size (little smaller, see above) and I've been running that live for several weeks, throwing anything I could at it and it's very stable.

 

[garlin]

My understanding is one of the OOBE WU tasks is checking for critical UWP app updates. I presume that's where UI.Xaml getting pulled, because one of AppInstaller's jobs is downloading "missing" pre-req's.

 

[nuhi]

Hi,

tested now by integrating .3007 CU, and there is no Xaml.2.8 in Apps.
So it must be that your sysprepped OS auto-installed Store apps, thus the newer Xaml 2.8 with its x86 part.

You can disable store app autoupdate by deleting 'automatic app update' scheduled task, and/or disabling the 'Windows Store - Install updates automatically' Setting.

If you're asking can there be a 32-bit App removal split, yes, potentially - if more cases arise.

 

[Pater]

Yes, it is UWP apps updating in background. I think what I'm pointing out is that the type and amount (and versions) of these remained stable for me for a good while, to now see this jump to x64-x86 varieties and more of them, plus what would seem to be reduntant version of the same app with the same main build number, which is probably at least something NTLite would want to address as there doesn't appear to be a mechanism in place (that worked) that gets rid of the older versions in Windows itself.

 

[garlin]

I don't agree that NTLite needs to solve this problem.

When there are automatic app updates (via WU, Store App, or OOBE), then newer app packages get installed. AppInstaller's role is to read the referenced Appx manifests and install whatever pre-req's are demanded.

UWP frameworks are like .NET, they're designed to have multiple releases exist side by side. There will always be one version (per architecture) of a given release, but Windows wants to decide if you need UI.Xaml 2.4 thru 2.7, and whether to include the x86 builds.

I presume if you disabled updates, and removed AppInstaller (losing winget in the process), then Windows would stop populating those other releases on the system. My point is even if you cleaned up your captured image, Windows would tend to mess up it again.

 

[Pater]

Yes, most definitely it would I guess what I was getting to was that the SystemApps seemed rather stable for a long period of time, and NTLite was programmed to address them (allow their removal). So what I'm suggesting is that it would merely be a broadening of the detection of those removals; i.e., say you remove UI.Xaml, well NTLite detects it (or used to) and so you remove it. Now, it will remove maybe one version and arch, and not be able to remove the others as it doesn't recognize them. Unless there is a safe way to manually remove the redundant versions and/or archs, then that would be an easy fix (I haven't tested that as of yet).

It was just that I would always update the sysprep VM, then use any runs of NTLite afterwards. But something nuhi implied is that could I edit the image pre-sysprep, so that the additional uwp apps don't download, so that NTLite would also not be burdened by having to detect and remove those. In that case I've learned a good new approach

Thanks for the input, I'll play around with that and see what it yields.

 

[Pater]

UWP frameworks are like .NET, they're designed to have multiple releases exist side by side. There will always be one version (per architecture) of a given release, but Windows wants to decide if you need UI.Xaml 2.4 thru 2.7, and whether to include the x86 builds.

But that point right there is well taken. It would then only become an issue to look into when future version of uwp apps that one might like to retain in the image would possibly require newer/specific versions of said runtime(s), upon which one would then have to figure out which to retain. But that gets into the fringe, I realize. Good talk