Category Archives: Windows Update

P16 Blows Up, Requires Clean Install

Wow! I took an unexpected detour yesterday. Upon rebooting my Lenovo P16 Mobile Workstation after CU KB5039302, it got stuck in perpetual Restart. After about an hour wasted on the spinning balls and apparently going nowhere, I forcibly rebooted the PC. Bad idea! Long story short: soon thereafter the P16 blows up, requires clean install to restore to working order. Sigh: let me explain…

Why P16 Blows Up, Requires Clean Install

I’ve seen my share of Windows crashes since the 3.1 days. This was one of the scariest. Indeed, it is the first one I can recall where even the Macrium Reflect Rescue Media couldn’t bring the system back from the dead. I could boot up the restore environment but the trackpad was MIA (fixable with an external mouse) as was the external NVMe drive where the restore image resides (not fixable at all).

So I downloaded a fresh Windows 11 23H2 ISO, turned off secure boot, and fired off a bootable UFD created using the MS MCT. That got the PC running again. But I still found myself woefully short of device drivers. A quick install of Lenovo Vantage and a set of updates later, that defect was remedied: I went from 20-odd “Unknown devices” in DevMgr to zero (0). Good!

Right now, I’ve just reinstalled Macrium Reflect, and am rebooting to be able to make a snapshot of the rebuilt system (and create new Rescue Media). After that I’ll try the lone pending update for the P16 and see if it finally goes through. My best guess is that something went sideways after that update. Indeed the P16 automatically rebuilt its BIOS when I did finally get the machine to reboot after the CU hung on me. So whatever affected the system, it was at a pretty low level.

Fingers Crossed, I Try Again…

With a new rescue disk, and a fresh image backup demonstrably at hand (see next screencap), I once again tried CU KB5039302.

P16 Blows Up, Requires Clean Install.exp-list

Today (6/26) there’s a fresh backup available!

Downloading takes some time . . . but eventually, it gets to installing . . . and about 20 minutes later (!) I’m ready to restart again,  with appendages overlapping for as much luck as I can get. So I fire off the restart and watch it count down (or up) . . . reboot . . . restart . . . spinning circle . . . and a second restart?! . . . SUCCESS!!!

That was officially weird, and I’m glad it’s behind me now.

The News Catches Up

This morning, I came across a story about KB5039302 at WindowsLatest. The title says it all Windows 11 KB5039302 breaks PCs, MS pulls the update. It specifically mentions the very “boot loop” that I describe earlier, and ties to nested virtualization. (I’m a heavy user of Hyper-V VMs on that PC so: no joke!)

The recommended fix is what I guess I should’ve done, rather than a clean install (though without trackpad drivers or access to USB-attached NVMe drives, things were challenging):

You must use the WinRE page to access the troubleshooting tools, remove the update, or do a clean install.

OK, now we know. But here in Windows-World, there’s always something around the corner looking to bite  you if it can. It certainly bit me! But that’s what Windows Insiders are for, I think . . .

Concluding Unscientific PostScript

I also understand now why the initial application of KB5039302 blew up on the P16, but why the post-clean-install upgrade worked. In the former case, Hyper-V and nested virtualization was already present and active. In the latter case, I didn’t enable Hyper-V and VMs until AFTER I’d applied the update. Turns out that was exactly the right thing to do. Better sometimes, indeed, to be lucky than good!

Facebooklinkedin
Facebooklinkedin

Forced Win10VM Upgrade Gets Stuck

This is pretty strange. I checked in on one of my Windows 10 VMs this morning, and found WU stuck part-way through a Windows 11 upgrade. This popped up, courtesy of toggling the familiar “Get the latest updates…” option in Settings > Windows Update. Alas, this forced Win10VM upgrade gets stuck. I’m trying some things to undo that state. Bear with me, as I report on what things I try…

Before I start introducing repair maneuvers and upgrade counters, let me explain I’m running this VM deliberately to check and test Windows 10 stuff.  Thus, I have ZERO desire to upgrade it to Windows 11, even though I know full well that I could if I wanted to.

Fixing Forced Win10VM Upgrade Gets Stuck

The excellent and usually reliable batch file from TenForums.com “Reset_Reregister_Windows_Update_Components….bat” returned WU in the VM to a normal appearance. Then I ran “Check for updates…” While watching the sliding balls, I wondered if I’d find this VM in the same situation as before. Not yet: it offered a routine Defender update, plus KB5037849. I let things roll.

Interesting results ensued. Defender download threw a 0x80070643 error.  A quick jump into Windows Security > Virus & threat protection > Check for updates showed that everything was already up-to-date. Subsequent “Retry” attempt dropped the same error anyway. Odd…

Back in WU, KB5037849 went through download and install. Eventually it got to the “Restart now” button, which I pressed. I’m pretty sure the Security Update error was bogus because of internal status in Windows Security, so off it went…

Beta Channel Sign-Up Effected!

When I got back into Windows Update, I found a successful transition to the CU, but an error report on the Security Update, to wit:

But because another visit to Windows Security showed the same update was still current, I’m seeing this as a Windows Update problem, not as an issue with security updates on this VM. So I jumped over to Windows Insider Program and signed up for the newly re-opened Beta Channel for Windows 10. Indeed, that was the whole reason I started down this rockier-than-expected road.

Then I restarted again, to see what would happen on the next go-round. WU came back clean, and I’m opted into the Beta Channel. Success, but without some oddities along the way. Another magic day in Windows-World…

 

 

Facebooklinkedin
Facebooklinkedin

IPRI Hits Production Windows 11

I’m not sure exactly how long this has been true but Copilot agrees with me that it first appeared in 23H2 Build 22631.3447. Release date for that build: April 9, 2024. It had been available in Insider Previews since earlier this year, but this is when in-place repair install (IPRI) first showed in a production release. Now that IPRI hits production Windows 11, it’s ever so much easier to let WU provide the files to make that happen. Good stuff.

What IPRI Hits Production Windows 11 Means

Before this facility appeared in various Windows 11 versions, the only way to conduct such a repair was to use UUPdump.net to build an ISO that matched the current installed Windows version, then mount same, and run setup.exe from its root-level folder (see red-boxed item in the screencap following):

IPRI Hits Production Windows 11.setup.exe

The old-school IPRI method requires an ISO for the same version.build that’s running, then launching setup.exe from its root-level folder.

Now, with this change you need only navigate to Settings > System > Recovery, then click the “Reinstall now” button as shown in the lead-in graphic. Windows Update does the rest. It does take a while (50-60 minutes in recent test runs for a ComputerWorld story) but that’s because it has to download all the component files, then build and update an ISO. Adding install time to the time UUPDump.net takes to create the ISO, it’s pretty much a wash.

And again: it’s ever so much more convenient and automated. Big win for Windows users everywhere. Thanks, MS!

Facebooklinkedin
Facebooklinkedin

22635.3430 Post-Reboot Black Screen Fix

Here’s an interesting item. Yesterday was Patch Tuesday for April. As per normal due diligence, I updated my various Windows 10 and 11 PCs. When I tried to remote into the production PC (ThinkPad P16 Gen1 Mobile Workstation) it showed me a black screen. Fortunately, I was able to come up with this 22635.3430 post-reboot black screen fix: Ctrl+Alt+Esc launched Task Manager. Then I was able to run Explorer.exe. After that, the desktop and all came up normally. Weird!

After the 22635.3430 Post-Reboot Black Screen Fix…

The system seems to be working properly. Nor is reliability monitor showing an error in its output for today. Whatever caused this strange pause in screen output during startup seems to have been benign (no errors) and purely transitory (I can’t make the system do it again).

After I did get to the desktop I installed a handful of winget updates, plus Intel DSA updates for Bluetooth, Wi-Fi and Iris Xe. This made another reboot mandatory. After that second reboot, all worked as it should have. So whatever caused my initial black screen was apparently a one-time hiccup.

The DISM /cleanup-image Report

I try to run dism /cleanup-image /analyzecomponentstore any time I install a CU. This time it quite startlingly shows 16 (!) reclaimable packages. Based on recent experience I’m guessing 13 of them are bogus (that’s a recurring number). Check it out!

What’s more the cleanup fails with error 6824 “another transaction is depending on the fact that this property will not change.” I’ve learned this means it’s time for a repair install based on recent experience.

Methinks something went awry with the latest CU KB5036992. I wonder how many others will report similar difficulties. In the meantime, I’m off to fix this, and move on. This time, I will have to use UUPDump.net, too. Sigh. The new way in Canary and Dev versions “Fix problems using Windows Update” is ever so much easier…

Note Added +3Hrs: IPRI Does It!

An indeed, though it takes quite a while to work through all the steps, building an ISO for 22635.3430 from UUPDump.net, mounting same, and running install from setup.exe gets rid of the high count for reclaimable packages (including “the bogus 13”). Here’s what I get from
dism /online /cleanup-image /analyzecomponentstore
after in-place repair install and its final reboot:

22635.3430 Post-Reboot Black Screen Fix.IPRI

After the IPRI, reclaimables drops to zero.
[Click image for full-size view.]

Fixed! Now I need to figure out how to report this on Feedback Hub.

Facebooklinkedin
Facebooklinkedin

KB50001716 Is Puzzling

OK, then. I was reading Martin Brinkmann’s post to gHacks this morning. It’s entitled “Microsoft’s sneaky KB5001716 Windows 10 update pushes Windows 11.” I don’t think my production PC qualifies, because its Intel SkyLake i7-6700 falls outside the range of supported CPUs. So I went looking for it, and learned some useful things. Let me share them with you…

Why KB50001716 Is Puzzling

First off I went to look at WU Update History to see if KB5001716 was present (or absent). I quickly realized that reading the whole WU history was more than a little taxing on a machine that’s been running Windows 10 since 2016.

So I turned to PowerShell where some operating on the Get-WUHistory command seemed like a good idea. When I figured out my Update History had 528 entries, that idea seemed even better. You can view the update history by creating a variable named $history, like so

$history = Get-WUHistory -last 1000

This grabs up to the last 1000 entries in the history records and assigns them to the variable $history. If you look at that output it’s kind of hard to ingest from Windows Terminal. It makes more visual sense if you look at it this way:

$history | sort date -desc | Format-Table Date,KB,@{l=’Category’;e={[string]$_.Categories[0].Name}},Title

[Note the preceding lines are a single PowerShell command string. If you want to try it, cut’n’paste into a text editor and make sure it’s a “one liner” before pasting into PowerShell. This produces output that looks like this:

KB50001716 Is Puzzling.table-output

Table format is more readable, but still too much to take in.
[Click image for full-size view.]

So I changed up the command string to write it to a file. That required appending the following string:

> i7wuhist.txt

The > symbol redirects the output, and the filename resides in folder context in which PS runs. Working with a file I was able to figure out the following:

1. I had no instances of KB5001716 in there anywhere
2. There were a total of 528 entries in that file.

I also concluded that my PC’s failure to meet Windows 11 hardware requirements probably meant that the upgrade offer (and indeed KB5001716 itself) were not forthcoming. Good to know, and I learned some interesting stuff along the way.

Facebooklinkedin
Facebooklinkedin

Canary 26063 Throws Install Error

Oh well: it happens sometimes. One of my two test PCs on the Insider Preview Canary 26063 throws install error right near the end of the install process. It’s one I’ve seen before –namely:

Failed to install on ‎2/‎22/‎2024 - 0xc1900101

It’s something of a grab-bag error in that it can come from insufficient disk space, driver conflicts (esp. from external USB devices), an out-of-date driver on the target PC, AV conflicts, and more (see this MTPW Backup Tips note for all the deets).

When Canary 26063 Throws Install Error, Then What?

I’m trying a two-pronged strategy this morning. First thing is a simple retry. And when I ran that option in WU, it thought for a while, then jumped from the download phase to the GUI install phase. So obviously, it checked over yesterday’s UUP downloads and found them satisfactory. Right now, WU is 49% into installling 26063. Here’s hoping that works.

But on the other prong, I’m downloading the 26062 ISO from UUPDump.net. I’ve observed that when a WU-based install fails, sometimes a local install using setup.exe from a mounted ISO will work. It may also provide more useful error messages in local logs should it fall over near the end of the process yet again.

FWIW, this seems to be a pretty substantial update, too. And indeed on the other test PC — the one where the upgrade worked –it  says 24H2 in the Winver window. I guess that means MS is floating Windows vNext to Insiders right now.

Lookit that! 26063.1 says “Version 24H2.” It’s arrived…

More to Follow…

Now, the WU install is at 64% and UUP is building images and stuff for the upcoming ISO file. Based on yesterday’s experience, this will still take a while. I’ll jump back in and update when it gets wherever its going. Stay tuned!

Facebooklinkedin
Facebooklinkedin

Repair Version Feature Update

Hey! I noticed something new and interesting yesterday. When MS pushed a feature update into the Beta Channel, it included a “(repair version)” label. That’s why I’m representing this as a repair version feature update, based strictly on the MS presentation in WU (see lead-in graphic above). Uncharacteristically, MS says nothing about this in its 22635.2921 announcement. It does say “This update includes a handful of fixes to improve overall reliability” under the General heading, though.

Is Repair Version Feature Update A New Thing?

Hard to say, except by watching to see if this falls into regular usage, or comes and goes without re-use. I think it’s a useful label because it designates the feature upgrade as bug-fix and reliability oriented.

As things played out on my Beta Channel Test PC (2018 vintage Lenovo X380 ThinkPad Yoga), it was a pretty lightweight feature update. The download and GUI install portion finished in 2-3 minutes, and the post-GUI/reboot phase took less than 2 minutes. The changelog is virtually non-existent. The only other item not already quoted reads:

[Input]

  • Fixed a high hitting tabtip.exe crash which was impacting the ability for some Windows Insiders to input text.

It’s always fun to catch MS slipping new terminology into the mix. It’s impossible not to wonder if it’s going to stick. Stay tuned: I’ll keep an eye out and let you know if and when it pops up again.

Facebooklinkedin
Facebooklinkedin

Windows 10 Lifecycle Changes

If I’m reading its HTML metadata correctly, Microsoft updated its Lifecycle FAQ = Windows document yesterday (December 5).  That’s when they added information about Extended Support Updates (ESUs) beyond the Windows 10 EOL date of October 14, 2025. ESU is a paid-for kind of support that allows licensees to get updates even after that cut-off date. Let’s explore what these Windows 10 Lifecycle changes  could mean.

Exploring Windows 10 Lifecycle Changes

For previous versions of Windows (e.g. 7) MS offered ESUs only to MS customers with existing paid-for support or licensing agreements. If I’m reading the afore-linked FAQ’s text correctly (see lead-in graphic), ordinary users (“individual users”) will also be eligible to pay for and receive these updates. That should be interesting.

I asked Copilot this question “How much did MS charge for ESU on Windows 7?” Here’s how it answered (superscript numbers 1-3 link to the sources for this information):

According to the web search results, Microsoft charged different amounts for Extended Security Updates (ESU) for Windows 7 depending on the edition and the year of purchase. For Windows 7 Professional, the ESU prices were $50, $100, and $200 per device for the first, second, and third year respectively1For Windows 7 Enterprise, the ESU prices were $25, $50, and $100 per device for the same period1However, some customers could get ESU for Windows 7 for free through Windows Virtual Desktop or other support contracts23.

Given that EOL for Windows 7 was January 14, 2020, let’s factor in some inflation. That makes it exactly 5.75 years between that date and the Windows 10 EOL. Using a low-ball average inflation rate of 2.5% over that period means adjusting the foregoing numbers by 14.4% or thereabouts. That means $50 becomes $57, $100 → $114, $200 → $228. You can do the math for the rest (but I think the Professional prices are the ones to go by).

Are They Ready to Rumble?

I’m forced to speculate that MS is adding individual consumers to its upcoming ESU coverage because they believe they left money on the table during the Windows 7 extended service period. This essentially brings businesses and users who are willing to pay for coverage, but who don’t have a licensing agreement or equivalent already in place with MS. It could easily be as big a revenue stream as the covered Windows 7 population was when EOL rolls around.

Inertia is indeed a strong force in business affairs. And sometimes, smaller businesses — especially sole proprietorships — can strongly resist change. This should be interesting to watch and try to figure out. I’m not sure if I should be impressed or appalled. Stay tuned: I’ll tell you…

PS Thanks to Sergey Tkachenko at WinAero.com for bringing this to my attention. I figured out the date info on my own…

Facebooklinkedin
Facebooklinkedin

WU Finally Proffers 23H2

OK, then. The wait is over — for the Ryzen 5800X system anywho. I just checked WU on that machine and got an offer. Now that WU finally proffers 23H2 on that system, it’s kind of an anticlimax. Took less than 3 minutes to download and install, reboot and everything.

As WU Finally Proffers 23H2, I Install It!

I’ve been deliberately waiting on this offer, to see how long it would take for WU to make it happen. Now I know: this time, it took 9 days after the original info came out for WU to come knocking at my door. One wonders, sometimes, how these things happen. I’m just glad the new release is finally arriving through “official channels.”

On my “big beast” test PCs — most notably, the P16 and P1 Gen 6 Mobile Workstation Thinkpads — I wasn’t inclined to wait. I simply grabbed the MSU file that Shawn Brink posted at ElevenForum.com, and had at it right away. I could be patient where the Asrock B550 (Ryzen 5800X, 64 GB RAM, 1 TB SSD) and Dell Optiplex 7080 (11th-gen i7, 32GB RAM, 1 TB SSD) were concerned.

So, whatever the holdup may have been, it came off sometime in the last 24 hours (I last checked these PCs in the morning yesterday, so it could be more like 30 hours, but no more). And now, things are upgraded.

Known Issues Sez…

I’d wondered if the BitLocker or Intel Smart Sound Technology issues on the Known Issues list might have been involved. I see they’ve both been “Mitigated.” But neither has been updated since October 31. So neither is an obvious culprit for the hold on those two PCs, either.

Sigh: I may never know what slowed the offer, or what eventually made it come through. Can I live with that? Heck, yeah! That just the way things sometimes go, here in Windows-World. By now, I’m used to it…

 

 

Facebooklinkedin
Facebooklinkedin

Phased Windows 11 23H2 Rollout Bites Hard

It’s another never-ending story. Earlier this week, I found myself wondering why none of my 5 physical Windows 11 production PCs, nor either of my two Windows 11 production VMs, were getting any WU action for the 23H2 eKB (enablement package). Then I read from various sources (see this WindowsLatest item, for example) that it’s arriving as a “phased rollout.” Given my personal experience (0 for7) I must observe that the phased Windows 11 23H2 Rollout bites hard here at Chez Tittel. Go figure!

If Phased Windows 11 23H2 Rollout Bites Hard, Then…?

There are other ways to force the KB5027397 eKB onto a production Windows 11 22H2 system running 22621.2506. This makes the transition to 22631.2506 and changes the version number from 22H2 to 23H2. You can read all those details in Shawn Brink’s helpful ElevenForum post “…Enablement Package for Windows 11 version 23H2..” More important, there’s a link there to an MSU (Microsoft Update, with installer) file for X64 and Arm64 PCs. I’ve used it on three of my production PCs and both VMs now, so I’m convinced it’s legit and I know it works.

But gosh! I always wonder why MS makes us wait for updates to rollout. The official line is they’re being conservative and taking no chances on incurring errors or issues on existing Windows 11 PCs, especially older units. But with two of my population less than a year old, both running pretty beastly workstation grade configurations, I’m puzzled by their hold-backs.

On the two PCs that haven’t yet updated (a 2020 vintage Dell OptiPlex 7080 with 11th-gen i7, and a 2021 vintage Ryzen 5850X) I’m deliberately waiting. I’m checking daily to see when WU will “make the offer.” So far, nada. Stay tuned…

Facebooklinkedin
Facebooklinkedin