Cumulative Update KB4469342 Weaves Tortuous Win10 Track
What can one say about a Windows 10 Cumulative Update that goes through four iterations? Quite a lot, as it turns out. In fact, KB4469342 has led to three or more point release values for Build 17763. A quick Google Search on KB4469342 at Microsoft.com produces info for .165, .167 and .168 point releases in the Insider Preview Release Preview program. Woody Leonhard vents some interesting spleen on this CU at ComputerWorld “Win10 Version 1809 gets another jolt, fourth KB 4469342 now runs build 17763.18.” There’s been a lot of recent action on this front, which is why I assert that Cumulative Update KB4469342 weaves tortuous Win10 track.
One Tale On How Cumulative Update KB4469342 Weaves Tortuous Win10 Track
Take my Surface Pro 3 as an example. I’ve been tracking the Release Preview stuff on that PC since the .165 version of KB4469342 appeared on November 16. I’ve read about various graphics driver and other issues for this update in its various forms. I didn’t get bitten until the .168 release appeared December 3.
When I checked WU no new KB4469342 update appeared. It wasn’t until yesterday that I decided to visit the Microsoft Catalog and grab the update for manual installation. But I couldn’t find it until some kind soul named Dave44 offered download links to the x64 and x86 .cab files at TenForums. I had checked various UUP-based download sites. Alas I couldn’t grab those files, despite numerous other reports of success from posters to the afore-linked thread.
The Tortured Track Continues
Once I used DISM to add this package to my online Win10 image things got interesting. After the package was integrated, DISM asked to reboot my PC. Prior to reboot, I saw the spinning balls and the typical “Processing updates” verbiage that counted through to completion. Following the reboot, the OS hung. It presented me with a set of “Choose your default keyboard” selections. When I did, the machine would restart and eventually return to the same screen. This is a so-called “Windows 10 boot loop.” After exhausting recovery options to the resident recovery partition without success, I booted to a Macrium Rescue Media UFD, and performed boot repairs. After the next reboot, Windows 10 went through its OS rollback (“reverting to previous OS version”) maneuvers and I was back running the .167 point release.
Light at the End of the Tunnel?
This morning, WU finally offered me KB4469342 directly for the first time. After a quick image backup and crossing my fingers, I fired it off. To my surprise and delight, it completed successfully all the way through. But when I ran DISM /cleanup-image /startcomponentcleanup on the .168 image it failed partway through. The error message read: “The operation cannot be performed because another transaction is depending on the fact that this property will not change.”
That’s a new one on me, so I looked it up in Microsoft Docs. It occurs when two transactions compete for the same resource, so neither can grab it and complete. I’ve noticed that sometimes running startcomponentcleanup causes two progress bars to appear, one that stops short of 100% and a new one that kicks off and usually runs to completion. Could it be that a second process gets spawned when the first one hangs and that this time they conflicted with one another? Hard to think of another more likely cause here. Very interesting.
Notice the two lines reported for progress. My best guess is that each represents a separate process. Each apparently requests a resource that the other needs to cause the error.
[Click image for full-sized view.]
I’m wondering now if this version of KB4469342 is the one that will go official next week on Patch Tuesday (December 11). There’s still time for another version to make its way into the Release Preview channel before then, though. Can’t ever remember seeing the same KB go through four iterations before. Anybody going for five?