Bug: Image Size

Hellbovine

Hellbovine

Well-Known Member
Update: August 23rd, 2023 (Unresolved)

Summary: Creating an image using only a few edits makes the disk space grow substantially, when it should be shrinking.

MORE INFORMATION
OS: Unmodified Windows 10 ISO, version 21H2, build 19044.1288
NTLite: version 2.3.9.9002, default settings, WIM compression set to 0

Steps I took to expose this issue:
1) Convert ISO to WIM format, use the trim other editions option and process it. The resulting folder of files is 9.07 GB.

2) Next I only did simple changes, then processed those:
- Replaced the existing DefaultLayouts.xml and added LayoutModification.xml
- Integrated 2 registry keys via a .reg file, for changing the default power plan to high performance
- Check the reapply tasks (registry keys) so that Install, PE, Setup, and Recovery use new power plan
- Remove OneDrive component (using licensed NTLite)

The result is that the Windows image folder grows substantially, becoming 10.1 GB in size. It should have shrunk by about 300 MB with the removal of OneDrive, rather than growing by 1 GB. This issue might be related to this other post (link1), but it could be unrelated too since their issue is post-install image size, while mine is about pre-install image size. I never paid attention to the image size in the past until I started messing with the WIM compression (link2) setting. Compression settings will change things obviously, but that shouldn't be the issue here.
 
Last edited:
What I'm wondering is how much is data, which is no longer saved as hard linked files. The reason for using DISM instead of "unzipping" WIM is to preserve hard links to save installed disk space on the target system. Obviously if you edit a file, you're breaking the link.

Going back to the classic NVIDIA example, if you integrate multiple INF files from the same distribution package -- each INF carries a forked copy of all the non-driver DLL's. When NTLite adds them to DriverStore, it doesn't check to see if the next added file has a duplicate first and creates a hard link instead of a new file. That way, when it's extracted the NVIDIA DLL's don't consume another 10-20 GB.
 
Some points to consider:

- Some components when removed have their counterpart in the WinSxS folder kept if Servicing Stack compatibility is checked (no deep removals) so they often reduce very little or nothing of the occupied space;

- When you mount a .wim file and save with Dism old files are kept, you need to export the indexes to remove this and have an effective reduction in the image. It may be that under some circumstances NTLite is not "rebuilding" the image by exporting the indexes. I've had this problem in the past but it looks like it's been fixed since I never experienced it again. If that's the case you can always right click install.wim under Source in NTLite and Convert -> Recompress

You can also open install.wim with 7-Zip to see if it has any old files.

boot.wim from Win10 22H2 official ISO from November 2022:

1670466685584.png

This [DELETED] folder contains the old files.
 
Most people forget to do a "DISM Cleanup in NTL Updates tab in second run or on a live install afterwards:
Dism /online /Cleanup-Image /StartComponentCleanup
That can reduce and installed image with about 2-4 GB's depending on removals.
After install seems to reduce more than in NTL.
 
I forgot to mention I used the default settings when it comes to DISM and everything else in NTLite. This issue is easy to replicate, and I listed all the pertinent information in the main post. I didn't do anything extreme, so the problem has to be on NTLite's or Microsoft's side of things.

Garlin's explanation makes sense to me though, so I can understand if that's the problem. But what is curious, is how did nobody else notice this over the years too then? So that's why I kind of lean towards bug, but I'm not sure.
 
Last edited:
Don't forget to turn off Reserved Storage and hibernate in Setttings. And if integrate updates with NTL and removals, a second run with NTL and UPDATES/ DISM compatible could be the waiting time worth depending how fast your CPU is.
My WIM 11 22H2.819 install is about 3.5 GB and about 6.1 installed.
 
My issue is pre-install. The image size that NTLite creates is growing, while the other user's thread is post-install disk size. I have hibernate disabled on the machine I use NTLite on, as well as pagefile. I'm not sure what Reserved Storage is though, can you point me to that information?
 
Last edited:
It's the 7 GB reserved storage Windows used to upgrade your install to next build - so maybe there's your culprit.
 
Reserved Storage is W10 feature which pre-allocates (steals) disk space on first install, to guarantee there's enough room to download and install a complete new Windows release. This prevents the user from blocking W11 upgrades by using all the free space on C:.

While not related, there's also the Windows Cleanup KB, installed by OOBE, which is the scheduled task disk cleanup tool. This tool also tries sweep up background junk to free enough space for future downloads.

MS really, really wants you to update to the next Windows.
 
Exactly - the kinda way as Office 365 with monthly payment haha

BTW that's the most easy to block in NTL Settings/ Windows Updates/ Feature Updates safeguards (Upgrade block) or simply put a reggie:

Windows Rgistry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade]
"BlockFeatureUpdates"=dword:00000001
 
I'll check out the reserved storage for future tweaking, but it for sure isn't going to be the issue here.
 
Last edited:
Casual users are shocked because a clean install adds hibernation.sys & Reserved Storage right out of the box.
 
I bow for you ;)
W11.621.819 is 6.18 GB to be exactly after removals.
And still think about wtf happened to coders after C64 :cool:
 
You must log in or register to reply here.
Back
Top