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.

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.

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!