OK, then. I’ve got an eval unit of the sturdy, stellar little Lenovo X12 hybrid tablet PC here in the office. I just had a simply stunning ThinkPad X12 21H1 upgrade experience. I swear to tell the whole truth and nothing but. I copied the self-installing upgrade (.MSU) file over from my production PC, and the whole thing ran to completion in under a minute. Maybe under 40 seconds. It was FAST!
Wow! Truly Stunning ThinkPad X12 21H1 Upgrade
Given that this PC is probably less than two months old, I’d wondered why MS hadn’t offered the 21H1 enablement package automatically. So I decided to push my luck, and use the self-installing upgrade file on that machine instead.
That file comes burdened with this incredibly long name:
A real mouthful, eh? But after right-clicking the name, and selecting Open from the resulting pop-up menu, the results proceeded to astonish and delight. It took less than 10 seconds to install, got to the reboot less than 10 seconds after that, and took less than 20 seconds to get to the desktop once the boot sequence got underway.
I’ve never seen anything like it before. Sure, enablement packages are meant to short-circuit the upgrade process, and speed it through to completion. But gosh, this is ridiculous! I’m pretty sure the whole thing took less than a minute, and perhaps under 40 seconds to complete and let me run the winver command that produced the lead-in graphic for this story. So far, this eclipses any enablement package I’ve ever installed by at least a binary (if not decimal) order of magnitude.
I’ve been dealing with enablement packages for Windows 10 since the 1909 version came out in September, 2019. I’ve never seen anything like this before. Frankly, given that WU didn’t offer the enablement package to the X12 on its own, I was more than a little apprehensive about the resulting outcome. I shouldn’t have worried: it’s amazing!
About three months ago I wrote about the Microsoft SetupDiag.exe tool. In that February 17 post, I explained how it provides info about upgrade errors and gotchas. Although the Microsoft Docs article doesn’t really say so, SetupDiag Illuminates Updates too. That is: you can use it to gather information and intelligence about update errors, failures, and so forth. Because those occur more frequently than upgrades, this capability is perhaps even more valuable.
If SetupDiag Illuminates Updates Too, Then What?
A failed Windows Upgrade leaves a copy of SetupDiag.exe behind, in the $Windows.~BT/Sources folder. Windows Update does no such thing. Thus, would-be investigators should bookmark this link, from whence the latest and greatest version may always be downloaded:
Once you have this tool in hand, open an administrative Command Prompt or PowerShell session, then enter its full path specification. I found one in the Windows.old folder hierarchy on a recently-upgraded Dev Channel test PC, and it produced the following (partial) output:
Run a local copy of the program if you’ve got one, though it’s best to download a current version instead.
[Click image for full-sized view.]
Once SetupDiag runs through all of its log searches and processing rules, it will produce a report that provides the error code and error string (aka “bug check code” and “bug check string,” respectively). This is usually enough information to lead affected users to possible solutions. Just today, in fact, I read a story about update failures for the May 11 KB5003173 that used such data to diagnose possible issues with manual Microsoft Edge removals. It seems that leaving old directories behind will stymie the update. See this Windows Latest story for details.
The Consummation You Should Seek
Be it upgrade or update, you’ll eventually want SetupDiag to show you something like this to indicate a successful outcome:
Once you’ve finished troubleshooting, and fixed things, SetupDiag should tell you something like this.
[Click image for full-sized view.]
This month’s “Patch Tuesday” fell on May 11. Windows versions 20H2 and 21H1 went to Build Numbers 19041/42.985. The delivery vehicle KB5003173 brings critical security updates to users, including fixes for three zero-day attacks labeled “critical:”
CVE-2021-31204 – .NET and Visual Studio Elevation of Privilege Vulnerability. Affects Visual Studio 2019 version 16.0-16.9, .NET 5.0 and .NET Core 3.1 (reported straight from MS).
CVE-2021-31207 – Microsoft Exchange Server Security Feature Bypass Vulnerability. A Microsoft Exchange vulnerability previously used in the 2021 Pwn2Own hacking challenge, attributable to either Devcore or Team Viettel.
CVE-2021-31200 – Common Utilities Remote Code Execution Vulnerability (affects Microsoft’s Neural Network Intelligence (NNI) toolkit, and comes courtesy of Abhiram V/Resec System via Github.
Most discussion of the new CU from security experts strongly recommends installing this update (see, for example, this BleepingComputer item). In addition to the 3 critical items already cited, this update fixes 55 vulnerabilities overall, one more of which is also labeled “critical”. 50 are designated “important” and one “Moderate.” To most people in the know, this makes the update worth installing, even though the three afore-mentioned vulnerabilities are not yet known to be exploited in the wild.
What Else Ya Got?
In the KB overview info, MS specifically calls out the following highlights (quoted verbatim from that source):
Updates to improve security when Windows performs basic operations.
~Updates to improve Windows OLE (compound documents) security.
Updates security for Bluetooth drivers.
That document also mentions security updates to the Windows App Platform and Frameworks, the Windows Kernel, Windows Media, the Microsoft Scripting Engine, and the Windows Silicon Platform. A little bit of everything, in other words. For further details on all 55 items covered in this update, check the May entries in the Security Update Guide from MS.
I concur with the experts: this update is worth installing. Check it out, and make the call for yourself. For the record, I had no trouble with it on any of the half-dozen machines eligible for the update. No issues during install, and nothing noticeable afterwards. So far, anyway…
If you’ve been following my recent adventures with Dev Channel feature upgrades and WU updates lately, you already know I’ve been struggling a bit. Yesterday, when the 21370 build emerged, it installed just fine on my 2018-vintage Lenovo X380 Yoga. Alas, it got stuck at 0% download on my 2012-vintage Lenovo X220 Tablet. I simply couldn’t get WU to download the file. So I built an ISO for 21371 from UUPdump.net. Then I installed it by mounting the ISO, and running setup.exe from its root directory. Only this morning did I notice an in-place repair upgrade gotcha bit me. You can see it in the lead-in graphic for this story.
What Is the In-Place Repair Upgrade Gotcha?
A common Windows 10 repair technique is to run setup.exe from the same version of Windows against itself. Hence the term: “in-place repair upgrade.” This is really running an upgrade from setup.exe inside the next version ISO, but works the same way.
The gotcha, as shown in the story’s lead-in graphic, is that the Feature Upgrade info is absent from Update History. You can plainly see at left that the X220 is running 21370.1. But there’s no record of that install in the Update History at the right. It shows the preceding build — 21364, dated 4/21/2021 — as the most recent Feature Upgrade.
A Return to Normal Behavior Beats the Gotcha
I’m guessing that because Windows Update did not handle that upgrade, it also didn’t record it in Update History, either. Stands to reason, I presume. This is a go-to strategy for me when I cannot use WU to perform a Feature Upgrade. So I’ll just have to learn to live with that missing history entry when I take that alternate route.
Now that I know it works this way, I can understand what’s going on. Hopefully, it will shed some light on an apparent anomaly to other Windows Insiders. I’ll also take this opportunity to make a request of the Insider Team: Please change Update History behavior to record ALL Feature Updates applied to a PC, whether manually or through WU. Sounds easy, but may be a huge PITA. We’ll see how they respond!
Here’s something I’ve not run into before. In trying to update my production PC to KB5001391 I found the download phase of the update stuck at 0% indefinitely. “No problem,” thought I, “I’ll download the .MSU file from the Microsoft Catalog.” Yeah, right!
I guess the Catalog is smart enough to avoid duplicate, parallel downloads. It wouldn’t let me download the MSU file to that PC. So I jumped on one of my test machines, and downloaded the file there. Then I copied it over the network, and installed it by double-clicking its MSU file. This took a while longer than I was expecting (around 5 minutes or so) but it did work.
I can only speculate that WU informs the OS that it’s already downloading the requested KB item on that PC. Thus, clicking the download link from the catalog does nothing. That said, it worked as expected on a different PC, so I found a two-step workaround where a single step wouldn’t cut it. Please keep that in mind if you ever find yourself in this boat.
More Update Weirdness Follows
After the reboot to install KB5001391, I see it is installed in Update History. Nevertheless, Windows Update still shows me it’s available as an “Optional quality update…” (see screencap following).
Even though it’s already installed (and showing in Update History), I get another offer anyway. Sigh.
Of course, I am compelled to click the “Download and install” button to see what happens. When I do that, the Windows Update page comes back in about 30 seconds with nothing to download nor any status or error message to explain itself, either. I guess it figured out the update was already installed, and withdrew the offer. That’s a reasonably intelligent thing to do. Checking Reliability Monitor, I see no error reports about this there, either. So it looks like a clean save, so to speak. I’m glad!