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

Rolling Back Fingerprint Reader Driver

Leave a comment

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

Understanding UEFICA2023Status=NotStarted

Leave a comment

With the introduction of the Windows UEFI Certificate Authority 2023 (CA‑2023), Microsoft updates the Secure Boot trust chain to enhance platform security. As part of this transition, Windows systems may report a registry value under the key HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing named UEFICA2023Status. This value reports the status of the Secure Boot servicing task that migrates systems to the new CA‑2023 trust model. Understanding UEFICA2023Status= NotStarted is important, because it doesn’t mean CA2023 is not in use in the running Secure Boot environment. Let me explain…

What UEFICA2023Status=NotStarted Means

There are two reasons why UEFICA2023Status can take a value of NotStarted. The obvious one is when the CA-2023 certificate is ready to be added to the Secure Boot value stores, and the Servicing Task hasn’t yet been scheduled or run. The other, as I’m about to describe happens when the Windows PC is already up-to-date. Huh?

The UEFICA2023Status value can take on several states, including NotStarted, PendingReboot, Completed, and Failed. A common misconception is that a NotStarted value signals failure to apply the CA‑2023 update. In reality, this value might also mean that the Secure Boot servicing task has not been triggered. Why? Because the system already meets all necessary criteria for CA‑2023 compliance, and that task need not be run.

Specifically, Windows only initiates this servicing task if all of these three conditions are met:
1. The system firmware does not already trust the Microsoft UEFI CA 2023.
2. The EFI System Partition (ESP) does not contain a bootloader signed by the CA‑2023.
3. A servicing stack update or cumulative update requires the migration to complete.

If the system firmware already includes the CA‑2023 certificate and the ESP contains a CA‑2023‑signed bootloader, Windows deems migration unnecessary. In such cases, the registry value remains NotStarted, which is both normal and acceptable. Even so, it took me aback when I checked this value and saw that status (see lead-in graphic). It spurred me to investigate, and led to this very blog post.

As it happens, the BIOS/UEFI flash I conducted to get the MSI MAG Tomahawk B550 motherboard working updated Secure Boot and included the CA-2023 certificate data as well. And, somewhere along the way the EFI partition got rebuilt to include the CA-2023 signed bootloader. My desktop, Flo6, simply doesn’t need Windows to run the UEFICA2023 update task.

Verifying the EFI Bootloader Signature

It’s easy to confirm that the system is booting with a CA‑2023‑signed bootloader. Indeed, one need only examine the signature of the boot manager located on the ESP. This typically resides at S:\EFI\Microsoft\Boot\bootmgfw.efi (where S: is the mounted ESP). Using PowerShell, execute the following one-liner command:

Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List *

If it’s current, the output shows the [Issuer] as Windows UEFI CA 2023. (Otherwise it shows as Windows UEFI CA 2011.) Seeing CA 2023 here confirms that the firmware uses a bootloader signed with the updated certificate authority.

Comparing with the OS Copy

Windows also maintains an OS copy of the boot manager at C:\Windows\Boot\EFI\bootmgfw.efi. This file is not used for booting but may be referenced during servicing operations. It is common for this file to remain signed by the older Microsoft Windows Production PCA 2011 certificate. This does not impact Secure Boot functionality, because the firmware uses the ESP copy. We’ve just confirmed the the ESP copy is current and correct for CA-2023.

This Time, NotStarted Is All Good

Appearances to the contrary notwithstanding, a UEFICA2023Status value of “NotStarted” does not always indicate a problem. Instead, it can simply reflect that the system complies with the Secure Boot requirements for CA‑2023 (and got there before MS could). We verified the ESP bootloader is signed by the Windows UEFI CA 2023. We also confirmed that the firmware trust store includes the appropriate (2023) certificate. Passing these checks means that users can be confident that the system is operating within the latest, current Secure Boot regime despite this “interesting” status. No further action is required unless future updates say otherwise.

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
Uncategorized

Alexandrine Solution Fixes ThinkStation Diagnostics

Leave a comment

In reviewing Reliability Monitor for my peppy and capable ThinkStation P3 Ultra Gen 2, I saw recent repeated APPCRASH errors. If you could drill down into the lead-in graphic — as I did — you’d see 3  between March 11 and 14. So I asked Copilot to tell me more about this error. I learned that this utility is recommended, not required. I also learned that what’s blowing up reflects some kind of telemetry error when the app tried to phone home. So I uninstalled it. This Alexandrine solution fixes ThinkStation Diagnostics (think: Gordian knot) and smooths out my reliability ratings.

How the Alexandrine Solution Fixes ThinkStation Diagnostics

In this context I’m reminded of the well-known DCOM Event 10016 error, which pops up dozens to hundreds of times a day in Windows 10 and 11. It’s not really an error, it’s the result of a design choice that tries a series of component object model (COM) and distributed COM (DCOM) components as it performs routine tasks such as running shell components, search indexing, UWP apps and background services. It appears as an error, even though the actual work to which such errors are tied actually succeeds. Noise, in other words.

In the same vein, the ThinkStation Diagnostics (TD) software is:

1. Recommended, not required
2. The “critical error” relates to the software’s operation, not the system it monitors
3. Copilot reports that Lenovo documents numerous cases where TD fails this way owing to external device voltage issues, unsupported cables or dongles, power state transitions (sleep/resume)

Indeed the error is something on the back end, not in the system itself, and doesn’t really signal an actual problem. Ironically, it’s the system for reporting problems that’s itself causing problems.

Noise, Not Signal Makes Alexander Right

Nobody could untie the Gordian knot, so they couldn’t get in the door, either. Alexander cut it off, and got the door open right afterward. I’m taking the same approach with this tool. It’s not because I don’t want it to tell me useful stuff; it’s because I don’t want it to crash for uninformative reasons.

Here in Windows-World, there’s always a certain amount of noise to go along with valid signals. When I feel like the noise is swamping the signals, I’m glad to remove a source of such noise. There are plenty of ways for me to find out what’s going on, using other means. Basta!

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

PS Version Bump WinTerm Oddity

Leave a comment

As is my usual practice, my workday starts off with a cruise over the mini-fleet of PCs here at Chez Tittel. I look for upgrades, updates, changes, and glitches. Today, I ran into something interesting on the Lenovo ThinkPad P16 Gen 1 Mobile Workstation. A PowerShell (PS) upgrade happened — and succeeded — even though its parent WinTerm session shows WinGet reporting “Installation abandoned.” That’s the source of this particular PS version bump WinTerm oddity. Let me explain…

Exploring PS Version Bump WinTerm Oddity

As you can see in the lead-in screencap, the left-hand WinTerm pane is running PowerShell v7.5.5. You can also see that WinGet gets going on a v7.6.0.0 upgrade, but reports “Installation abandoned” at its apparent conclusion. Indeed, most readers might be tempted to conclude from this that the installation failed. Not so!

As you can see in the right-hand pane, opened after the apparent WinGet failure, the PS version there is 7.6.0(.0). The update succeeded but it can’t show itself in the parent pane for a very good reason. PS v7.5.5 is running that pane, and the developers didn’t include logic to halt that process and swap in a new version as part of the way that PowerShell works.

It’s a kind of Catch-22 (“How can you see you have flies in your eyes, if you have flies in your eyes?” as Orr asks in the famous WWII novel). With the older version running, you can’t really get the newer one to report itself right there at that moment. But as the right-hand pane shows, you need only open a new PS Session and presto! the new version is up and running therein.

Self-Update Is a Tricky Thing

This is an age-old gotcha in computer science. When the thing being updated is also running (and indeed, running the update tool in use), certain compromises and workarounds are needed to prevent things from falling over. For PowerShell, that means reporting a cancelled installation even though the installation itself completes and succeeds. The session that did the work simply can’t see and report on that particular change, because it itself would have to change to do that. Start a new session, and a new and changed context lets that happen.

Here in Windows-World, change is a constant. When the changer itself is changing, things get interesting. WinGet’s report of a “cancelled installation” for PowerShell shows how a specific compromise happens at runtime when PowerShell participates in its own update process. Fun!

 

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

WinGet Versions May Affect Installs

Leave a comment

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

Why WinGet Versions May Affect Installs

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

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

Is It a Version, or an Instance?

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

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

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

26220.8062 OOBE Grants New Naming Tools

Leave a comment

Amidst my excitement about Restore Point controls in Settings in the latest Beta build yesterday, I missed some other cool new capabilities. Indeed, the Build 26220.8062 OOBE grants new naming tools to installers. As you can see in the lead-in graphic, that means setup now includes a “Name your device” pane with input fields for:

  • Device name: installer can specify device name, instead of the prior MS penchant for long, auto-generated machine names
  • User folder name: installer can specify the base account’s folder name (previously, up to the first five characters in the base MSA)

Good Thing 26220.8062 OOBE Grants New Naming Tools

In the past, one of my typical post-install tasks would be to replace the auto-generated machine name with something more informative. For desktops, these would be DESKTOP-XXXXXX, or for laptops LAPTOP-XXXXXXX, with a mix of 7 alphanumerics (e.g. DESKTOP-UU1KCDG or LAPTOP-AB12CDE). I usually go with something shorter and more descriptive (e.g. Flo6, P16, X380, etc.).

Also, I’ve generally shied away from attempts to rename an account’s user directory because of the number of steps and amount of work involved. (See this ElevenForum.com tutorial to see what I mean.) Of this task Copilot opines:

You can rename the user profile folder, but it’s advanced and risky — follow a tested tutorial step‑by‑step and back up first.

And, FWIW, it too recommends that very same tutorial as the best step-by-step guide to this somewhat tortuous task. Nice that MS has finally made all that effort unnecessary. I’ll be glad when it makes its way from this Insider Preview into more general distribution.

Here in Windows-World, the little things sometimes count (and take more time and effort) than they otherwise might. Kudos to MS for adding these controls; shame on them for not doing it 20 years ago.

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

Build 26220.8062 Settings Integrates RPs

Leave a comment

Last Friday, MS released a new Beta Channel build to Insiders. In these insider previews, things of interest do pop up from time to time. Methinks one particular new capability in that release will interest readers. Namely, Build 26220.8062 Settings integrates RPs (Note: I abbreviated Restore Points as RPs here, for brevity). You can see what this looks like in the lead-in screencap. This is fascinating, and I’ll tell you why…

What’s Noteworthy, as Settings Integrates RPs in Build 26220.8062?

Over the past decade, MS has been surely moving functions from Control Panel to Settings. While that pace has been glacial, this marks major movement in that long-persisting icecap. You used to have to work through the “System Protection” tab in the System Properties Control Panel item to handle restore point status and access. No more. As the lead-in graphic shows, it’s now integrated into Settings > Recovery. And there’s more…

If you click the “View or edit” (Restore Points) button at the right of the “Point-in-time restore” item shown above, you’ll get a sub-menu that lets you:

  • Turn RP capture on or off
  • Manage RP frequency (default is “Every 24 hours”)
  • Manage RP retention (default is 72 hours)
  • Fix restore point disk usage
  • Access a list of available restore points (with time stamps)

Here’s that that looks like on my X380 Yoga test PC:

From what I can tell, the upgrade turns RPs on by default. Notice they already consume 7GB of disk space.

This is a major shift in Windows functionality. I checked and the old standby — easily run as SystemPropertiesProtection.exe — remains available in this build. I guess MS will offer them side-by-side for a while as is their usual practice.

Big doings in this latest Beta release. Nice to see another big chunk of Control Panel capability make its way into Settings. Here in Windows-World, that counts as “real news:” now you know!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Networking, Recent Activity, WED Blog

ASUS Router Triggers Security Review

2 Comments

In reading ARS Technica, I couldn’t help but observe that a major exploit around the KadNap is hitting ASUS routers around the world. “Hmmm,” I thought to myself, “Don’t I have one of those?” Indeed I do. But I’m pleased to report that it’s operating in AP-only mode, has the most current firmware available, and not susceptible to drive-by or external attack. Given how many similar devices have been pwned, I’m happy that when ASUS router triggers security review, the overall results are positive. Or at least, not overly scary…

ASUS Router Triggers Security Review:
Now What?

I couldn’t help but notice I bought this device back in 2018. It’s definitely past the “age of replacement!” So now, I’m looking around for something else to take its place. Copilot recommends multi-node mesh devices, but they’d have to integrate built-in switch capability with 2 or more additional RJ-45 ports to be worth installing.

Good news! Many models for Wi-Fi 6E and 7 include two or more 2.5 GbE ports. That lets me use existing RJ-45 wallplates to accommodate them, and lets me retain connectivity to already-present wired devices. Sounds like a plan!

Now all I have to do is come up with the funding. Here in Windows-World, where’s there’s a will — and the money — there’s almost always a way. I’ll add this to my “to buy, and to do” list!

 

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

Stuck Inside Boot Alert Kills Whole Day

Leave a comment

I mounted a full-throttle attempt to fix my “new CPU detected” boot warning, and lost a day to wandering in the wilderness. You’ve seen this screenshot before, in my February 27 post. I saw it a LOT more yesterday through at least 15 cold boots, plus various changes. Indeed getting stuck inside boot alert kills whole day, as I try to put my flaky startup situation right.

Why Stuck Inside Boot Alert Kills Whole Day

I’ll admit it: it was my own damn fault. I had to turn TPM off to attempt the warning breakout, but mistakenly also turned Secure Boot off as well. Big mistake. I’m *STILL* trying to recover from the latter, though I’ve managed to fix the former.

Along the way what wasted hour after hour was the impact of trying to boot in a half-open, half-closed Secure Boot environment. I kept getting stuck at Post Code 00 (nothing happened), Post Code 22 (graphics won’t initialize). I had to pop the CMOS battery out twice yesterday to reset the runtime to recognize all the hardware. Once I even had to disconnect all USB, network, and display peripherals.

A Trying Day Here at Chez Tittel

Chasing my tail is not always my idea of fun. Chasing the same trail of gotchas and glitches I’ve chased at least twice before is downright discouraging. But today, the machine booted (with the alert warning shown) and I’m up and running. I’m going to try one more time to get into UEFI, turn on Secure Boot (my only remaining hurdle to seal things back up) and see what happens.

Wish me luck. I’m going to need it. Here in Windows-World, there may not be enough time to do it right, but there’s always plenty of time to do things over and over … and over again until we get them fixed. Stay tuned: I’ll keep you posted.

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness