Category Archives: Troubleshooting

Insider stuff, Recent Activity, Troubleshooting, WED Blog

Device Zombies Roam Among Us

Leave a comment

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

  • T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
  • X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
  • Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
  • X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

    1. Remove them from the list while they’re still under my control
    2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
    3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.

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

Flo6 Mobo Switchover Succeeds

Leave a comment

On Thursday and Friday of last week, I continued to fight with warm boot issues on my primary Flo6 desktop. The ASRock UEFI stubbornly refused to synch up the MS updates for Secure Boot with its own internal, stored values. Net result: I couldn’t restart Flo6. I could only traverse the shutdown/startup cycle through a deep, cold boot that sometimes required a CMOS reset. After lunch Friday, I took the plunge and tore the PC apart to switch out the ASRock B550 Extreme4 for an MSI Mag Tomahawk B550 WiFi Max. To my great relief and delight, that Flo6 mobo switchover succeeds admirably. That said, I started after lunch Friday and finished after 9M Saturday nite. Phew!

Lessons Learned, as Flo6 Mobo Switchover Succeeds

I made a couple of interesting mis-steps along the way that slowed things down, but the overall process was pretty straightforward. The teardown was easy, but it reminded me how much I now depend on reading glasses for close-up work, since last fall’s cataract surgery.

In putting the new build together, I saw that I’d failed to remove the clear plastic sticker on the CPU cooler during the previous build. Have to laugh, but the results are amazing: no sticker plus a fresh coat of thermal paste took CPU temps down from mid-50s to low-60s to a steady 31°C (Source: Speccy; HWiNFO shows various temps ranging from 32 to 42°C). All show serious improvements over the old build!

Putting the old parts onto the MSI Tomahawk board is where things got interesting. That board offers only LEDs for CPU. DRAM. VGA and BOOT.  I missed the two-digit POST code display on the ASRock mobo, which was more intelligible and easier to read. My first mis-step was mispositioning the 5800x CPU. I was 180 degrees off on the first try. Easily fixed, but took time.

My second mis-step was to put the GPU in the secondary PCIe slot. For some reason I was scared of the metal clad primary. But the PC wouldn’t POST that way, so eventually got that straightened out (the VGA LED did its job). The third stumbling block wasn’t a mis-step, it was more of a design flaw in the MSI board. It wouldn’t start up with more than 2 of the 4 orignal RAM modules (32 GB each) in place. That was a pure trial-and-error exercise.

All the Stops along the Way…

I also had to flash the UEFI (though they still call it BIOS flashing) before I could get past recognizing the CPU. This works with neither CPU nor GPU installed, from a specially formatted USB 2 flash drive. It’s like magic that the board can DIY this process, but it worked like a champ. From that point on, I moved from one proper set-up step to the next. CPU first, GPU second, and proper RAM configuration last.

Note: getting the RGB connector to seat properly on the mobo pins was the most physically challenging part of the build. Close second was working with RAM modules right up against the massive ThermalWright Assassin CPU cooler. But it all got sorted, by guess and by gosh.

Eventually (around 6:30 PM Saturday), I got the setup to boot and it took me straight into Windows, running the same image I’d been using on the old ASRock mobo. Boy, was I relieved to see that happen. And now, for some clean-up notes and good news. Read on…

Booting into Windows, and Beyond…

Once I got into Windows, I had to adjust for the mobo change. To activate Windows 11 Pro, I had to re-enter the same MAK it had already been running on (who knew?). To switchover from the old ASRock to the new MSI drivers, the system loaded an MSI Center app. It cheerfully offered to load “all” necessary drivers, but gave me control over which ones I chose. Needless to say, I skipped the fluff and stuck to device drivers and useful utilities only.

Then I ran Settings > Windows Update, which caught up other key drivers. A fresh run of the Logi app brought back my wireless mouse (I’d been forced to plug in a wired mouse during set-up because I mistakenly grabbed an MS wireless mouse instead of the Logi model, LOL).

Checking Secure Boot and CA-2023

The following image triumphantly confirms that with the current UEFI and recent MS updates in place, Secure Boot and certificates took care of themselves. I didn’t have to do anything!!!

The first PowerShell (PS) command [confirm-SecureBootUEFI] shows it’s in place and working. The second PS command tells me that CA-2023 is in place and in use. That was really the whole reason for the mobo switch, so I’m tickled to death it worked like it was supposed. Added bonus: I can restart, shutdown, and even use “shift+(Settings > Power Button > Restart) to get into the Windows Recovery (WinRE) environment. In short, Windows boot now works just like it should, and Secure Boot is properly doing its thing.

It was a long time coming, and cost me US$150 for the MSI mobo. But God: it was worth it. Case finally, finally closed. I’m thrilled!!!

Facebooklinkedin
Facebooklinkedin
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

Clearing X-Rite Error Proves Interesting

Leave a comment

I’ve got a terrific new loaner unit from Lenovo, a P16 Gen 3 Mobile Workstation. I’m still learning my way around this powerful beast of a laptop, as I discovered this morning. After login, I couldn’t help but notice that the built-in X-Rite Color Assistant failed — namely it opened a dialog box that told me the app couldn’t run because of an “unexpected error.” Mildly disturbing, and not terribly informative. Indeed clearing X-rite error proves interesting, as I first try–and fail–to fix the app through a basic uninstall/reinstall maneuver. Then I notice something…

Why Clearing X-Rite Error Proves Interesting

While I was checking over the P16 Gen 3 for clues, I noticed that Lenovo Vantage had a new firmware update pending. “Hmmm,” I wondered: “Maybe a firmware update (and reset) will also make X-Rite happy?” I quickly installed same (and then waited for the usual update process to grind to completion, and the post-install reboot to finish).

Guess what? The firmware update did the trick! After the reboot, I was able to launch the X-Rite Color Assistant. And it turns out it’s a “background app” on that Lenovo model (which uses a software or virtual color control, because the unit lacks a built-in color sensor). So I had to go through the Notification area, and right-click on the app to get it to open.

Below, you can see the About info from the app itself. According to Copilot, the UEFI/firmware refresh helped to bring X-Rite back to life because it resets the basic runtime environment, including the GPU to system connection. Good to know!

After a quick UEFI reset, X-Rite Color Assistant ran without error.

Here in Windows-World, the right ingredients for a happy and working laptop include the underlying firmware and drivers, as well as the OS and its software. Luckily for me, by fixing the lowest level stuff, the higher-level app came back to life. I’ll count this one as a win.

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
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
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
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, 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