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

Ongoing Reboot Issues Affect RDP

Leave a comment

I’m still struggling with reboot issues on Flo6. Lately, I have to go through the infamous “new CPU detection” alert, then deny it, before I get into Windows 11. After multiple such reboots just now, I elected to stay logged in and get some work done. No such luck: my ongoing reboot issues affect RDP. On the way to a working session, I got the mysterious error window you see as the lead-in graphic.

Why Do Ongoing Reboot Issues Affect RDP?

It seems that multiple successive reboots in Windows 11 can impact RDP. This can lead to stale RDP capability caches, stale virtual device handles, TPM/Hello falling shy of full initialization, mismatched channel GUIDs, and more. In short, things get shook up and need to settle down.

What’s interesting — and amusing — about this error is that it’s not really an error. Closer inspection reveals it carries error and extended error codes that are null (0x0) in value. And indeed, right after the error window popped up, an RDP session into P16  opened up and worked like a champ.

What Happened Here?

Though it’s reported as an authentication error, it actually occurred during virtual channel negotiation between Flo6 and P16. Naturally, that indicates both devices were working just fine, thanks, and trying to get together. Copilot speculates — and I concur — that the most likely culprit is a Windows Hello redirection problem. (That’s mostly guaranteed by my turning fTPM off on one boot to kick start that process, then turning it back on.)

Boy howdy, things do sometimes get strange here in Windows-World, though. On the whole, I’d rather have a bogus error that fixes itself (or isn’t really an error) than have a serious glitch that requires further troubleshooting. I’ve had enough of that already today, thanks very much!

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
Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 10, Windows 11

Resetting CMOS Has Its Hurdles

Leave a comment

You’d think it would be dead easy. And to be fair, on some motherboards it is. But popping (or replacing) a CR2032 3V coin battery — especially when resetting CMOS — has its hurdles to overcome. At my age, clear visibility can get interesting. Then, there’s often limited space inside the PC case to reach the darn thing. In dealing with recent Secure Boot (and related CA 2023 boot certificates) recently, I’ve been reaching for the CMOS battery rather more often than not.

OK, Resetting CMOS Has Its Hurdles: Name Some…

Beyond the two already noted (visibility and space), I also bumped into various other impedimenta, including:

  • Removal techniques: new sockets may not yield to a fingernail, so I found a small flat-head jeweler’s screwdriver helpful
  • Timing: most guides say to leave the PC alone after popping the battery for anywhere from 10 seconds to 5 minutes. I made sure I had something else to do before removing the battery and erred on the “too long” side of things. Seemed to work.
  • Reinsert the old or replace with a new: If it’s been more than 3 years since I replaced the battery (or I can’t remember) I’ll replace rather than reinsert a CR2032. They typically cost US$5 or less, so if I have to remove it anyway, why not replace it, too?
  • Making room: On at least a couple of desktops, I have to remove the GPU just so I can SEE the CMOS battery holder. On any given laptop at least one deck has to be removed; sometimes other assemblies (e.g. keyboards or storage modules) must also go.

But when a PC goes truly off the rails — especially when BIOS or UEFI becomes inaccessible or non-responsive — a CMOS reset can often set things back to rights. That’s why I find myself digging for my replacement stash from time to time, so I can put a fresh one in to replace the older one at the same time.

Nothing says resetting CMOS has to be easy, here in Windows-World. But lots of times, it’s a necessary step in the troubleshooting process. So it goes…

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

Thunderbolt 5: Video Good, Storage Bad

2 Comments

I finally laid hands on a Thunderbolt 5 NVMe enclosure this week. I shouldn’t have bothered, though I learned something important. Aping Alex Karras’s unforgettable character Mongo in Blazing Saddles, I have to say that for Thunderbolt 5: “Video Good, Storage Bad!” Let me explain.

Why Say for Thunderbolt 5: Video Good, Storage Bad

TLDR version: the channel is fast, but PCIe tunneling bandwidth peaks out at PCI 3.0 x4 levels. I tested a blazing fast Crucial T705 NVMe inside a brand-new Acasis TB501Pro NVMe enclosure (it cost me US$200+tax). It underperformed both the Samsung 970 EVO and the Crucial P3 NVMes I also tried out in that same box.

How can this be? Easy: The current TB5 controller generation from Intel — code name Barlow Ridge — includes a PCIe endpoint block that handles storage transfers to/from the TB5 USB-C port on the PC side of the connection. It’s hard-wired as PCIe 3.0 x4, which limits effective bandwidth for the link to somewhere around 3-4 GBps. Thus, there’s no real advantage in this generation of hardware in buying a TB5 NVMe enclosure.

Indeed, performance from a TB5 NVMe enclosure with a Barlow Ridge controller is the same as the USB-C port on my otherwise mind-blowing ThinkPad P16 Gen 3 laptop (which uses the same controller for TB5/USB4.0 v2). This isn’t going to get better until a next generation of controllers comes out, hopefully with a faster PCIe tunnel to boost NVMe access. This hardware doesn’t do what I wanted and hoped it would: offer 6-7 GBps speeds for external NVMe storage devices. That won’t change until Intel builds something faster for PCIe access.

In the meantime, save your money: you’ll get the same performance out of a TB4/USB4 NVMe enclosure as from this newer model, for around half the price. I’m sending mine back to Amazon, thankful for its “failed to live up to expectations” return policy. Sigh.

 

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

Fixing Failed MSA Remote Login

Leave a comment

Every so often, I run into Windows 11 behavior odd enough to make me scratch my head. Occasionally, I’ll observe that my Microsoft Account (MSA) logins work perfectly at the local console. But they fail constantly if used within Remote Desktop Connection. The error? A familiar one: ‘Your credentials did not work. The logon attempt failed.’ Today, I’ll explain what worked for me when fixing failed MSA remote login.

In the meantime, I’d been working around this issue by setting up a Local account named “LocalOnly.” You can see it mentioned in the lead-in graphic for this blog post. If my upcoming technique doesn’t restore your MSA’s remote access as it did mine, you can use a local account to remote into a balky remote host if your MSA won’t work.

Refusal of Known, Good, Working Login

You may see this message while trying to RDP into a Windows 11 machine using an MSA. If so, you know how frustrating it is. Especially when you know those credentials are correct, and you can use them locally, no problem. What gives?

As it turns out, the answer lies in a complex and sometimes fragile identity stack that underpins Windows 11’s user authentication . Let’s unpack what’s going on under that hood.

Windows 11’s identity model for MSAs is built on three interdependent layers:

  1. SAM (Security Account Manager) – The local account database. It stores user SIDs (Security Identifiers) & basic account metadata.
  2. WAM (Web Account Manager) – The token broker that handles cloud authentication for MSAs. It’s responsible for storing and refreshing tokens so services like RDP can validate your identity.
  3. Ngc (Next Generation Credentials) – This layer handles Windows Hello and TPM-tied credentials, like PINs & biometric logins.

When all these layers are working and cooperating, things go swimmingly. Sometime though, particularly on Insider builds where MS is messing with this identity stack, things can get weird. Over time changes can mean an MSA works locally but not remotely.

A Swicheroo Is Key to Fixing Failed MSA Remote Login

Here’s what was happening on my ThinkPad X380 Yoga. I could log in locally using my MSA. But RDP logins would consistently get refused with the error message that serves as the lead-in graphic. After ruling out more obvious causes (e.g. network issues, RDP settings, firewall rules) I thought about the situation. Because local login worked, SAM and Ngc layers were probably OK. That presented WAM as a likely cause.

The fix, then, was simple. I rebuilt the WAM token cache, to make sure all pieces harmonized. Here’s what I did:

1. Log in locally using MSA
2. Visit Settings > Accounts > Your info
3. Change to “Sign in with a local account instead”
4. Sign out, or Reboot PC
5. Login locally using local account name/pwd
6. Visit Settings > Accounts > Your info
7. Change to “Log in with a Microsoft account”
8. Reboot PC

The switcheroo undid the link between the MSA and the account, made it local, then re-established a new connection. That completely rebuilds the whole infrastructure, including the WAM.

After that switcheroo (MSA > Local > MSA) RDP worked fine from my Flo6 primary desktop into the X380. The odds are good this technique will work for you, if you get caught in this situation. Here in Windows-World, a switcheroo sometimes works wonders. It did here, anyway!

 

 

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

AMD Gets New Chipset Driver

Leave a comment

Here I go again. I read this morning on Neowin that AMD had dropped a new version of its chipset drivers, including the B550 in my Flo6 and RyzenOfc desktops. Time for an upgrade! I found what I needed at the Chipset Driver Release Notes 8.01.20.513 page (a 62.5MB download named amd_chipset_software_8.01.20.513.exe). After applying that file, AMD gets new chipset driver upon reboot. What happened on my ASRock system was a little more vexing…and complicated. Let me explain…

After AMD Gets New Chipset Driver, Comes a Reboot

The UEFI on my ASRock B550 Extreme4 motherboard is a little tetchy. Whenever the firmware or drivers get touched (updated or replaced), it tends to hang on a black screen after a reboot intended to flush out old stuff and bring in new. Sure enough, that’s what happened after the AMD chipset installer fired off a restart with my express permission.

I had to do a deep cold start to bring the motherboard back to life. That meant:
1. Hold the power button down until the system turns off
2. Turn off the PSU
3. Hold the power button down another 10-15 seconds to discharge any capacative devices
4. Turn off, then unplug the power cord from the PSU
5. Wait 2-5 minutes for everything to turn itself completely off
6. Plug the PSU back in, turn on its power switch
7. Use the front power switch to start the PC back up
Fortunately, that worked and the unit came back to life.

Checking the Install

I’m learning to make doubly-darned sure that an update actually gets applied, thanks to some recent misadventures with Secure Boot. I visited Device Manager and made sure no yellow triangle warnings popped up, nor did anything appear under the always-annoying “Other Devices” heading.

At Copilot’s urging, I also checked the install dates for all of my AMD drivers. Copilot also confirmed that those dates matched the latest ones in the afore-linked release note (and hence, should be current).

I used this handy PowerShell one-liner to elicit the data shown in the next screencap:

Get-WmiObject Win32_PnPSignedDriver |   Where-Object { $_.DeviceName -like “*AMD*” } |  Select-Object DeviceName, DriverVersion, DriverDate

Here’s the resulting output:

After checking these against the release notes, reported dates = current dates.

It looks like the chipset update got properly applied. Copilot tells me other UEFIs will reboot after a chipset update without the 7-step polka the ASRock board needed. I wish I had another AMD system around here to verify that claim. But here in Windows-World we don’t always get what we want. Good enough for now, I guess!

Facebooklinkedin
Facebooklinkedin
Uncategorized

Secure Boot Recovery Means New Media

1 Comment

Here at Chez Tittel, I’ve been on something of a Secure Boot tear lately. Late last week, it dawned on me that this might require a change in recovery media, too. I checked: it does. Indeed, MS spells out the notion that secure boot recovery means new media in a couple of MS Learn Documents:

Basically, this boils down to the following data points, all of which determine whether or not recovery media will work properly after enabling Secure Boot:

  • Recovery media must use MS-signed UEFI bootloaders
  • Bootloaders signed with a certificate trusted in db
  • Bootloaders signed with the old 2011 CA blocked in dbx
  • Updated WinRE images (incl. new recovery media) signed with the 2023 CA

What Secure Boot Recovery Means New Media Comes Down to…

Simply put: once a PC has secure boot enabled and reports the presence of CA 2023, it needs matching secure boot media for recovery and repair. Older media won’t work because it lacks the new CA 2023 certificate. Bootloaders will fail, and/or WinRE won’t run. This will provoke a “Secure Boot violation” error or “invalid certificate” message in the bootloader. Sounds bad, eh?

The fix is easy, as long as you’ve turned Secure Boot on, and have installed the CA 2023 certificate (Garlin’s scripts at ElevenForum do this job nicely). With all these pieces in place, your current runtime meets the afore-stated requirements. Then, you can use Windows built in “Create a recovery drive” feature to build new recovery media to match this new state. Done!

Here in Windows-World when things change the supporting infrastructure must change to follow suit. Today that means generating fresh, new recovery media to match Flo6’s “secure boot on, CA 2023 installed” state. Takes only a few minutes, but means that future recovery efforts are far more likely to succeed. Good-oh!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness