Category Archives: Device drivers

Firefox Update Fixes Weird Cursor Ripple

I’ve got to admit, I was misled this morning. After updating my NVIDIA Studio driver for the 3070Ti GPU, I noticed a strange “ripple” behavior around the on-screen cursor in Firefox. This occurred as I was scrolling inside today’s new posts and threads at ElevenForum.com. After reloading the graphics driver (WinKey+Shift+Ctrl+B), no change. So I asked Copilot: “Do I need to reboot?” “Nope,” it responded, “a Firefox update fixes weird cursor ripple” thanks to a fix for a DirectComposition code path error when using NVIDIA cards. It worked!

How Firefox Update Fixes Weird Cursor Ripple

A well-advised principle in troubleshooting relies on answering the question “What changed?” That’s what had me ready to blame the new NVIDIA driver as soon as Firefox got wonky. After taking advice from Copilot, I noticed further that the cursor ripple was indeed limited only to Firefox. It didn’t show up in Chrome or Edge, nor in other Windows apps. If it had been the GPU driver, all would have been affected.

Thus, I’m glad I thought to ask Copilot rather than start rebooting or rolling back the driver. Turns out the cause was obvious, indeed, but related to the specific program I was running as it interacted with the NVIDIA driver. Here in Windows-World, it’s wise not to overlook the obvious. But it’s also wise to cast a wider net, so as not to blame the obvious when something else could be — and in this particular case, was — at fault.

All’s well that ends well. I’m happily using my updated system. And Firefox — where I usually work to create this WordPress content — is working correctly now, too. Bonus: updating the browser is much faster than a driver rollback, and faster than a reboot. Good-oh!

Facebooklinkedin
Facebooklinkedin

Flo6 Gets Unghosted, Loses 183 Drivers

When I switched my production PC, Flo6, from the ASRock to the MSI motherboard on March 21, I left a large crew of ghosts behind. In this case, a ghost is a no-longer-used driver that remains in the driver store even though it’s out of service and irrelevant to the new installation. Thankfully, Copilot helped me remember and find Uwe Sieber’s outstanding Device Cleanup Tool. It specializes in identifying and removing such ghosts. After using the tool, Flo6 gets unghosted, loses 183 drivers (!), and gets considerably slimmed down.

How Flo6 Gets Unghosted, Loses 183 Drivers

At first I tried a tool named GhostBuster. It showed me I had 399 drivers installed on Flo6, of which up to 193 could be removed. But I couldn’t actually make it remove anything. So I asked Copilot for a different option, among which I recognized Uwe Sieber’s aforementioned tool. It worked, too!

Sieber’s Device Cleanup Tool shows ONLY drivers that may be removed. So I removed all of them. Of the 194 in that collection, 11 came back after a reboot (you can see them in the lead-in screencap). That’s how I got to the 183 number for the count of drivers removed from Flo6 overall. I used PowerShell to calculate before and after sizes for the DriverStore. It started out at 10.63 GB, and dropped to 7.87 GB after cleanup. I like that!

One of the consequences of moving from one mobo to another without a clean install is that this kind of cleanup is needed. One of the advantages of that swap is that I didn’t have to clean install the OS. What can I say? I was in a hurry! Here in Windows-World, these are the trade-offs and the consequences we must learn to accept.

Facebooklinkedin
Facebooklinkedin

Two Checkboxes Means 12X Faster

I plugged a Samsung 990 Pro 1TB NVMe into the Thunderbolt 5 port on my Lenovo ThinkPad P16 Gen 3 mobile workstation. ICYDK, TB5 promises up to 80 Gbps bandwidth. The 990 Pro is one of the fastest consumer NVMe drives money can buy. I expected fireworks. I got a firefly. Fortunately, I determined that clicking two checkboxes means 12 faster results. This comes from foregoing quick disconnect and enabling write caching. Let me explain…

Exploring: Two Checkboxes Means 12X Faster

As shown in the lead-in graphic, CrystalDiskMakr tells the ugly truth. As you can see on the left hand side, read speeds looked good. But writes are stuck in what I’d charitably call “USB 2.0 territory.” Something was very, very wrong — and it wasn’t the hardware. Results come from CrystalDiskMark 9.0.2 x64 software.

Now, look to the right, you can see that write speeds jumped significantly, while read speeds stay more or less the same. Indeed, the Thunderbolt 5 (TB5) link and Acasis TB501Pro enclosure weren’t the whole bottleneck. Sequential writes jumped from 473 to 5,943 MB/sec for a 12.6X speed boost.. Even more amazing: 4K Q1T1 writes leapt from 1.04 to 110 MB/sec, for a 105X gain.

All this came from two little checkboxes, on the Policies tab from the Properties window for the Acasis TB501Pro enclosure. Deets follow…

Two Related Settings in DevMgr Do the Trick

Here’s the 30-second procedure:

  1. Open Device Manager → expand Disk drives → right-click your external NVMe → select Properties → click the Policies tab.
  2. Switch from “Quick removal” (the default) to “Better performance.” This unlocks the write caching option that’s otherwise grayed out.
  3. Check the box for “Enable write caching on the device.” This is the setting that actually turns on write caching.
  4. Click OK, then rerun your benchmarks and enjoy the results.

Both settings are required. Selecting “Better performance” alone without the write caching checkbox won’t deliver these numbers. You need both.

Here’s the Tradeoff

Windows defaults to Quick Removal for a good reason: it protects against data loss if you yank a drive without ejecting it first. With Better Performance and write caching enabled, you must use “Safely Remove Hardware” before unplugging, or you risk losing data still sitting in the write cache.

That’s the tradeoff. For a stationary workstation drive that stays plugged in during work sessions, it’s a no-brainer. For a drive you hot-swap constantly throughout the day, think twice. I’m going for maximum speed on backups and restores, so I’ll make myself remember this tradeoff if I need to unlplug the NVMe enclosure.

The Results Could Still Be Better

I’m still of the opinion that — as I opined in my Feb 20 blog on this topic — that buying a TB5 NVMe enclosure isn’t worth the added expense. TB4 enclosures cost about US$100 less, and deliver nearly the same performance as TB5 (it’s a 10-15% difference at best). Doubling the price for a modest gain just doesn’t make sense. TB5 shines for video and networking. For storage links, not so much, because controllers basically limit links to PCIe x3/x4 levels.

That’ still true today. But I was pleased to get much more out of my rig once I made the enclosure behave more like a USB drive and less like a USB stick! Here in Windows-World you sometimes have to take your wins where you can find them…

Facebooklinkedin
Facebooklinkedin

Rolling Back Fingerprint Reader Driver

I have to laugh at myself a little ruefully. In checking over my Canary test platform just now — the snazzy little ThinkPad X12 Detachable Gen 1 hybrid tablet — I found the too-familiar BEX64 error in the mix. To those not already aware, this flags an out-of-bounds memory access, often from a driver or an associated dll. In this case it was the notoriously picky Synaptics Fingerprint reader. After looking over driver dates and versions, I realized my driver was newer than the official Lenovo offering. Thus, rolling back fingerprint reader driver was exactly the right thing to do. But there was a problem, also of my own making…

The Problem with Rolling Back Fingerprint Reader Driver

I’m relentless about using Driver Store Explorer (RAPR.exe) to clean up old drivers. Needless to say, that means the Rollback driver button in the fingerprint reader’s properties sheet was greyed out. Of course, that’s because the older driver had been removed from the Store. So I had to visit Lenovo support and grab the driver from there. Easily done, armed with the unit’s Serial Number thanks to Lenovo Vantage.

Another complication then presented. Because I was replacing a newer driver with an older one, I had to uninstall the new before attempting to install the old. Why? Because Device Manager doesn’t allow older drivers to over-write newer ones as a matter of policy. That is, Windows enforces this to prevent accidental regressions or security downgrades, so it refuses to overwrite a newer driver with an older one unless the newer one is removed first. An uninstall gets the previous driver out of the way, so the new install can proceed successfully.

All’s Well That Ends Well

I’m 100% confident that the driver swap worked. I’m expecting the fingerprint reader to behave well going forward. What makes me so confident? After installing the driver, I logged out and then used the selfsame fingerprint reader to log back in. It worked, and read my right index fingerprint from the already-defined biometric data at its disposal.

If there had been any issues with compatibility or workability, Windows Hello would have forced me to start afresh. That would mean proving my identity with a PIN, password, or other acceptable data. Then, I’d have had to re-scan my fingerprints to give the reader something to work with to establish my identity.

None of this happened. The fingerprint reader worked on the first try. I’m hopeful this will do away with the error documented in this post’s lead-in graphic. But as with so many other things in Windows-World, we’ll just have to wait and see what happens. Stay tuned!

Facebooklinkedin
Facebooklinkedin

Clearing X-Rite Error Proves Interesting

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

DDU Fixes GPU Driver Disasters

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

CPU Changed Boot Warning Nightmare

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

Thunderbolt 5: Video Good, Storage Bad

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

AMD Gets New Chipset Driver

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

So Long Samsung ML-2850

Over the weekend, I saw a story at Tom’s Hardware that reported MS is phasing out V3 and V4 printer drivers.  “Hmmm,” I thought, “I bet this means my 2009 vintage monochrome laser printer is included.” Copilot confirmed that it’s time to say so long, Samsung ML-2850. It runs V3 printer drivers and MS is halting support for same, like now.

Succession Plans After So Long, Samsung ML-2850

The printer still works fine. And it still works — for the time being, at least — with Windows 11. But it’s just a matter of time before it won’t work any more. That might hit as early as whenever 26H2 hits public release. Or it might last as long as 27H2. But its days are now officially numbered.

Here’s my plan: I’m going to use up the laser cartridge(s) I have at my disposal. When the ML-2850 runs out of toner, it’s toast. At that point, I’ll drop it off at Goodwill, where I routinely recycle my used electronika.

How long does that give this device to remain in use here at Chez Tittel? I might print 100 pages of output a month on this printer, max — probably less. So it could be 6 months or more  before I pull the plug and pack it off to Goodwill. Let’s see what happens, shall we?

But Wait, There’s More…

My Dell 2155cn is also facing obsolescence, but it qualifies as a V4 driver, not V3. So I’ve probably got another year or two before it, too, goes off to Goodwill for lack of driver support. What will I buy next? I’m thinking something like the HP M455dn, which is a low-end business class networked color laser printer that retails for US$550-800 depending on bells and whistles. Or whatever its equivalent may be when I exhaust my final set of CMYK cartridges for that printer (I’ve got a set of spares, and CMY all ahow 100% in the Dell Printer Hub’s toner status display, with B at 80%).

I’ve got at least 2 years left on that printer, it seems. Then, I’ll buy another. Interesting note: it will probably be the last printer I ever purchase, seeing as how the Samsung has lasted 17 years, and the Dell more than 13. It seems that obsolescence comes calling long before the hardware itself runs out. That was also the case for my Apple LaserWriter 1, purchased in 1985 and still running like a champ when I gave it away in 2005. For all I know, it’s still running today — that thing was built like a battleship.

MS Changes Its Tune (Added 2/25/26)

The news is out all over the place that MS is NOT dropping support for older V3, V4 printers and their drivers. Looks like they’re just limiting what OEMs can do to update or improve such drivers. The roadmap page that had promised deprecation is changed. At Windows Central, Zac Bowden quotes MS as follows:

“Windows has not ended support for legacy printer drivers. If your printer works with Windows today, it will continue to work, and no action is required,”

I guess that means this was a false alarm, of sorts. I’m still planning to retire the Samsung and Dell printers, and replace them. But the urgency is definitely dialed down. Change is the unvarying attribute of life here Windows-World. In this case, change is good!

Facebooklinkedin
Facebooklinkedin