I was referring to the cleanup done with dism /online /cleanup-image /startcomponentcleanup and I also mentioned the servicing scheduled task which runs a variation of the same with some limitations.
May you elaborate on the improvements? What kinds of applications or tasks seem to have benefited the most? Any numbers? Benchmarks? What's your CPU Model? _ I haven't noticed anything major myself. But I have a 4 Core / 4 Thread CPU, so I guess that's why.
All leads to same result dism cleanup the components immediately the task wait 10 days (or maybe 30) before running the cleanup disk cleanup runs component cleanup only if it detected superseded updates (in 18362 case, RTM packages are always superseded)
Is it ok to delete these folders in "C:/Windows/Servicing/LCU" ? These seem to be some old CUs (apart from the latest one of course), taking about 2.2Gb of space (127.000 files) These are not cleaned when using system files cleanup. I tried on a VM and it seemed ok (and doing an in-place upgrade worked fine after cleaning these folders), but I prefer asking here just in case
Afaik, should be safe to delete but that's the pool where windows looks for when a reinstall of the cu is needed, when deleted, it will get redownloaded when needed.
My guess is that the updated CPU scheduler is for Ryzen 3000 CPU. I Also noticed some improvements with 19h2 (since 10013) on my r5 3600 compared to 1903.
Then maybe the recommendation would be to disable the servicing task, at least until Microsoft decides to fix its own cleanup mess.
That is the 1st thing I did once this issue became known and went unfixed. I continue to install newest CU's as they are released to the RP ring and I just don't run dism cleanup/resetbase and leave the servicing task disabled.
i9-9940X seems the cores start at 0 running applications instead of using 2 cores 4 and 7 on previous windows
idem, that's what I always did, also never did use Dism for a cleanup/resetbase, and until now never had a problem with CU's on all my installations.
@bonesz @TShadow I think there is something missing here. I have never brought into this discussion the /resetbase switch. The issue which was introduced with 1809 I think and is certainly observed in 1903 is that the /startcomponentcleanup without /resetbase behaves like the /resetbase is configured. The servicing task does not have the /resetbase flag, but would likely behave the same in the recent versions of Windows 10. Regardless, thanks for replying and confirming that servicing task was disabled on your systems.
1809 don't have the issue (aside from some PSFX delta issues on non en-us systems, but was very limited) 1903 have one change (considered as issue) and another issue the issue is, running full resetbase breaks CUs installation completely the change is, CU are direct updates to system packages, which lead to superseding RTM packages thus, when running any cleanup, it simply uninstall any superseded updates (in this case the updates are RTM system packages), and as result any RTM components associated with the removed packages are removed as well this change is not issue itself, but the way they build some release preview CU leads to issue they add some new components to CU, then in later CU they remove them, which break the consistency and lead to missing components issue
I am using 19H2 build 18362.10019 from ISO built from UUP Dump and it installed and updated flawlessly with no errors. This thing don't appear. I'm using es-MX language (perhaps that is the reason)
Now 18363 is just RP little test update, real 1909 is 18362.10019... for now... Soon MS merge Slow ring and RP and 18363 will be fully 1909. Now 18363 is just 1903 with bump delta update.