Experiment Record 1

Experiment Record 1

Experiment Title

Investigating why, after installing a system using the WIM file from an original Windows system ISO image in WIMBoot mode, the C drive still occupies a large amount of space in certain cases.

Experiment Prerequisites

  1. Undoubtedly, all versions of Windows 10 and Windows 11 in Microsoft’s Windows system support WIMBoot mode startup.
  2. Using the WIM from a Microsoft original ISO can result in a successful WIMBoot creation, but after booting the system, the C drive usage remains very high (9-10 GB), equivalent to a normal system size.
  3. System WIM packages we create ourselves using Dism++ software can successfully use WIMBoot to save C drive space, with C drive usage around 2 GB.

Experiment Hypotheses

  1. The presence of multiple system versions in the WIM file causes this issue.
  2. Microsoft’s WIM is not optimized for WIMBoot.

Basis for hypotheses:

  1. Gemini3pro stated that WIM files need to be optimized for 4K, so the WOF driver can properly read data blocks from the WIM file. Otherwise, the WOF driver will activate a fallback mechanism, copying files from the WIM to the C drive, causing WIMBoot to fail. (AI-generated, credibility questionable)
  2. Gemini3pro stated that Microsoft’s WIM is optimized for Windows system installation speed, not for WIMBoot, and therefore cannot fully support WIMBoot. (AI-generated, credibility questionable)

Experiment Design

  1. Experiment 1
    1. Extract the WIM image from the original ISO file of Windows 10 LTSC 2019. Name it LTSC_original.wim. Verified that this WIM package contains only one system version.
    2. Using Dism++, Open Image File -> LTSC_original.wim, select the only system version inside, Export Image, and name it LTSC_exported.wim.
    3. Create a new virtual machine vmwimbootLTSC_original. In the PE environment, use WinNTSetup to install LTSC_original.wim in WIMBoot mode.
    4. Create a new virtual machine vmwimbootLTSC_exported. In the PE environment, use WinNTSetup to install LTSC_exported.wim in WIMBoot mode.
    5. After installation, boot the virtual machines and check the C drive space usage respectively.
  2. Experiment 2
    1. Extract the WIM image from the original ISO file of Windows 10 22H2. Name it 22H2_original.wim. Verified that this WIM package contains 6 system versions: Home, Home Single Language, Education, Pro, Pro Education, and Pro Workstation.
    2. Using Dism++, Open Image File -> 22H2_original.wim, select the Pro system version inside, Export Image, and name it 22H2_pro_exported.wim.
    3. Using Dism++, Mount Image -> 22H2_original.wim, target image: Pro, mount to directory D:\000.
    4. Using Dism++, save the mounted Pro image as a new file. File -> Save Image As, select compression rate as “Maximum Compression Image”, and name it 22H2_pro_repacked.wim.
    5. Using Dism++, unmount 22H2_original.wim, ensuring the D:\000 directory is empty.
    6. Create a new virtual machine vmwimboot22H2_original. In the PE environment, use WinNTSetup to install the Pro system from 22H2_original.wim in WIMBoot mode.
    7. Create a new virtual machine vmwimboot22H2_pro_exported. In the PE environment, use WinNTSetup to install 22H2_pro_exported.wim in WIMBoot mode.
    8. Create a new virtual machine vmwimboot22H2_pro_repacked. In the PE environment, use WinNTSetup to install 22H2_pro_repacked.wim in WIMBoot mode.
    9. After installation, boot the virtual machines and check the C drive space usage respectively.

Experiment Results

Experiment 1

  1. After booting into Windows, vmwimbootLTSC_original C drive usage: 2.78 GB
  2. After booting into Windows, vmwimbootLTSC_exported C drive usage: 2.80 GB

Experiment 2

  1. After booting into Windows, vmwimboot22H2_original C drive usage: 9.94 GB
  2. After booting into Windows, vmwimboot22H2_pro_exported C drive usage: 9.80 GB
  3. After booting into Windows, vmwimboot22H2_pro_repacked C drive usage: 9.82 GB

Results Analysis

In Experiment 1, the 0.02 GB difference in C drive usage is random error and can be ignored. Therefore, it can be concluded that the C drive usage after WIMBoot installation is consistent for both WIMs in Experiment 1.
Since a complete Windows system installed in normal mode requires about 10 GB of C drive space, and both virtual machines in Experiment 1 use <3 GB, the difference is statistically significant. Thus, WIMBoot is considered to have effectively saved C drive space.

In Experiment 2, the ~0.1 GB difference in C drive usage is random error and can be ignored. Therefore, it can be concluded that the C drive usage after WIMBoot installation is consistent for all three WIMs in Experiment 2.
Since a complete Windows system installed in normal mode requires about 10 GB of C drive space, and each virtual machine in Experiment 2 uses approximately 10 GB, the difference is not statistically significant. Thus, WIMBoot is considered to have not saved C drive space.

Supplementary Experiment

  1. Enter the Windows system of vmwimboot22H2_pro_repacked from Experiment 2, and attempt to delete the 22H2_pro_repacked.wim file used during WIMBoot creation.
  2. Enter the PE system of vmwimboot22H2_pro_repacked from Experiment 2, and attempt to delete the 22H2_pro_repacked.wim file used during WIMBoot creation.
  3. Repeat the above operations for the other two virtual machines in Experiment 2.
  4. Repeat the above operations for all virtual machines in Experiment 1.

Supplementary Experiment Results

All virtual machines in both Experiment 1 and Experiment 2 exhibited the same behavior: In the Windows system, the WIM file could not be deleted, with the prompt File is open in system. In the PE system, the WIM file could be deleted, but the system would fail to boot afterward.

Supplementary Experiment Results Analysis

Since all virtual machines in both Experiment 1 and Experiment 2 showed that the WIM file could not be deleted in Windows, with the prompt File is open in system, this indicates that WIMBoot was successfully created in all virtual machines. However, in the virtual machines from Experiment 2, it did not effectively save space.

Questions Raised

Interestingly, in the supplementary experiment, using the PE system allowed deletion of the WIM package that WIMBoot depends on. This contradicts my past practical experience. In my past experience, the WIM package that WIMBoot depends on could also not be deleted in the PE system, with the prompt File is in use by another program. I had to format the C drive in PE before I could delete this WIM in the PE system.

This confusion is resolved later in the text.

The difference between my past experience and this experiment is: In the past, the WIM package I used for WIMBoot was created by backing up a Windows system that had been in use for some time using Dism++. In contrast, all WIMs used in this experiment are original system WIMs, i.e., Microsoft’s initial WIM images that have not gone through the system out-of-box experience.

Experiment Record 2

Experiment Title

Investigating whether having multiple system versions in a self-made WIM causes WIMBoot to fail to save C drive space.

Experiment Hypothesis

Having multiple system versions in a self-made WIM can still save C drive space.

Experiment Design

Use the VMWin10.wim package from the file D:\x\y\Windows\Windowsimage\VMimage\VMwin10_1809.iso to create a WIMBoot in a virtual machine.

  1. Note: VMWin10.wim contains two system versions: Windows 10 Enterprise LTSC_vmtools and Windows 10 Enterprise LTSC_without_vmtools.
  2. Create a new virtual machine vmwimboot_VMWin10_multi. This experiment uses the Windows 10 Enterprise LTSC_vmtools version to create the WIMBoot.
  3. After WIMBoot installation, boot the virtual machine for the first time and check the C drive space usage.

Experiment Results

After WIMBoot installation, the first boot of the virtual machine shows C drive space usage of 2.55 GB.

Experiment Conclusion

Having multiple system versions in a self-made WIM can still successfully create a WIMBoot and save C drive space.

Experiment Record 3

Experiment Title

Investigating whether exporting a specific version image from the WIM in an original ISO, repackaging it with DISM as a compressed image optimized for WIMBoot, can successfully create a WIMBoot and save C drive space.

Experiment Hypothesis

A WIM package optimized for WIMBoot cannot successfully save C drive space after creating a WIMBoot.

Experiment Design

  1. Use the Windows10_22H2_exported_pro.wim (size: 4.45 GB) generated in Experiment Record 1.

  2. Use the DISM command:

    1
    dism /Export-Image /SourceImageFile:Windows10_22H2_exported_pro.wim /SourceIndex:1 /DestinationImageFile:Windows10_22H2_exported_pro_labeled.wim /WIMBoot

    to create a WIM image with a WIMBoot label, Windows10_22H2_exported_pro_labeled.wim, and record its size.

  3. Create a new virtual machine vmwimboot_win10_22H2_exported_pro_labeled.

  4. In the virtual machine, install Windows10_22H2_exported_pro_labeled.wim using WIMBoot. Check C drive space usage before and after booting.

  5. Attempt to delete the WIM in both the Windows system and the PE system to see if it can be deleted.

Experiment Results

  1. The Windows10_22H2_exported_pro_labeled.wim image size is 5.39 GB, significantly different from 4.45 GB, indicating that DISM recompressed and repackaged the WIM.
  2. After creating the WIMBoot using WinNTSetup in the PE system, the C drive usage in PE is 333 MB. After booting the system, the C drive usage in Windows is 9.80 GB.
  3. The WIM cannot be deleted in the Windows system.
  4. In the PE system, if the C drive partition is not opened immediately after booting PE, the WIM can be renamed. If the C drive is opened once, the WIM cannot be renamed.

Experiment Conclusion

A WIM package optimized for WIMBoot cannot successfully save C drive space after creating a WIMBoot.
The experiment hypothesis is correct.

New Discovery: From Experiment Result 4, whether the WIM can be deleted in the PE system is related to whether the C drive has been read in the PE system. Reviewing the supplementary experiment results of Experiment Record 1, I did not open the C drive when entering the PE system at that time, so the WIM could be deleted directly. Therefore, the question from Experiment Record 1 can now be explained.

Experiment Record 4

Experiment Title

Investigating whether using the WIM from an original Windows 10 LTSC 2021 system ISO to create a WIMBoot can save C drive space.

Experiment Hypothesis

Using the WIM from an original Windows 10 LTSC 2021 system ISO to create a WIMBoot can save C drive space.

Experiment Design

Known: The WIM in the original Microsoft system win10_ltsc_2021 ISO contains only one system version.

  1. Create a new virtual machine vmwimboot_win10_ltsc_2021_original. Copy install.wim from the win10_ltsc_2021 ISO and rename it to win10_ltsc_2021_original.wim.
  2. In the virtual machine, install win10_ltsc_2021_original.wim in WIMBoot mode.
  3. Check C drive space usage before and after booting.

Experiment Results

  1. In PE, after installing the system with WIMBoot, the C drive usage is 285 MB.
  2. In Windows, the C drive usage is 10.6 GB.

Experiment Conclusion

Using the WIM from an original Windows 10 LTSC 2021 system ISO to create a WIMBoot cannot save C drive space.
The experiment hypothesis is incorrect.

Experiment Analysis

Since using the original WIM from Windows 10 LTSC 2019 can successfully create a WIMBoot and save C drive space, it is necessary to consider that Windows system version compatibility causes some original Windows 10 WIM files to successfully create a WIMBoot and save space, while others cannot.

Summary

My series of experiments has proven that the original WIM structure of Windows 10 20H2 (including LTSC 2021 and 22H2) — which contains complex update pending states and unoptimized compression blocks — is incompatible with the traditional WIMBoot mechanism. For self-protection and performance, the system automatically replaces pointer files with actual files during the first boot.

Experiment Record 1
https://en.lvlele.top/054-wimboot-experiment-exploration/
Author
Lvlele 吕了了
Posted on
June 4, 2026
Licensed under