Last Thursday, I downloaded and installed a new Preview CU for Windows 10 — namely KB55053634. After lunch Friday, I finally got around to rebooting to complete that process. Eventually, it succeeded. But first, just to make things incredibly exciting KB5053634 kills mouse, keyboard — my vital USB peripherals — dead. Here’s the story of what I had to do to bring those devices back to life, and actually log in to Windows 10.

KB5053643 Kills Mouse, Keyboard: Now What?

Because I couldn’t get past the lock screen without a valid input device, that turned out to be a little more vexing than one might guess. So first, of course, I rebooted again. Still no joy: the keyboard didn’t respond to keypresses (a good test on my Comfort Curve 4000 is to toggle the Function Lock or Scroll Lock keys because those also toggle handy little green indicator LEDs). Nor did a mouse click open the PIN input box as usual.

So I tried again. Still no dice. Then I thought: “maybe the device needs a cold, hard boot?” That means powering off the PSU, waiting 1-2 minutes, powering back up, and pressing the power button. And indeed, that did the trick. Once I went through that maneuver, the hardware got completely reset, reinitialized and enumerated. It was enough to restore my key USB peripherals to working order.

What (Would Have Been) Next?

If the cold boot or hard boot didn’t work, I’d have had to jump into UEFI, turn off Secure Boot, and then target bootable repair media to get something running on that PC. I’ve done it many times before and will no doubt do it again. But hey: I was glad not to have to do it this time. Cold, hard boot did the trick.

Makes me feel like I dodged a bullet. Remember to give that a try if you find yourself bereft of mouse and/or keyboard after installing a Windows update or upgrade. If you’re lucky like I was, that will bring the USB drivers back into play, and let your PC get back to work. Cheers!

Whoa! In the realm of Windows Insider Preview upgrades, sometimes you win and sometimes you lose. This time around — starting from Build 27783 — I found myself on a long, hard 27788 upgrade road for this latest Canary Channel version. When I tell you what happened, and how I surmounted the obstacles on that path, you may be able to save yourself some unnecessary time and effort.

To begin with, what I lost on this upgrade road was time. I spent most of yesterday afternoon going through various motions to try to get the Insider Preview for 27788 and a companion KB5053390 (CU for .NET Framework…) up and running. All such attempts, alas, proved fruitless.

Traversing That Long Hard 27788 Upgrade Road

Getting to the state depicted in the lead-in graphic — showing that the Lenovo ThinkPad X12 Hybrid Tablet is up-to-date in WU and running Build 27788 in Winver — took some doing and some time. In fact, it wasn’t until I read about a workaround in an ElevenForum post from Russian user @Dronix that I made any real headway. Along the way, each update/upgrade cycle took about 1:10 (70 minutes) to work through.

I’ll deliver a recitation of what I tried that didn’t help my problems. I am also speculating when I say this, but I believe one can’t upgrade to 27788 until KB5053390 for .NET completes successfully. There may be dependencies in the upgrade that need the previous CU to complete successfully. And indeed, once I did that, the upgrade went through without further issues.

Here’s my list of failed strategies:
1. Simply retry the failed KB or upgrade item.
2. Run Eleven Forum’s Reset_Reregister_Windows_
Update_Components.bat from this Reset WU tutorial
3. Run the built-in WU Troubleshooter

What Worked: DISM-GUI 1.3.1.02

Turns out there’s a German software tool named DISM-GUI that lets one install KB .cab files from failed installations. You have to know the name (a partial name will do) of that file to provide it as a target. The afore-linked Eleven Forum thread identifies it, and it includes the KB number as a sub-string. Using Voidtools Everything, I found it immediately (search string *KB5053390*.cab). For the record, the filename is:

Windows11.0-KB5053390-x64-NDP481.cab

Click on the box in DISM-GUI that reads “CAB Install” (lower left) and the program will prompt for the file location. You can get that from Everything, then left-shift click and use the “Copy as Path” option (you’ll have to delete opening and closing quote marks).

This opens a Command Prompt session and uses DISM to install the package for you. Unlike the WU driver install, this actually works. And it takes less than two minutes to complete. Then, when you’ve got the CU installed, the follow-up upgrade to 27788 works, too.

TLDR: Possible Problems with 27788 Are Fixable

If you read through the whole Eleven Forum thread about 27788, some posters were able to install KB5053390 and the 27788 upgrade without any difficulties. Numerous others — myself included– got exactly nowhere until they used DISM-GUI to get over the KB5053390 hump.

Should you find yourself in the same boat, you can go straight to the workaround using that tool, and avoid the hours and hours of thrashing about I went through yesterday. Why not learn from my experience, instead of repeating that misery?

Providing such info explains why I write this blog. It also explains why I expect lifetime employment doing that kind of thing here in Windows-World. It’s always something…

But Wait! There’s More… (Added Jan 7)

When I logged into the X380 and the X12 this morning, KB5053390 again showed up as needed. And again, a regular WU install failed. So this time, I fired off DISM-GUI taking the left-click “Run as administrator…” option. Apparently that did the trick. Here are some screencaps along the way:

Between the 2nd and 3rd screencap, I ran DISM-GUI again (as admin) and it showed a successful conclusion at the command line, then reboot with successful update there after). Once I rebooted the system and it worked through the rest of the process, I got the 3rd figure above from WU. Gadzooks! I hope it’s finally over…

I’ve seen it before. And I’m grimly resigned to seeing it again. Every now and then, a Windows PC has issues with some Windows Update (WU) item. Mostly, though, I’ve seen this with Cumulative Updates (CUs) rather than security, MSRT, or servicing stack items. Indeed, this very situation popped up on a brand-new review unit from Lenovo following Patch Tuesday this week which brought KB5050009 to Windows 11 24H2. On all four of my other production level 24H2 PCs, no problem. On the ThinkCentre M90a (see yesterday’s intake review) however, I spent some time overcoming KB5050009 update errors. Let me explain…

Escalating Steps When Overcoming KB5050009 Update Errors

I’ve been through this kind of thing often enough that I’ve got a series of steps I follow when a WU update fails and throws an error. Here it is:

1. Write down the error string ( 0X800F081F in this case)
2. Run the WU update again (helpfully, it offers a “Retry” button)
3. If it fails, note the error message. Record only if different from 1.
4. Download and run the batch file from Eleven Forums Reset Windows Update tutorial (Batch file named Reset_Reregister_ Windows_Update_Components_for_Windows11 .zip).
5. Try again. It it fails. note the error message if different from 1.
6. Download the self-installing update file (.msu) from the Microsoft Update Catalog, then install.
7. If it fails, note the error message. Record only if different from 1.
8. Visit UUPdump.net. Create an ISO file for the target Build (26100.2894, as per KB5050009 support note).
9. Perform an in-place upgrade repair install on the affected PC. This applies the already-integrated CU as part of that process.
10. If that fails, perform a clean Windows install using the UUPdump ISO.

I’ve only had to beyond step 5 in a small number of instances in the 30-plus years I’ve been using Windows. This was one of those cases. To my surprise the catalog download failed the the same error message as before. Next, it took an hour and half to download and build the 26100.2894 ISO, and another 50 minutes or so to install that image on the ThinkCentre. Ouch!

One Step Short of Clean Install Works

But when the PC rebooted, it came up with no errors. Interestingly, the Update History does not show KB5050009, even though it must be present for the build number to reach 26100.2894. You can see this in the lead-in graphic, which shows that very build number, but not the CU entry for KB5050009. That’s because it was part of the install image when the upgrade repair install occurred, not added separately via WU.

But it does go to show that here in Windows-World, when WU won’t work, there may sometimes be a way to work around its failings. This is such a tale…

PostScript: About the 0X800F081F Message

Here’s what Copilot says about this error message, thanks to info from answers.microsoft.com:

The error code 0x800F081F typically occurs when the Deployment Image Servicing and Management (DISM) tool is unable to find the necessary source files to repair the Windows image. This can happen during Windows updates or when running the DISM /Online /Cleanup-Image /RestoreHealth command.

To me that indicates there was some WU issue with the files included in the update package that got downloaded from the WU servers. Curiously it also seems to have affected the Catalog item. I’ve never had that happen to me before. Go figure!