Category Archives: Troubleshooting

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

Overcoming KB5050009 Update Errors

January 17, 2025 Ed Tittel Leave a 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!

Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog

Identify Spurious Windows Reclaimables

December 9, 2024 Ed Tittel Leave a comment

OK, then: thanks to some excellent detective work by ElevenForum stalwart @Bree, it looks like DISM can tell curious Windows users which packages are “stuck.” That is, you run the DISM command sequence: Analyze-Clean-Analyze, with a positive number of reclaimable packages still showing. (You can find all the details in my 11/2023 blog post on this topic.) This time around, I’ll show you how to list out the actual items that identify spurious Windows reclaimables. Warning: some PowerShell hacking is involved!

How-to: Identify Spurious Windows Reclaimables

@Bree shows the source for the data needed to identify these strange offenders. It’s based on analyzing data within a DISM generated text file. Here’s the specific command that creates that data:

DISM /ONLINE /GET-PACKAGES /FORMAT:TABLE > KB.txt

What this does is to inspect the current running Windows image (/online), grab all packages it finds with some related data (/get-packages), and format it into a table (/format:table). That last bit (> KB.txt) redirects command output into that named file. The column headings in that output read: Package Identity, State, Release Type, and Install Time with vertical bars (‘|’) used to separate entries.

Bree’s analysis concurs with my own prior inspection of this same kind of output. We both agree that only lines with the strings “Staged” and “Feature Pack” in them point to spurious Windows packages. His analysis depends on sucking the output into a text file, converting to Excel format, sorting by State, and counting groups of lines to match the spurious reclaimable count to what’s reported by DISM /AnalyzeCompontentStore. Remember: those are packages that stay in the component store even after a DISM /cleanup-image operation has completed successfully. I simply write the output from the /Get-Packages DISM command to a file named KB.txt and filter its results.

Automating Analysis of KB.txt Contents

Next, my PowerShell script comes into play (such as it is, it’s pretty primitive). Unzip kbfilt.zip and then move kbfilt.ps1 to the directory where you created kb.txt (to run this file type .\kbfilt.ps1 inside an administrative PS Terminal window: screenshot follows later).

# Path to the input text file
$inputFilePath = "kb.txt"

# Path to the output text file
$outputFilePath = "kbfilt.txt"

# Read the file line by line and filter the lines
Get-Content $inputFilePath | ForEach-Object {
# Check if the line contains both "Staged" and "Feature Pack"
if ($_ -match "Staged" -and $_ -match "Feature Pack") {
# Output the line to the output file
$_ | Out-File -FilePath $outputFilePath -Append}}

# Confirm the script has finished
Write-Host "Lines w/ 'Staged' and 'Feature Pack' written to $outputFilePath"
Write-Host "Remember to delete kb.txt, kbfilt.txt before next use"

I used the -Append directive for Out-file which means the script appends text to the file and doesn’t over-write (“clobber” in PS-speak) other content. That’s why you’ll want to delete these files if you want to run the script again.

My Copilot+ PC (an Intel Aura Yoga Slim 7 model from Lenovo), running Windows 11 24H2 Build 26100.2134, has 2 spurious packages as shown here:

2 packages with LONG names (typical for Windows)
[Click image to view full-sized.]

This investigation is simply to show you which packages are stuck. You can get rid ofthem with DISM /Remove-Package. But if you do, they’ll most likely pop back up again after you install the next Cumulative Update (CU). Windows images are funny that way. But at least, now you can identify the packages involved.

Insider stuff, Recent Activity, Troubleshooting, WED Blog

Persistent Revo Requires Disabling Task

December 4, 2024 Ed Tittel Leave a comment

Drat! After returning from vakay, I noticed Revo Uninstaller still popping up after Startup. My November 21 post mentioned disabling some settings. Autoruns (see lead-in graphic) also tells me there’s a scheduled task that must be disabled to prevent its “helper” (and the app) from launching after startup. Indeed, this persistent Revo requires disabling task for its helper.exe. Go figure!

It Irks Me That Persistent Revo Requires Disabling Task

When software makers offer free versions of their applications, they seem to feel entitled to let that version do various things to Windows PCs — not all of them desirable or well-behaved. I take umbrage with Revo, and other publishers who do likewise. That goes double, especially when they offer no opt-out in their installers, nor warnings for users. It seems they’re resolved that their software is going to make itself run at startup whether you like it or not.

Methinks it’s because such vendors seek added upsell opportunities. Alas, it only proves irksome and bothersome instead. This time, I had to call out the heavy artillery — namely, SysInternals Autoruns, capable of showing and stopping anything and everything that touches startup behavior on a Windows PC.

This isn’t the first time I’ve found myself saying “Thank you, Mark Russinovich and the rest of the SysInternals team.” It won’t be the last, either. In fact, that litany will no doubt continue until I stop running Windows (unlikely) or you pry it out of my cold, dead hands (inevitable, but hopefully not for some time yet).

Backup/Restore, Insider stuff, Recent Activity, Security, Troubleshooting, WED Blog

Windows Resiliency Initiative Includes Quick Machine Recovery

November 20, 2024 Ed Tittel Leave a comment

It’s that time of year again, when MS meetings and conferences — Ignite 2024, in this case — heat things up with future promises and new idea campaigns. Yesterday’s Windows Experience Blog from David Weston (MS VP Enterprise & OS Security) is a case in point. Entitled Windows security and resiliency: Protecting your business, it asserts that a new Windows Resiliency Initiative includes Quick Machine Recovery as a key capability. Very interesting!

Explaining Windows Resiliency Initiative Includes Quick Machine Recovery

This new initiative “takes four areas of focus” as its goal — namely (all bullet points quoted verbatim from the afore-linked blog post, except for my [bracketed] commentary):

Strengthen reliability based on learnings from the incident we saw in July. [Crowdstrike kernel mode error took down 8.5M Windows PCs.]

Enabling more apps and users to run without admin privileges.

Stronger controls for what apps and drivers are allowed to run.

Improved identity protection to prevent phishing attacks.

The first and arguably most impactful preceding item is what led MS to its announcement of Quick Machine Recovery. Here’s how Weston explains it:

This feature will enable IT administrators to execute targeted fixes from Windows Update on PCs, even when machines are unable to boot, without needing physical access to the PC. This remote recovery will unblock your employees from broad issues much faster than what has been possible in the past. Quick Machine Recovery will be available to the Windows Insider Program community in early 2025.

In other words, this new feature should enable what savvy administrators had to do using OOB access to affected machine via KVMs smart enough to bootstrap machines otherwise unable to boot.

Great Addition: How’s the Execution?

IMO this is something MS should’ve built into Windows long ago. I’m curious to see how (and how well) it works. I’m also curious to see if it will be available for Windows 10 as well as 11. Only time will tell, but I’ll be all over this when it hits Insider Builds early next year. Good stuff — I hope!!

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

Forced 24H2 Upgrade Throws BSOD

November 1, 2024 Ed Tittel Leave a comment

I couldn’t help myself: I HAD to try it. On the Lenovo ThinkStation P3 Ultra, I used the Windows 11 Installation Assistant to bring on the newest version. Alas, my forced 24H2 upgrade throws BSOD with error code 0X85 SETUP_FAILURE. Quick research found an MS Learn article on that very topic. Alas, it also says “a fatal error occurred during setup” and suggests unplugging peripherals and trying again, but provides no real repair advice. You can see my iPhone BSOD photo, skews and all, as the lead-in graphic here.

Bad Cess As Forced 24H2 Upgrade Throws BSOD

Please note: even though the BSOD text reads in part “We’ll restart for you,” I had to toggle the power button to bring the P3 Ultra back to life. Sigh: looks like its Intel i9-13900 Intel CPU is subject to some documented issues. Indeed, I just found an Intel Community post that says if Turbo Boost is enabled in the BIOS, it can crash during the Windows 11 upgrade process.

So I visited Settings > System > Recovery > Advanced Startup and then entered the BIOS. Sure enough, Turbo Mode was enabled, so I disabled same. Now, I’m running the Installation Assistant again. It zoomed through download and verification phases, so the files from the original download were obviously still present. Now it’s doing the GUI install portion …

Is the 2nd Try Charmed, or Doomed?

It took about 10-15 minutes for GUI install to complete. Turning off Turbo Mode notably slows things down. The post-GUI install went much slower, though: it zoomed up to 71% in 5-8 minutes, then took the better part of an hour to work its way to completion and OOBE.

But I’ve now got a working 24H2 installation on the ThinkStation P3 Ultra, as you can see in the next screencap. It shows Lenovo Vantage device info, above which I’ve positioned Winver output. Then I had to go back into the BIOS and turn Turbo Mode back on. With Turbo Mode restored, the system runs very much faster.

Winver 24H2 in front, Lenovo Vantage Device Details in back.

Now, I have to ask: is this disable/enable in BIOS looming over all future upgrades, or is it just a one-time 24H2 thing? As the clue that pointed me toward this fix came from 22H2, probably not. Another thing for me to remember, in that case…

And isn’t that just the ways things go from time to time, here in Windows-World? You betcha!

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

BIOS Update Demands Cable Switch

October 29, 2024 Ed Tittel Leave a comment

Whoa: this time, things got just a little bit TOO interesting. I’ve got a Lenovo P360 Ultra ThinkStation on loan, and a BIOS update came through today (to version S0JKT2AA). But when I would install the update, the usual BIOS flash screens did not come up after a reboot. It wasn’t until I swapped the graphics cable from the full-size DP to full-size DP port, to a full-size DP (monitor) to mini DP (PC) that the splash screen showed up at boot, and the BIOS flash ran through to completion. Thus, the BIOS update demands cable switch to succeed. Go figure!

How Did I Figure Out That BIOS Update Demands Cable Switch

By watching the post-reboot behavior on-screen, I realized it wasn’t showing me what it was supposed to. Basically, the screen stayed black post-restart until the lock screen for Windows 11 appeared. I knew I was supposed to see the boot-up splash screen (which reads “Lenovo” in white letters on a black background on this device). But instead: nada.

So on a whim, I brought down the video & power cables box from atop my bookshelves. Then, I grabbed a full-size DisplayPort to mini-DP cable and used it to replace the full-size DP to full-size DP I was currently using. Immediately thereafter, I got a splash screen and the BIOS update started processing. It took a while, but it eventually ground through to a successful update.

What About those Intel Graphics?

The next item of business was to get the built-in Intel graphics (UHD Graphics 770) updated. After a handful of failed attempts to get the Lenovo version to run, I visited the Intel DSA (Driver & Support Assistant) and installed that version instead. It worked. You can see the results for my final — and entirely welcome — update check using the Lenovo Commercial Vantage tool as the lead-in graphic above.

That was a wild ride. But indeed, that’s the way things go in Windows-World far too often, based on my current level of interest vs. fatigue. Today, fatigue wins out. Sigh.

Insider stuff, Microsoft 365, Recent Activity, Troubleshooting, WED Blog

MX Error Provokes Outlook Account Fix

October 18, 2024 Ed Tittel Leave a comment

Ever since Microsoft pushed an Outlook update in late September, Outlook hasn’t let me access my primary email account. Something about handling of DNS info related to mailservers changed, and not for the better. Simply put, the configuration I’d been using to ingest incoming email and send outgoing email quit working. But when I checked the dreamhost config recommendations, everything agreed with same. Despite repeated fix attempts, account setup kept foundering because of a reset to some whacko domain I never heard or read about –namely: smtp. mailchannels.net. This morning I had an astonishingly positive encounter with Microsoft 365 chat support, during which an MX error provokes Outlook account fix. Buckle up: this is going to take some explaining…

How an MX Error Provokes Outlook Account Fix

Outlook is obviously reading from MX records for the domain names it runs into. The only way I can get my home account (the one for this very website, in fact) to work is by over-riding both incoming and outgoing mail server values that the lookup process finds on its own.

It gets worse. If I tell Outlook to repair itself, it overwrites my over-rides with those selfsame values again. Fortunately, I’ve now got all this stuff memorized and I know how to fix it. But it wasn’t until we tried and failed to use my domain name (edtittel.com) for the mail servers that the inbuilt Outlook facility started reading the right MX records. Only then was I able to use those for the email host instead of whatever Outlook was dredging out of the MX records it finds on my behalf. Sigh.

Automation Had Best Be Correct…

I understand that MS is just trying to help by automating the mail server lookups and name assignments. That’s terrif, as long as they get those lookups right. But as I’ve just learned, over-riding errors in such lookups can get excessively interesting.

Shoot! I couldn’t even get email to work in Outlook until I figured out I should ignore its findings and insist on what the provider’s configuration page told me I should use. What’s interesting is that’s what was in there in the first place, and quit working late last month. I wasn’t able to get back into the fold, however, until I tried my own domain name, at which point the error trail finally located workable MX records.

Go figure! That’s what keeps me on the edge of my seat, and makes Windows-World an always-interesting place to work and live.