Category Archives: Troubleshooting

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows Update

WU: How Long Is Too Long?

February 13, 2025 Ed Tittel Leave a comment

Here’s a Windows road I’ve been down many times. Indeed, it’s the kind of road, as in Robert Earl Keen’s excellent song, that “goes on forever…” It’s the road you walk on when WU hangs during download, GUI install, or post-GUI install. I read with amazement this morning in an ElevenForum thread that some poor soul waited THREE HOURS on a stuck install before asking for help. Ouch! Of course this raises the question with WU: How long is too long when things get stuck?

For me, the TLDR; answer is “10-15 minutes.” I just don’t have the patience to wait much longer. And FWIW, I’ve only seldom seen something that’s been stuck that long succeed after such a delay.

In WU, How Long Is Too Long Depends on You

At some point, the stuckee realizes that nothing is going to change, no matter how much longer one waits. That’s the point at which one must bite the bullet, and restart the stuck PC. Holding down the power button for 10 or more seconds until the PC shuts down will usually do it. Sometimes, however, one must either power off the PSU (desktops) or take more drastic steps (e.g. disconnect battery or wait for it to drain completely on a laptop).

Surprisingly, in the dozens of times I’ve had to do this when stuck in the past 5 years or so, the aftermath has mostly been positive. Often, Windows will simply pick up where the stuck update left off and finish up from there. Sometimes, it will roll back to the pre-install state instead.

Only in a handful of cases has the affected PC refused to boot correctly. When that happens, it’s time to pull out your rescue media and perform an image restore to your last known,good, working image backup. You have one of those, right? I’ve learned the answer to that question had better be “Heck, yeah. Let’ s go!”

Overcoming The Worst Case Scenario

No image backup and no working PC can be problematic. Hopefully, you’ve got at least some important stuff backed up someway, somehow (OneDrive, maybe?). You’ll either find a way to run a repair install (works sometimes) or you’ll have to choose between a clean install or a factory reset. Hopefully, it won’t come to that. I haven’t had to go there but once or twice in the 30-plus years I’ve been running Windows. Hopefully, your odds and experience will be the same. Good luck!

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11, Windows Update

Long Hard 27788 Upgrade Road

February 6, 2025 Ed Tittel 2 Comments

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…

Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog

NVIDIA Rollback Gets Interesting

February 5, 2025 Ed Tittel Leave a comment

Take a look at the lead-in graphic. It shows multiple daily crashes — hardware errors mostly — on my production desktop for the past week. As it turns out, my switchover from Game-Ready to Studio NVIDIA driver did not fix my dual monitor problems. I had to forcibly reload the graphics driver (WinKey+Ctrl+Shift+B) to get both displays working after sleep even after the switch. Resolved to undo recent updates, I learned that NVIDIA rollback gets interesting on this PC. Let me explain…

Why NVIDIA Rollback Gets Interesting

It doesn’t seem to matter which January 30 version of the NVIDIA driver I try to run on this PC and its RTX 3070 Ti GPU. Both posed stability and “wake from sleep” issues. Thus, I knew I had to roll back to the previous version.

Alas, the rollback button in Driver properties was not lit up, so I had to find and download the driver from the NVIDIA website. Once I identified the next-most-recent version — namely 566.36 — I was able to download its installer file from the older drivers listing for my graphics card, filtering on the Studio Driver tab.

Just to be safe, I also told the installer to do a clean install of that driver. This flushes out all associated files and registry settings found on the PC and replaces them with clean new (in this case, older) copies.

Rollback Success?

I was able to reboot and get into the OS with both monitors working just fine. I just put the PC to sleep, and was able to wake into both monitors without difficulty. I’d hazard the hypothesis that this might have fixed the issues I was experiencing. But after being too quick to declare victory in my Febuary 3 post after switching to the 572.16 Studio driver, I think I’ll wait and see if things keep working before calling this one “fixed for sure.”

Stay tuned! I’ll report back tomorrow and let you know if ReliMon throws any more errors. So far, so good even after “forced sleep and wake…”

Info Added 25 Minutes Later

I just came back from lunch. The PC woke up with a single keystroke (Enter) and both monitors are working as they should be. I’m encouraged.

Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog

Latest NVIDIA Game-Ready Driver Disses Dual Displays

February 3, 2025 Ed Tittel Leave a comment

Last Thursday, January 30, I installed new versions of the NVIDIA app and the latest game-ready driver (version 572.16) on my production desktop. It’s got a GeForce RTX 3070 Ti GPU, so I generally stay on the leading driver edge. Not this time! Immediately after I installed the new driver, trouble came to visit. Indeed, I’ll claim that the latest NVIDIA game-ready driver disses dual displays because no sooner did it next sleep, monitor 2 went dark and stayed that way. Eventually, I figured out that I had to cycle power on that monitor to get it working again. Sheesh!

Undoing Latest NVIDIA Game-Ready Driver Disses Dual Displays

I’m OCD enough about Windows stuff that I can’t leave something broken for too long. So when uninstall/reinstall failed to fix my wake-from-sleep issue with Monitor 2 (left-hand, as shown in lead-in graphic), I switched from NVIDIA’s Game-ready driver to the Studio driver model.

It, too, shows the same version number and release date. But as far as I can tell, it’s not inclined to lose Monitor 2 when the desktop goes to sleep. That’s a good enough reason for me to switch and stick with that selection. If I were a gamer — I’m not — I might feel differently. But because I’m not I’m glad that the more staid and reliable Studio version of the driver meets my needs, and keeps my monitors going.

And isn’t that just the way things go here in Windows-World sometimes? But the principle is a good one: if the driver you’re using is causing trouble, and a different model is available, there’s no harm in trying to see if the trouble goes away upon switching. In my case, I was lucky that it did!

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 10, Windows 11

Windows.old Required For Uninstall Window Access

January 29, 2025 Ed Tittel 2 Comments

Here’s an interesting Windows gotcha that affects both Windows 10 and 11. There’s an interval setting value in these OSes that controls how long Windows.old stays on your system disk before it gets deleted. It’s called the “OS uninstall window” and it’s set to 10 days by default, though any value from 2 through 60 (days) is legal. That said, you can only see and manipulate this value if Windows.old is present on the target system. That’s what the title means when it says “Windows.old required for uninstall window access.”

Why Is Windows.old Required For Uninstall Window Access?

God only knows (and possibly a few Microsoft OS engineers). That’s just the way it works. Indeed the relevant MS Learn article doesn’t comment on the why; it only documents the how. I had to go to Google to get an explanation for what you see in the lead-in graphic — namely, that when you run the DISM command that tells you the current uninstall window value for Windows.old, it throws an error if there’s no Windows.old present on your system for it to inspect. Weird.

The best explanation I found is at SuperUser.com. The short answer to “Why an error and not a number?” reads simply “No, you are too late.” That is, once Windows.old is removed, the command no longer works the way one might presume it should. In short, if no Windows.old is present, the OSUninstallWindow value is not available, nor can it be reset. Again: Weird.

Even weirder: you’d think there would be a registry value to control this. But alas, as Copilot informs me and my truth-check research confirms “There isn’t a specific registry value in Windows 10 or 11 that directly controls the OSUninstallWindow value.” It’s just another Windows oddity for the ages. Now I know (and now, you do, too). Cheers!

Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Backing Off Intel Graphics Driver

January 27, 2025 Ed Tittel Leave a comment

Ok then: I was operating under the belief that no harm should come to Lenovo PCs after updating to Intel GPU drives via DSA. Apparently I was mistaken: I’ll show evidence that for the ThinkStation P3 Ultra at least, the DSA-supplied Arc & Iris Xe drivers pose problems. Hence, I’m backing off Intel graphics driver on that machine.

Why I’m Backing Off Intel Graphics Driver

Check out the lead-in graphic. It shows Reliability Monitor with 2 crashes on both 1/22 and 1/23 for the IntelGraphicsSoftware Service process. Not good! Indeed, it causes about a 5-point drop in the reliability index in two sharp dips.

To me, that makes it pretty clear that — at least for this PC — the Intel driver is not working properly in its runtime environment. The notion that I picked up was that updating Windows 11 graphics drivers would not necessarily overwrite OEM customizations. FWIW, Copilot confirms this. But the evidence from ReliMon on the P3 is pretty hard to contest. Methinks Intel is still right to post its warning in DSA where such drivers are concerned (with a checkbox for users to explicitly opt in anyway), to wit:

And indeed, now that I’ve uninstalled that driver and reverted to a Lenovo driver dated 10/29/2024, I’ve experienced no further issues with Intel graphics stuff. That said I do have an APPCRASH for the IntelSoftwareAssetManagerServer.exe process. But a quick hop to the Intel Support Community shows that this belongs to PROSet Wireless stuff not graphics. So there’s a problem for another day!

Here in Windows World it’s always something. Lately, those “somethings” have an interesting number of elements with Intel’s name involved. Go figure…

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11, Windows Update

Overcoming KB5050009 Update Errors

January 17, 2025 Ed Tittel 1 Comment

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!

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Dead CMOS Mungs Boot Behavior

January 15, 2025 Ed Tittel Leave a comment

It’s one thing to know something in the abstract. It’s entirely another to have it hit you in the face. Today, I went to log in to my son’s PC to update the BIOS to wake on LAN (WoL). No dice. I couldn’t get anything to get me into UEFI, not System > Recovery > Advanced Startup; not the Asrock Restart to UEFI utility, not even shutdown /r /fw /t 00. Then it hit me: could the CMOS battery be dead? Sure enough, a new CR2032 lithium coin battery fixed the problem. And I was forcibly reminded that a dead CMOS mungs boot behavior.

New Battery Fixes Dead CMOS Mungs Boot Behavior

I happened to have 7 of the 10 (now 6) CR2032s I bought via Amazon in 2023 still on hand. With an expiration date in the 2nd half of 2027, I felt comfortable swapping in this newer battery in place of the dead one. As soon as I’d done that, then recabled everything — alas I had to unseat the GPU to reach the battery receptacle — the system resumed proper, normal boot behavior.

Take this lesson from me: if you ever find yourself unable to get to UEFI, WinRE, or other boot menus and displays, check the CMOS battery. If you’re as lucky as I was today, replacing same will fix your issue(s) as it did mine. Cheers!

And ain’t that just the way things go sometimes, here in Windows-World? You betcha… There is an upside though: with the BIOS/UEFI change I was finally able to make, I can now remote into the upstairs Ryzen PC thanks to Wake on LAN (WoL). All’s well that ends the same way.

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows OS Musings

Assessing Generic WU Error Fixes

January 10, 2025 Ed Tittel Leave a comment

Here’s an interesting situation. Right now, my Windows 10 production PC (22H2 Build 19045.5247) has been showing a “perfect” Reliability index since December 21 (21 days). That said, this same device threw a “Failed Windows Update” error 4 times in the period from December 30 through January 6. In researching the error it shows mostly gobbledygook: error 0x80073D02: 9P6PMZTM93LR-Microsoft.6365217CE6EB4. Furthermore, it has me assessing generic WU error fixes, because I can find no definite prescription to fix this recurring item.

Why I’m Assessing Generic WU Errror Fixes

Take a look at the reliability monitor output in the lead-in graphic. It shows a Windows 10 PC that’s working as well as it can for an extended period of time (3 weeks). It also shows 4 instances of the same gobblydygook error string reproduced in the preceding paragaph that occurred about every other day over an 8-day period.

To begin with, the 10 reliability index convinces me that whatever is wrong isn’t really serious. Next, conventional wisdom when troubleshooting WU errors is to “try a bunch of stuff, and hope something works.” Indeed, here’s what Copilot — affirmed by other reliable sources including TenForums.com — recommends for this error:

Run Windows Store Apps Troubleshooter: Go to Settings > System > Troubleshoot > Other troubleshooters, and find the Windows Store Apps troubleshooter.
Reset Microsoft Store Cache: Press Windows Key + R to open the Run dialog, type WSReset.exe, and press Enter.
Uninstall/resinstall Windows Store (Winget does this nicely with Microsoft.WindowsStore as the targeting ID.
Re-register Windows Store: Open PowerShell as an administrator and run the following commands:

Set-ExecutionPolicy Unrestricted
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$ ($_.InstallLocation)\\AppXManifest.xml”}

Check System Files for Corruption: Run the SFC and DISM commands to check and repair potential corruption.

The problem with this kind of approach is that it involves “try everything, and hope something works.” Mostly, the Store is working well enough to avoid uninstall/reinstall (Item 3 above) and also unregistering then re-registering all Store contents (item 4) above.

So I tried items 1, 2 and 5, which took under 7 minutes to complete. None said they fixed anything, either. So far, no repeat errors in the past four days. Is the problem fixed? As with most mysterious Windows weirdnesses, only time will tell.

If It Ain’t Broke…

One thing I’ve learned in tinkering with Windows versions since 3.1 and forever afterward (3.11. 95, 98, Me, NT, 2000, XP, 7, 8, 10 and 11) is that fixing problems that aren’t really problems only makes things worse. Here I took the approach of “do the easy stuff, save the hard risky stuff if it comes back later.” So now, fingers crossed, I’m watching to see what happens next. Hoping for that to be “little or nothing.”

Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

DSA Update Succeeds Where Lenovo Vantage Fails

January 2, 2025 Ed Tittel Leave a comment

Go figure! When Lenovo Vantage reported this morning that the ThinkStation P3 Ultra needed a new Intel Wi-Fi driver, I thought nothing of it. I elected the install, fired it off, and waited for the results. Oops: “Failed to install.” Tried again, and got the same result. So I checked Intel’s Driver and Support Assistant (DSA). Sure enough it reported the same outdated driver (23.60.0.10) and the same incoming new replacement (23.100.0.4). But that DSA update succeeds where Lenovo Vantage fails. As you can see in the lead-in graphic, a subsequent Vantage update check post-DSA reports no updates available (and shows a failed attempt below).

Guessing Why DSA Update Succeeds Where Lenovo Vantage Fails

I’m a great believer in the old principle that “if one tool fails, try a different one.” What’s trickier is figuring out why Vantage falls over while DSA does the job correctly. Copilot speculates it could have to do with compatibility, permissions, or software conflicts. Turns out one must enable a registry setting to get Vantage to log and report on failures — absent on the P3 Ultra, alas — so I can’t really tell what went south when Commercial Vantage did its thing.

If it were really important (and I hadn’t found an immediate and easy workaround) that’s what I’d be doing next. The key string involved is:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Lenovo\
SystemUpdateAddin\Logs

The REG-SZ (registry string) value named “EnableLogs” needs to be changed from its default value of “False” to “True” for subsequent logging to occur. I’ve made that change, and will check out if and when future Vantage install or other update errors occur. Good stuff!

Prepped for the next gotcha: logging enabled.

Hopefully next time I won’t have to guess what happened. The log should tell me something. Whether I can parse its meaning is a whole ‘nother challenge!