DISM creates thousands of empty SWM files when splitting a modified install.wim
Asked by
MellowCedar47
I'm adding drivers for a new machine model to the install.wim used by an unattended Windows 25H2 installation. The source media contains install.swm and install2.swm, so I first use DISM /Export-Image to combine them into an install.wim. I mount that WIM, use /Add-Driver to add drivers from a folder previously prepared with /Export-Driver, and then unmount it with /Commit. Everything works up to this point.
The problem happens when I run /Split-Image again because the modified WIM is larger than 4 GB and the installation USB uses FAT32. DISM fills the destination directory with tens of thousands of zero-byte installxxxxx.swm files and eventually fails with error 13. The DISM log reports: "WIMCloseWIM:(3909) -> Fail to flush file buffers." There is plenty of free space, the destination is writable, and real-time Defender scanning is disabled. I reproduced the problem on another freshly installed computer as well.
Has anyone encountered this, or found a reliable way to split the modified WIM?
Answers
Another approach is to leave the drivers outside the WIM and have Windows Setup or a deployment task sequence install them. That avoids repeatedly merging, mounting, committing, and splitting the image, and can make the deployment easier to maintain.
Reply to this answer
Try splitting the image to a normal local folder on the system drive rather than directly to the USB or another removable destination. Once DISM finishes successfully, copy the resulting SWM files to the installation media. That separates any DISM or filesystem problem from the USB device itself.
Reply to this answer
The FAT32 requirement may be the main thing to reconsider. Modern systems can usually boot Windows installation media from NTFS, so formatting the USB as NTFS and copying the installation files over may avoid the need to split the WIM entirely. If a particular older firmware has trouble booting NTFS, a USB creation utility can usually work around that.
Reply to this answer
For a repeatable build, consider scripting the whole image process from an untouched Microsoft WIM. The script can copy the base image, apply drivers, language packs, updates, and customizations, then export the final image. Rebuilding from a clean source is often more reliable than reopening an already modified WIM each time.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions