Cumulative update December 2020 - KB4592438 Failed to install

I was in a boot loop in 630 so I did the

Download KB4592438 Offline Installer

option and it's all good now. 

Updated to 685

Hi,

I was offline for a day or two so unable to respond earlier. When I originally shared my findings, I used two computers, both on 20H2 19042.630. Once failed as described, but the other succeeded. The difference is in the update history:

1. The one that failed started with a clean install of 2004 (aka 20H1) in September, later upgraded to 20H2 via the Windows update mechanism.
2. The one that succeeded has many years on its belt. I upgraded for 1909 directly to 20H2. As this is a very hold, hardware limited laptop, I was not offered the upgrade to 20H2. So I forced it by creating 20H2 installation media and performed a non-destructive update. An important difference, more about that later.

Regarding the KB4586853 question - not in my case as I'm not on the Windows Insider channel so using only retail builds

Preliminary findings: neither 20H2 19042.630 or KB4592438 have a principle issue as one combination worked. The difference must be in the underlying installation history.

The next step - as we collectively couldn't identify the cause yet, I decided to roll back to 2004 through a backup taken in late October and a bare metal restore. I then applied the upgrades released since then via the Windows update mechanism including the 20H2 upgrade. When applying KB4592438, it failed again with logs pointing again to the dual_wvmbusr.inf component as before.

So I concluded that the only way forward is to progress with a clean install of 20H2 but not at the price of starting from scratch. Unfortunately, the successive applications of patches erases the older restore point so rolling back to 2004 via system restore wasn't possible. Back to the bare metal restore as before, followed by a non-destructive upgrade using 20H2 installation media. When running Windows update afterwards, only a Windows defender update and KB4592438 where offered. As last, applying KB4592438 succeeded! The resulting OS build is now 19042.685.

Preliminary conclusions: KB4592438 issues are not likely caused by a specific OS build and as my example shows, it happens with retail builds.

Neither is 20H2 19042.630 or**KB4592438 failing in general.

In my case, the corruption of the underlying install has been caused prior to applying 20H2 and neither sfc / dism - based repair methods could fix it.  The non-destructive 20H2 update wiped the slate clean and eradicated the the underlying issue. What caused it remains unexplained. But this approach is only possible for those of us who can revert to a version prior to 20H2. Otherwise, it is a destructive re-install. 

So for me, the key issue is no longer KB4592438 but the inability of sfc / dism to restore the integrity of the operating system prior to applying the patch.

Best regards,

Roland

Mark,

glad that it worked for you. It didn't for me and I suspect the explanation is not the difference in online vs offline installers but the installation history of our PCs prior to applying KB4592438. Before I saw your response, I posted the steps I took to resolve it. In that post, I forgot to mention the offline installer but did so in an earlier one. But everyone affected should give the offline installer a try in any case.

Regards,

Roland

Hello,

I've had problems with this update as well. I've tried enabling .NET in Windows features, disabling firewall, clearing Software distribution folder and one other in System32, those didn't help me.

After that I did the mentioned:

sfc /scannow

dism /online /cleanup-image /restorehealth

and added

chkdsk /r

But what most likely helped me was "freeing" disk space. When I was googling for possible issues for this update I've found this thread and some general info that, among others, having not enough disk space might be an issue. I've had plenty so I have ignored that at first, but after a while I have recalled I'm using 4GB RAMdisk and my both Windows TEMPs are redirected to it. My RAMdisk starts with the system and in this case, update was quite big and 2nd part of the update was running after restart, so probably before RAMdisk could start or RAMdisk was too small for this update. I've changed paths for my TEMPs in environment variables (variables TEMP and TMP) to an existing folder on the system drive and it was last thing before a succeeded update attempt.

Since I wasn't making update attempts in between those 4 last mentioned steps I can't say for sure what combination of them helped, but I have a vague memory I've had a quite similar issue few years ago and back then it was due to update being unable to get to TEMP locations due to changed paths - not having enough available space and might have been just the same now.

A tip for MS crew: if the update needs disk space, let it create a folder in Windows folder for its own and delete it after the update is done as last part of the installation, that would make the update independent of TEMPs paths that can be changed to a disk too small or unavailable during boot up.

If it doesn't help you, focus on the error code for solutions connected to the error code instead of solutions to problems connected with the update number. Update is new, most error codes are much older, so it's very likely there's more to find looking for error code.

Best regards,

miauek

I also have the same problem if microsoft cant get it right then please leave it alone. these updates are stopping my work day in day out. i don't want anymore updates i will now be getting apple .