Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

WinGet Versions May Affect Installs

Leave a comment

I just saw something interesting running WinGet on multiple PCs here at Chez Tittel. On my production desktop (Flo6) running production Winget (Version 1.27.470.0) a Teams update just failed with error message “…system cannot find … file specified (0x80070002).” On my Canary test system (X12Hybrid) running preview Winget (Version 1.29.30.0) that very same update succeeded. Inevitable conclusion: WinGet version may affect installs and updates, including success or failure. Who knew? Let’s discuss…

Why WinGet Versions May Affect Installs

Copilot confirms my suspicion that version differences sometimes affect update or install behavior. It says (and I concur) “some WinGet releases and App installer builds handle extraction and temp paths differently; newer/older builds can succeed where others fail.” Isn’t that strange — but typical — for Windows stuff anyway?

Fortunately, the in-app updater in Teams popped up as soon as I opened the app up. It, at least, was able to update itself successfully. So I applied the old principle: if you can’t do it one way, try another, and got past this hurdle anyway.

Is It a Version, or an Instance?

Then I went looking at my other production level PCs here at Chez Tittel. I looked at 4 other machines in my office all running Windows 25H2 Build 26200.8037 (latest production build). None threw the same error, though all are on the same Windows, Winget and Terminal versions. Interesting! My other production machines, however, did post this warning (in yellow) after the Teams update:
“Successfully installed. Restart the application to complete the upgrade.” (That warning does not appear in the lead-in graphic, which comes from a preview WinGet version instead.)

I’m left with no choice to conclude that it’s the configuration of the particular machine (Flo6) that’s somehow suffering or different. Based on what Copilot told me, it’s likely a PATH issue of some kind. As the old Internet adage goes so well for Windows: YMMV. Indeed, it just did!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog

DDU Fixes GPU Driver Disasters

Leave a comment

Today’s blog post is a paean to a tool named Display Driver Uninstaller, popularly known as DDU. It’s long been part of most Windows admin and power user toolboxes. DDU comes from Wagnardsoft, but well-known 3rd-party mirrors also include Guru3D and TechPowerUp. DDU remains a useful tool at completely replacing GPU drivers and their Windows infrastructure when graphics go wrong. It’s also a great way to switch from one GPU type to another. Say, from NVIDIA to AMD, or vice-versa, or even from one of them to Intel ARC. TL;DR version: DDU fixes GPU driver disasters and lets you switch types with little muss or fuss.

Why Say: DDU Fixes GPU Driver Disasters?

Over the past 9 days, we’ve seen an unusually fast series of NVIDIA Game-Ready GPU drivers (with one evanescent Studio driver on February 26). That Thursday saw both versions make an appearance that provoked immediate issues and outcry; version 595.59 was withdrawn less than two hours after its release.

Then on Monday, March 2, NVIDIA fired off Game-Ready version 595.71. Users soon began reporting diminished performance from this driver (especially for certain, GPU-intensive games). Further inspection (using tools like GPU-Z) observed that it imposed voltage caps on RTX 50-series GPUs to limit damage potential. At the time, I wondered if this wasn’t like putting “chewing gum on top of baling wire” to fix things.

On March 4, 2026 (Wednesday), NVIDIA dropped a hotfix to address these issues, in the form of 595.76. It addressed the voltage capping, and a variety of other game-specific glitches and gotchas. Since then, things on the NVIDIA Game-Ready driver front are steady, if somewhat uneasy. This is the first time in YEARS that the company has had two unstable Windows Hardware Quality Labs (WHQL) designated drivers follow in quick succcession.

Rollback Versus Deep Cleanup

So far, users have been able to recover from these updates without lingering issues. In the past, GPU driver glitches have resulted in black or stuttering screens, serious and ongoing display disturbances (aka “screen artifacts”), driver store damage, or bothersome system or GPU installer instability or crashing. When those things happen, that’s when DDU comes into its own. It cleans up all of the old GPU driver stuff and gets rid of whatever’s causing problems, then lays down a brand-new, clean and (hopefully) reliable replacement runtime to get your GPU(s) working properly once again. Hopefully, it’s obvious this capability also makes DDU excel at “out with the old, in with the new” actions when switching from one GPU type to another.

Did the recent NVIDIA debacle call for DDU? No it did not. I personally observed that the rollback facility in Device Manager took my system back from 595.59 to 591.74 (Studio). Other users have consistently reported that Game-Ready drivers also rolled back successfully as well (591.86 in most cases).

Even though this latest spate of Game-Ready drivers has caused some commotion, it hasn’t seemed to cause much need for DDU. Not this time around, anyway. But it’s good to know that DDU is out there should you need it. Or should you be switching from one GPU type to another. Here in Windows-World it’s better to have such tools and not need them, than to need them and not have them!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Web Extensions Stymie Input

Leave a comment

While trying to conduct a cash transfer online yesterday, I ran into an interesting — and new (to me, anyway) — problem. In attempting to provide account and identity information I found myself unable to enter data into the very input form that was soliciting same. “Hmmm,” I wondered to myself, “Why is this not working?” So I decided to ask Copilot. It immediately informed me that things such as auto-fill. password managers, and related “conveniences” can step all over input fields inside certain web pages. The TL;DR diagnosis, put succinctly, is some Web extensions stymie input.

Copilot recommended that I open an incognito window, and try again. Guess what? That worked like a champ!

Why Web Extensions Stymie Input — In Some Cases

In my case it looked like a combination of Chrome auto-fill and the Norton Password Manager were conspiring against the input page to prevent it from seeing and handling my input as it should. As soon as I got those things out of the way, the input problems disappeared.

I’ve been building websites and writing about markup languages for over 30 years now, and this is the first time I’ve run into this phenom. Apparently I’ve been incredibly lucky, because it happens on a lot of websites, especially those built to handle multiple languages and character sets. It just so happens this particular gotcha never bit me until yesterday, when it bit hard (and drove me just a  tad bonkers).

KISS Remains a Valuable Approach to New/Unfamiliar APIs

KISS is, of course, the acronym for “Keep It Simple, Stupid!” It’s a good approach to keep in mind when working with new and unfamiliar apps, user interfaces, and the code beneath those skins. By simplifying the text handling the browser performed when providing input, I allowed the target web page to do its job without lots of other stuff going on in the background.

A simple, straightforward text entry environment let the web page accept input straight from my keyboard, with no extra processing or data delivery. Apparently, that was just what it wanted or needed to get the job done.

Here in Windows-World, not stepping on yourself is often the key to a successful user experience. Once my browser got itself out of the way, the web page was able to take it from there. I’ll count that as an unqualified success, and an interesting learning experience.

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

On Windows 11 Restore Points

Leave a comment

In Windows 11, a restore point provides a snapshot of various essential system files, settings, installed programs, and the registry taken at a specific point in time. Restore points can roll back the OS and associated state info should something go sideways. They don’t replace backups (especially image backups) because they don’t contain personal files and documents, nor do they capture other boot disk partitions for full restoration (e.g. EFI, MSR and recovery partitions, if present). I’ve been thinking on Windows 11 restore points because I don’t use them (I use daily image backups instead) and because they can take up lots of room on disk.

Looking further into Windows 11 Restore Points

Before I could share my reflections and observations about Windows 11 Restore Points (let’s condense that to W11RPs) I had to find a machine with them turned on to dig into them a bit. Turns out my newest personal acquisition — the very nice ASUS Zenbook A14 I picked up during Black Friday sales last year — still has them turned on. You can see that the C: drive has W11RPs enabled, and the info about a single restore point that I just generated right under neath.

You can find restore points inside the WizTree app pretty easily, if you’ve got any. They appear within the System Volume Information folder, which lives at the root of the boot/system drive (C:\ usually). It’s the big purple rectangle in this snippet from Wiztree, and corresponds to the shadow copy item shown in the lead-in graphic (output from the vssadmin list shadows command, in fact):

At 2.3 GB in size, one can see why keeping numbers of them around might be something of a storage-sucker. In truth, that’s one big reason I typically don’t keep them around.

Turning W11RPs on and off, and more

The controls for W11RPs live on the Protection tab of the System Properties applet in Control Panel. Settings in Windows 11 kind of interferes with access to this info, so the best way to get there these days is to invoke its executable directly (Into the Windows Run box (Winkey+R), type this string:

C:\Windows\System32\SystemPropertiesProtection.exe

That fires up the item screencapped next, and shows the key controls for W11RPs, to wit:

For any drives available on the target system, you select its entry, click the “Configure” button then enable or disable restore points. As you can see about the C:\ drive has W11RPs enabled, and it came that way from the factory.

Problems with W11RPs?

If you read up on informed sentiment about W11RPs (I get my insights from many sources, but find TenForums.com and ElevenForum.com particularly insightful), you’ll learn that they sometimes work, and sometimes don’t. If you use them, you’ll learn that they take a while to load (on the order of 15-20 minutes on most of my PCs). They also tend to happen once a day by scheduled task, and whenever you make system changes or install apps that include built-in RP capture commands.

You can use them if you like. I don’t like, and I don’t use them. Macrium Reflect can restore a full system image on my PCs in the 2-6 minute range, is easier to use, runs from a rescue disk if needed, and has shown itself to be thoroughly reliable and capable. For me that’s the end of the story.

Now, pardon me while I go off to disable W11RPs on the AsusSnap. I seem to have forgotten this little step in my intake process…

 

Facebooklinkedin
Facebooklinkedin
Uncategorized

Keep Your Windows Clean

Leave a comment

In poking around the fleet here at Chez Tittel lately, I can’t help but notice that my Windows PCs seem to pick up detritus at a good clip. Nearly every time I run a tool such as Disk Cleanup (cleanmgr.exe), PC Manager, or even the ancient but still servicable UnCleaner utility, I put at least 800MB-1GB  of storage back into the free pool. One of my mottos has been (and remains): “Keep your Windows clean.” And there’s more to suggest driven by that impetus…

What Keep Your Windows Clean REALLY Means

As you can see in the lead-in graphic, even after running PC Manager’s “deep clean” facility, Uncleaner still finds another GB of trash to take out. Indeed, multiple tools often focus on multiple sources of unwanted or unnecessary stuff. Using them in combination will usually take out more trash than a single item can ferry into oblivion on its own.

But wait: there’s more! Other things in Windows besides file storage need an occasional cleanup. Here are some examples:

  • Use a tool such as RAPR (DriverStore Cleaner) to remove obsolete or duplicate device drivers from the Windows driver store
  • Use DISM to do likewise for the Windows Component Store (e.g. DISM /Online /Cleanup-image /StartComponentCleanup)
  • Various identity and authentication cleanups, including credential manager, Windows Hello/NGC, AAD/Workplace Join, cached identity tokens, and more

I’ll blog about this final item tomorrow, because I’ve been spending a lot of time on that kind of stuff lately, and have some useful PowerShell to share along those lines. Stay tuned.

And remember: a clean Windows install is a happy and healthy Windows install. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog, Windows 11

Another Take On Failed RDP Login Fix

Leave a comment

Last Friday, I packed up the tiny but nifty Lenovo ThinkCentre Neo 50q to ship it back to North Carolina. Then, I stood the small but mighty ThinkStation P3 Ultra Gen2 up in its place. When I tried to RDP into that machine to catch it up with changes since it went dark in early January, it wouldn’t let me log in with my usual MSA. “I’ve seen this before,” I thought, as I recalled my Feb 19 blog on this very topic. That previous fix had changed the folder name for my user account and I wanted to avoid that on the P3Ultra2 if possible. So, I took another take on failed RDP login fix and came up with something better. Let me explain…

Details: Another Take on Failed RDP Login Fix

The P3 Ultra2 had been healthy after its identity‑stack cleanup, TPM reseal, and scheduled‑task repairs. Local login worked. The system was stable. Nothing in the logs suggested trouble. But RDP refused to authenticate. Every attempt failed with the same unhelpful message: “The credentials did not work.” The username was correct. The password was correct. The account was enabled. The SID matched. The machine was healthy. Yet RDP would not accept the credentials under any circumstances.

When this kind of failure presents, there’s usually some mismatch between the local Windows identity and the identity info RDP uses for remote validation. TL;DR version: that was exactly what went wrong.

Why Correct Credentials Failed RDP Validation

The key understanding requires knowing how RDP handles MSAs. When a user signs into a Windows PC locally, her or she can use Windows Hello, a PIN, or security tokens. That said, RDP cannot use any of these for remote login validation. Indeed, RDP requires a local NT password hash stored in the SAM on the target PC. If no such hash exists, RDP can’t validate user login input, even if the supplied password for an MSA is correct and current.

Here’s what went wrong on P3Ultra2: the MSA acccount had never generated a local password hash. From the first login, Windows 11 used Hello-based authentication. Alas, that means the SAM never got a password hash for that account. Locally, things worked as expected (because Hello could — and did — work with cloud based authentication). RDP could find no password hash and thus could not authenticate.

The Fix Is In, and Dead Easy

All I had to do was to sit down in front of the P3Ultra2 and force it to use the password for a single login. I did so at the lock screen by clicking the password icon (middle position in lead-in graphic) and then typing in the account password.

As soon as I did that, Windows automatically generated the NT password hash for that MSA. With that value now available, RDP immediately opened its remote access doors on my next try to get into P3Ultra2 through the Remote Desktop Connection App. Problem solved.

Sometimes, problems in Windows-World are huge and hairy. Sometimes, they’re astoundingly simple — as long as you can figure out what’s really going on. This particular RDP thing fell into the latter category. I’m glad I now understand, and gladder still it’s fixed.

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

CPU Changed Boot Warning Nightmare

Leave a comment

This morning I noticed external audio wasn’t working on my Flo6 desktop. I quickly went down a rabbit hole with audio drivers and such. Along the way, through a series of a half-dozen reboots, I noticed the fTPM “CPU changed” message kept popping up. At first, it was mildly annoying. But when it kept repeating I found myself stuck in a “CPU Changed” boot warning nightmare. How to escape?

Note on an AMD mobo fTPM is a firmware Trusted Platform Module, which resides inside a Platform Security Processor on the mobo. It provides the same functions as a discrete hardware TPM. It’s been bugging me lately, as I will relate…

Ending the “CPU Changed” Boot Warning Nightmare

Interestingly, the fTPM “CPU changed” message can appear even when the CPU has not been replaced. It shows up when the firmware detects a mismatch between the stored fTPM data and the state reported by the Platform Security Processor. This mismatch can happen during normal use. It can also happen after a firmware stall or a power loss. The message is confusing because it suggests a hardware change. In most cases, nothing is wrong with the CPU. The system is only trying to protect the integrity of the TPM state.

To say that Flo6 shows this message more often than other systems is an understatement. It happens a lot, and the reason is simple. Flo6 has a sensitive trust chain. It depends on the Platform Security Processor (PSP), the Embedded Controller (EC), and the BIOS staying in sync. If any part of that chain resets at the wrong time, the fTPM state can fall out of alignment. When that happens, the firmware cannot confirm that the stored TPM data belongs to the current system state. It then shows the prompt and waits for user input.

What Makes Flo6 My Problem Child?

This message appears most often after a forced shutdown. It can also appear after a firmware stall or a long power loss. If the system loses power while the PSP is active, the fTPM state may not save cleanly. On the next boot, the firmware sees the mismatch and stops to ask for confirmation. This is a safety feature. It prevents the system from using TPM data that may not match the current hardware state.

Flo6 also shows the message after a failed warm boot. A warm boot will not fully reset the PSP. If the PSP is left in a partially updated state, the next boot may not match the stored fTPM data. The firmware then shows the prompt again. This is why the message sometimes appears after a simple restart. The system is not failing. It is only trying to confirm the trust state.

Responding to “CPU Changed” with Yes

Choosing Y tells the firmware to restore the stored fTPM state. Choosing N tells it to discard the stored state. On Flo6, Y is usually the correct choice. It keeps the system stable and avoids repeated prompts. N is only valid when the CPU has changed. If the CPU has not changed, N can cause more trust state mismatches. It can also trigger BitLocker recovery if BitLocker is enabled.

The “CPU changed” message does not mean the CPU is faulty. It does not mean the BIOS is corrupted. Nor is the system unsafe. It only means the firmware wants to confirm the TPM state before it continues. Flo6 is more sensitive to this check because of the way its firmware handles power loss and warm boots.

That’s why I’m getting ready to swap the ASRock B550 Extreme4 mobo for an MSI MAG Tomahawk model. I read that its UEFI is more stable, robust, and less prone to fTPM mismatches. Here in Windows-World, an escape from the frying pan can lead into the fire. Fingers crossed that the upcoming rebuild ends this nightmare.

Facebooklinkedin
Facebooklinkedin
Uncategorized

How UEFI Flash Overturned Flo6

Leave a comment

A routine UEFI firmware update brought unexpected trouble to the Flo6 system yesterday. What should have been a simple BIOS flash turned into a boot failure. The cause? A major change in Secure Boot keys. This event highlights how firmware updates can affect system trust and stability. As I was figuring out how UEFI flash overturned Flo6, I had to work my way through another CMOS reset, GPU disconnect, and more. Buckle up: here come the deets!

How UEFI Flash Overturned Flo6, and Killed Normal Boot-up

The BIOS update for Flo6 included more than microcode or AGESA changes. It replaced the Secure Boot Platform Key (PK), Key Exchange Key (KEK), and the Allowed Signatures Database (DB). These new keys came from Microsoft’s 2023 certificate chain. They replaced the older 2011 certificates that had been in use since Windows 8. This was a full trust-chain rollover, not a routine patch.

Why Did Boot Balk Afterward?

After the update, Flo6 failed to boot. The reason was a mismatch between the new firmware keys and the bootloader signatures. Windows had already staged boot components signed with the 2023 certificates. But the firmware update reset the trust chain. The system no longer recognized the bootloader as valid. Secure Boot rejected it, and the system dropped into firmware setup.

Recovery and Realignment

Once the firmware finished installing those new keys, Windows rebuilt its boot entries. It aligned its bootloader with the new DB. The system re-entered User Mode and Secure Boot resumed normal operation. Flo6 booted successfully again. The trust chain was restored, and the system stabilized.

Along that seemingly simple path, however, I had to reboot Flo6 at least a dozen times. Maybe more than that: I kinda lost count. At one point I had to pop the CR2032 CMOS battery. At another, I unpowered the GPU so the system would be forced to reset GOP stuff during a next restart, destined and designed to fail. Along the way I worked through nearly ever aspect of the ASRock board’s Secure Boot capabilities, setting things back to rights.

Lesson Learned

Firmware updates that modify Secure Boot keys are not routine. They change the foundation of system trust. If the OS and firmware are not aligned, boot issues can result. Understanding how PK, KEK, and DB work helps prevent surprises. Always check BIOS release notes for Secure Boot changes before flashing.

The Flo6 incident shows how a UEFI flash can affect more than performance or features. It can change the system’s trust model. With Secure Boot evolving, it’s more important than ever to understand what firmware updates really do.

Secure Boot has definitely  made life more interesting here in Windows-World. I’ve just ordered an MSI MAG Tomahawk B550 board to replace the ASRock model. Hopefully, it will show itself more robust in the face of Secure Boot changes. We’ll see…

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

Spectrum Router Roadblock Diagnosed

2 Comments

Sometimes, the biggest obstacles in tech aren’t the bugs in your code. Rather, they’re the invisible hands meddling with your network traffic. I recently ran into one such gremlin while trying to install the .NET Core 3.1 Desktop Runtime on a Windows machine. What should have been a simple download turned into a multi-device diagnostic rabbit hole, all thanks to a Spectrum-supplied SAC2V1A router and its overzealous filtering behavior. After I looked intently at its behavior, this spectrum router roadblock diagnosed itself through its (lack of) formatting. It was weird, though…

Once Spotted, This Spectrum Router Roadblock Diagnosed

Things started innocently enough. I needed the .NET Core 3.1 Desktop Runtime for a legacy app. I grabbed the download URL from Microsoft’s official archive and pasted it into Chrome. Instead of a download prompt, I got a blank page with a single, cryptic line of text:

GatewayExceptionResponse

This was odd: it included no HTTP error code, no branding or sourcing, and no explanation. Just that one-liner. I tried again in Edge. Same result. Then I fired up PowerShell and used Invoke-WebRequest. Still the same string. At this point, I suspected something was intercepting the request — but what?

The Plot (or Confusion) Thickens…

I tried the same URL on a second Windows machine. Same result. Then on an iPad. Still blocked. That’s when the lightbulb went off: this wasn’t a device issue. It was a network issue. To test the theory, I pulled out my iPhone, disabled Wi-Fi, and switched to 5G cellular. Then came the real test: typing a 60-character URL — a delightful mix of letters, numbers, and dashes — into Safari by hand. No copy-paste. No QR code. Just raw thumb labor. After a few typos and some muttered curses, I finally got it right. And lo and behold, the file loaded just fine.

Now I knew for sure whence this anomaly issues. The file wasn’t broken or MIA. Microsoft’s Content Delivery Network wasn’t off the air. Clearly, this was a problem coming from the LAN, right at the boundary.

A Ray of Light Shines on the Culprit

With a bit of digging, I discovered the culprit: Spectrum’s Security Shield. This cloud-managed feature is baked into the SAC2V1A router. It’s designed to protect users by blocking malicious or suspicious content. Unfortunately, it seems to think that downloading an out-of-support Microsoft runtime from a legacy CDN is suspicious enough to warrant a silent block.

Let me explain what “silent block” means here. Instead of an HTTP error code or an explanatory “I can’t do that, Dave” message, Security Shield simply emits the string:

GatewayExceptionResponse

No HTML document, no context, no wrapper of any kind. It looks like some kind of escaped error message, in fact. Here’s the real gotcha: one can’t manage this router’s behavior from the web interface anymore. One has to do it through an Android or iPhone mobile app. For the nonce, I’ll forgo that dubious privilege (though I could tackle it on the iPad, where I can at least run an external Bluetooth keyboard). Now that I know what I’m seeing, and why, I can live with this once-in-a-while weirdness.

If This Happens to You…

Should you ever see GatewayExceptionResponse pop up in tiny print at the upper left-hand corner of an otherwise blank browser, you’ll know what it means. The router is gatekeeping what it thinks is a dangerous resource from entering your LAN. I found a different download source (dotnet.microsoft.com) and grabbed what I  needed. You should be able to sniff out an alternative if you really need it. If you don’t this could be your clue to leave it alone.

And boy, howdy, is that ever the way things occasionally go in Windows-World. You ask for something, and get a cryptic response in return. Then, you figure out what it means and go forward from there. Case closed!

Facebooklinkedin
Facebooklinkedin
Hardware Reviews, Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Why Switch One 2020 Mobo for Another?

Leave a comment

I’m surprised. I’m actually considering replacing a 6-year-old Asrock motherboard with an MSI of the same age. Basically, I’ve gotten tired of fighting UEFI and firmware issues on the Asrock that serves as the foundation for my production desktop. I see reviews and other online evidence that the MSI MAG B550 Tomahawk Max will solve those problems. It costs US$150, which is a relatively small sum when compared to the days and days I’ve spend fighting with the Asrock board in the last month.

Why Not Switch One 2020 Mobo for Another?

I’m pretty sure I can take Flo6 apart, swap mobos, and get back up and running in an afternoon. I’ve almost had to take the whole thing apart half-a-dozen times recently to pull the GPU, various drives (including the primary SSD), and the CMOS battery. Why not go all the way?

Simply put: I don’t feel like funding a complete rebuild into a new system right now, given prevailing costs for RAM and SSDs. I can make this switch for another US$150, versus US$2,650 for a similarly equipped i714700K based build.

That’ll have to wait for the general exchequer to charge up a bit. Maybe next year? For now, I’ll be happy to get a system that boots properly, and handles Secure Boot without major issues. Let’s see what happens, shall we? I’m giving it a try…

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness