Yes, the past disasters have been kind of a wake-up call for MS. They had to learn the hard way that having no adequate update quality control will backfire eventually.
I can confirm that slow 19H2 18362.10006 cab file does not want to install as well on a .263 system that done componentcleanup, same as .264 cab file. @Enthousiast : My question for you is should I wait for a fix from MS, from your experience with past issues, or should I restore my system to a restore point of the 17th before the cleanup, and proceed from there? It does carry a certain risk as I have stuff installed since then.
This is the first time that msft released an update giving this kind of issue after a non resetbase cleanup, i would roll back if you can, but can't assure it will work.
With the installation of the .263 or .264, do you have the System32\edgehtmlpluginpolicy.bin file that is deleted ? Thanks
Ok, happy to report restore went well, quick enough and back to .239 version, quick update of my softwares, and patch with cab file to 18362.10006, all successful. I'm now a bit worried that automatic maintenance will decide to do some cleanup of say componentcleanup, but I hope this slow ring is unaffected by the bug. I certainly will refrain from any such cleanup in the future. The standalone system restore process is now working properly, unlike with previous windows 10 versions, I accessed it by shift-reboot and recovery options, to boot up into restore.
So, after all the problems with one insider update you went to an even more insider update, from RP to SLOW ring Living on the edge
Same error upgrade 263 to 264 with 263 cleanup not resetbase. Restored using patched 264 image reinstall cover the 263 is ok.
Here's a crazy idea - why don't we just skip .264, seeing as it's so damn problematic for some people? Just sit tight.
we dont know if it's a bug with .263, as i couldnt update to 18362.10006 either, could be something unknown related to componentcleanup, so i did a rollback to restore point, and am now a happy camper
I would go with this explanation: https://forums.mydigitallife.net/threads/windows-10-hotfix-repository.57050/page-428#post-1537424
the new update has amd64_dual_swenum.inf missing compared to .263 (or rather, has it downgraded to the .1 version that comes with the OS and thusly is not included in the update package) An idea is to unpack the update and put the corresponding winsxs folder with the .1 version of the component in the same folder.
FIX FOR .264 NOT INSTALLING: Unpack the update and the attached file in the same folder and use dism with update.mum
Send me the specific list of command you used and your CBS.log, i should be able to diagnose the problem
so what do we have, users fixing MS bulls**t now, botched RP update, technical support politely pointing to "please proceed to report in the feedback hub", at least the bloody system restore finally works now.
Note that you need to unpack any updates using "expand -f:* update.cab target_dir" in commandline, they use a newer CAB format that 7-zip does not understand
I've used DISM /Online /Add-Package /PackagePath:E:\TEMP\update.mum as syntax. (Inside E:\TEMP dir I've unpacked update cab and your 7z file). Anyway, as it seems to be a very common issue, I'll be waiting for MS to fix it.
You installed the RP update, not MSFT, RP still is Insider Preview, nobody forces people to install all that MSFT publishes.