I’ve been futzing around with my wife’s old mini-ITX PC for some time now. It’s got a 2011/2012 vintage Jetway NF9G-QM77 motherboard that’s now failed to upgrade from 1909 to 2004 on four separate attempts. First attempt was through Windows Update. Second attempt via an ISO built using the Microsoft Creation Tool (MCT). Third attempt used a customized ISO built for Build 19041.331 via UUPdump.ml. And the fourth and final attempt employed the Windows Update Assistant. All attempts failed at 92% complete in the post-GUI install phase. I’m still trying to figure out exactly what’s causing my problem, but I’m pretty sure it’s a device driver that’s either not available for 19041.450 or that doesn’t work with Version 2004. But that’s not why I’m writing this story.
KB4023057 Adds Zombie Upgrade Behavior
I knew I was going to have problems with the install, but I was expecting it to ask for a restart to fire off the post-GUI install process. That would have given me time to make sure I had all drivers ready, all USB devices unplugged, and run quick system file checker (SFC) and DISM health checks before turning PC control over completely to the Windows installer.
But this time, Windows didn’t ask me to restart the PC. It restarted on its own — and of course, about an hour later there it was: stuck at 92% again. I had no idea why this happened until I read Martin Brinkmann’s story about KB4023057 over at Ghacks.net. In that story, entitled Microsoft pushes out KB4023057 again to enforce Windows 10 upgrades Brinkmann makes it clear that this update not only forces the upgrade on as-yet trailing PCs, but that it also automatically restarts that PC once the GUI-phase of the install process completes. This is an important tidbit of info that the KB support note itself fails to disclose, in fact.
All of this explains why my wife came to ask me on Friday evening why her machine was stuck at 92% complete on an upgrade I’d fired off four or five hours earlier while she was out running errands. Silly me! I figured the upgrade would complete the GUI install, then restore access to the PC waiting for a manual restart to tackle the second and troublesome post-GUI install phase. This time I was wrong. So I powered down the PC, then started it back up. I already knew from experience with the three prior failed upgrades that this results in a successful rollback to 1909. And luckily for me, I gave her a working PC back in about five minutes.
A Plea to MS: Let Users Manage Restart!
Until I saw Brinkmann’s story, I remained puzzled as to why this latest upgrade attempt restarted itself upon completion of the GUI install phase. KB4023057 makes sure this happens within the limitations of usage hours. Had I known that I wouldn’t have fired off install at all until that night, as we all headed off to slumberland.
This is the first whiff of the old “forced upgrades” that prevailed in the early days of Windows 10 I’ve experienced in some time. If anybody at MS is reading this, I hope you’ll hear my plea to let the users retain control of when (and if) restart happens once the GUI phase of the upgrade is complete. Such control makes it ever so much easier to make sure the target PC is properly prepared for the post-GUI install phase — not to mention assisting in the even-more-important goal of maintaining domestic tranquility. But that’s the way things go in Windows-World, at least sometimes here at Chez Tittel …
Author: Ed Tittel
Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.