this thing happens here too(i wait for six hours,and nothing happens,frozen in 60%),after install all kbs and start both the disk clean as startcomponentcleanup freeze in 60%, I have to finish the process and start again to work, it just happened now after these updates from Tuesday.
Is this on a HDD? Throw in an SSD instead. Also, to make my wims smaller, I compress them during export: Code: Dism /Export-Image /SourceImageFile:old.wim /SourceIndex:1 /DestinationImageFile:install.wim /compress:maximum
Nice...but how should this help ? Had myself the issue that i tried to run a system file integrity check via: Code: sfc /scannow that got stuck at 100%. AND THIS HAPPEND ON A SSD . Needed short time to get there, but then it stopped. TiWorker.exe was showing as busy...but nothing further happend, so i had to kill it manually. Tried rebooting with no avail. Then googled the problem and found a recommendation to run a component store restore via: Code: dism /online /cleanup-image /restorehealth After that the system file check went smoothly and stated, no violations found.
I'm running imagex in Windows 7pe to capture an image of Windows 8, I'll have to use the win8 pe or can I continue to use the win7pe for capture image of Windows 8? Thanks
Should work fine. I would recommend using WinPE4 anyway as WinPE3 used to flip drive order with some chipsets...
So it seems there's enough to test, this is where I'm now: (1) Installed a fresh W8 in audit mode (the slightly modified .wim, with NetFX3 added, most appx aps removed) (2) Did an update run (everything OK, including Net3 updates), rebooted, did another run, rebooted. (3) Made a TrueImage backup of the partition (so that's *before* Generalize/Shutdown system). This way, I can do two tests: (a) Capture the .wim from PE *without* cleanup run, and (b) *with* cleanup. This way I can compare once and for all if the long wait is worth it or not. (4) After the two tests, I'll have a "quick and large" .wim, and a "slow and small" one. Details will follow after the tests. Also, I want to test if I can use the new wim as a base for new updateruns. Still have to find out about the rearm stuff, though... (Actually, for the tests I'm using some wonderful tools: The new Win8PESE, running TrueImage, thanks to the nice script by a2CD, also JFX's wonderful WinNTSetup). Thanks to them, and everybody here at MDL for your kind assistance!!!
Sorry, another reply from myself. I'm busy testing all kinds of scenarios, right now my testPC is running the full cleanup once again (this time around I'm timing it, so I don't have to wait for nothing next time). Thought about this: (1) Maybe exclude update KB2821895 (which seems to be responsible for the new cleanup method). Actually, this is not a good idea, because the whole point of my update run is to have an up-to-date system... Also, reducing the .wim is kind of nice, too (still have to check how big the differences are in filesize of the .wim and free disk space after install) (2) Try dism /online /cleanup-image (without the "/startcomponentcleanup" part). Doesn't work. (3) Accept the long waiting time. This might be the best solution At least now I know *what* I'm waiting for (reducing the wSxS folder), next time I'm not going to use the loud (fan) PC for the updaterun, but a silent laptop. EDIT: .... and now I'm utterly confused. This time around, the cleanup finished in 10 minutes.... WTF???!!
Thanks redroad, but for me, full, up-to-date .wim files are the best. I'm just trying to understand what's going on with /startcomponentcleanup. Last test, it finished in about 15 minutes (instead of 3 hours). Nice? Of course, but not knowing *why* still drives me crazy (and make me worry for the next time, no way of telling how long that will take if I don't know what the heck is going on).
One thing that I noticed, that with KB2821895 installed, the old files are reduced to diffs only on Win8 PRO and not on Win8 enterprise. On 4 machines, only on the one with win8 pro command "dism / online / cleaning-image / startcomponentcleanup" took very long time and after that, the old versions of files had reduced size. On other three machines with win8 ent, the command ran fast and old versions have the same size as new version
As I said in my original post in the Windows 8 Hotfix Repository thread, and quoted on here by abbodi1406, it should be quicker after the first time you run it as it has already done its work on the files. I guess subsequent times it just does a check. It's not something that is intended to be really fast, it favours reliability over performance. If it stuffs up the delta for a file, and that delta is then used, the resulting file will be corrupted and therefore useless. I believe it does do a CRC check which will prevent the file from being active and subsequently meaning whatever required the earlier file to be used will also fail.