New
#160
I is not a 10GB download size, the download took me 5 minutes. But the files gets locally expanded, thus big size.
EDIT: I know this because I monitored the download folders during the update process.
EDIT2: Based on the ActionList.xml for Build 15042 and Build 15046 the download size were following:
- Build 15042
- 2812282554 bytes
- Build 15046
- 520601464 bytes
That is only 18.5% in size for the "buggy" download vs the normal UUP-ESD download.
You still think it is a bug?
Last edited by slicendice; 02 Mar 2017 at 06:57.
Something seems to have improved:
===============================================================================
Convert CAB > ESD . . .
===============================================================================
===============================================================================
Creating Setup Media Layout . . .
===============================================================================
===============================================================================
Creating boot.wim . . .
===============================================================================
Using LZX compression with 2 threads
Archiving file data: 890 MiB of 890 MiB (100%) done
===============================================================================
Creating install.wim . . .
===============================================================================
Using LZX compression with 2 threads
Archiving file data: 7120 MiB of 7120 MiB (100%) done
===============================================================================
Adding winre.wim to install.wim . . .
===============================================================================
===============================================================================
Creating ISO . . .
===============================================================================
OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Copyright (C) Microsoft, 1993-2012. All rights reserved.
Licensed only for producing Microsoft authorized content.
Scanning source tree (1500 files in 54 directories)
Scanning source tree complete (1707 files in 99 directories)
Computing directory information complete
Image file is 4105633792 bytes (before optimization)
Writing 1707 files in 99 directories to 15046.0.170224-1700.RS2_RELEASE_CLIENTPRO_OEMRET_X64FRE_EN-GB.ISO
100% complete
Storage optimization saved 18 files, 133120 bytes (0% of image)
After optimization, image file is 4109234176 bytes
Space saved because of embedding, sparseness or optimization = 133120
Done.
Press any key to exit.
Great work! I replicated this approach, using DISM to create the ESD files, and have also installed the resulting ISO in a Hyper-V VM. I could not even copy the Download subfolder elsewhere previously, as I always got a PATH too long error when using File Explorer. I did manage to 7-Zip the entire thing but could not extract the files anywhere, due to the same PATH too long error.
The clean install from ISO ran without error and the resulting Windows install also passes sfc /scannow.
EDIT: I don't know scripting, but after reading a couple of command line help screens, I came up with this one-liner which will create the ESD files from all folders beginning with "amd":
EDIT: I was missing one slash in the code above earlier, so I have added it in now.Code:@echo off FOR /D %%a IN (amd*) DO DISM /Capture-Image /Compress:max /ImageFile:%%a.ESD /CaptureDir:%%a /Name:%%a /Description:%%a
Last edited by DonCuthbert; 03 Mar 2017 at 11:12. Reason: added info on automating solution
Awesome, that someone actually tested this and verified it works.
I love that scripting one-liner, that could be the thing we need, but we need to also consider 32-bit Windows. I like to process the xml-files, because there are all the data we need, I just can't wrap my head around shell scripting for this part. This is why I am working on a .NET assembly in C#.
I expect that the original authors of UUPtoISO will find it relatively easy to adapt to the changes. I was just trying to find a way to test it and curious if I could do it all with DISM instead of wimlib-imagex.
It sounds like this is the beginning of "differential download packages", as mentioned in this blog post:
An update on our Unified Update Platform (UUP) - Windows Experience Blog
What ends up in the SoftwareDistribution subfolder appears to be a compilation of files that were downloaded by Windows Update and files from our existing OS build (that were unchanged in the new build). That is why it becomes so much larger than what was downloaded.
This could mean that once UUP is giving a different download to each device (which appears to be as of now, with build 15046) an ISO can still be successfully built from the results, as you have discovered.
I was working with the files from C:\Windows.old\Windows\SoftwareDistribution\Download\[hex folder name]. That is where all the UUP files end up after a successful UUP upgrade.
Great that you tried the DISM method. It is always good to stick to MS default tools.
Yes, I agree that all these updates are moving towards differential updates. This is why it is imperative to be able to process the XML-files. All information is there. If the required files for updates are not located in the HEX-folder, then they are scattered all around the HDD in Windows folder and the XML-files will help located the required files for building a proper ISO.
The Windows.old usually still has the upgrade files after upgrade, but sometimes the update process cleans up the HEX-folder after it's completed, and everything is gone. This is why I always backup the HEX-folder, just in case, before hitting reboot.
Wimlib-imagex.exe is a renamed open source version of imagex.exe, which was the original imaging tool for creating and handling .Wim files. Since it is open source, you can rename it back to Imagex for your own use! wimlib - Main page
Generally DISM has an unnecessarily long-winded syntax, often requiring the console to be widened to see the command on a single line, with a lot of hyphenated switches. Why "apply-image" instead of just "apply", for instance?
Since MS Imagex predated DISM for the handling of Windows image format files I am hard put to understand why the imagex syntax was not adopted when these imaging functions were included in DISM in the early days of Windows 8