Another Toolset for Secure Boot Checks

Yesterday, I read my way through the latest AskWoody newsletter. In Susan Bradley’s article “Check Those Browsers” I found reference to Secure Boot checks: “If you merely need to run a script to check the UEFI KEK, DB, and DBX Secure Boot variables, you can use this one.” Because the source wasn’t directly named, I followed that link to access cjee21’s scripts entitled Check-UEFISecureBootVariables at GitHub. And there, I found another toolset for Secure Boot Checks — and a good one, too.

Why Grab Another Toolset for Secure Boot Checks?

You can (and probably should) visit GitHub to grab cjee21’s Check-UEFISecureBootVariables. At the time of writing it’s sitting at 226 stars and was updated two days prior — such active maintenance on a niche diagnostic utility is a good thing. This is the tool you want when your first question is “What do I actually have on this machine?”

Its orientation is forensic and inspection-first. It surfaces everything inside the UEFI Secure Boot variable store: PK, KEK, DB, DBX, event logs, and XML dumps of the full variable contents. Most people working a CA-2023 compliance problem have never actually looked at those variables directly. This tool makes that straightforward.

Two specific components stand out for CA-2023 work:

  • Check EFI file info.cmd — This is the direct answer to what Get-AuthenticodeSignature lacks. Point it at an .efi file and it explicitly tells you which CA signed it (CA-2011 or CA-2023), along with the SVN, SBAT level, and raw version data. That’s the specific question you must answer, and this specific tool answers it.
  • Scan ESP for revoked files.cmd — This one scans EFI binaries on a drive against the live Microsoft DBX revocation list. If you’re checking USB boot media for compliance — a Ventoy stick, a WinPE drive, a rescue environment — this is the fastest way to know whether anything on it has been revoked.

Don’t Forget the Garlin Scripts (ElevenForum)

Cjee21’s scripts show and tell you what you’ve got. Garlin’s ElevenForum Scripts tell you what to do about it. This pair of scripts: Check_UEFI-CA2023.ps1 and Update_UEFI-CA2023.ps1, are action-oriented where cjee21’s tool is inspection-oriented. At 38 GitHub stars it’s a smaller project, but it was updated approximately two weeks before writing and recent commits show active refinement, including a fix for a bug in SVN signature data ordering. The associated forum thread is VERY active, and usually gains 2-3 pages per day.

The workflow is deliberately linear and guided: run Check_UEFI-CA2023.ps1 to assess your current CA-2023 status, then run Update_UEFI-CA2023.ps1 to fix whatever it finds. The scripts source certificates from \Windows\System32\SecureBootUpdates and the official Microsoft Secure Boot Objects repository, so you’re not pulling from unofficial or unverified sources.

A few things make the Garlin scripts especially helpful:

  • USB removable media support — It handles boot file updates for USB recovery media like Macrium Reflect drives and similar tools. This is a gap that most documentation quietly ignores.
  • Broader architecture coverage — x64, x86, arm64, and arm are all supported, which gives it wider applicability than you might expect from a community script.
  • Accessible for non-specialists — The guided, opinionated workflow means you don’t need deep UEFI expertise to use it. The script makes the decisions; you confirm them.

Complementary, Not Competitive

Again: the cjee21 scripts show you what’s what with Secure Boot on a Windows PC, at a deep level of detail. More than many of us want to know, in fact. The Garlin scripts tell you what to do about your current status, and help you set things right on installed systems and for bootable media.  A great combination, well worth exercising. Give them a try, if you haven’t already.

Facebooklinkedin
Facebooklinkedin

Intel DSA Remains Driver Install Clickmeister

I just realized that DSA was MIA on my ThinkPad X12 Gen 1 Detachable Tablet. So I installed it, then ran it. It found 3 drivers in need of updates on that device: Wi-Fi, Bluetooth, and (Xe) Graphics. In updating them, I observed that the  Intel Driver and Support Assistant (Intel DSA) remains driver install clickmeister supreme. Let me explain…

Why say: Intel DSA Remains Driver Install Clickmeister?

It’s long been my observation that using DSA requires lots of mouse clicks. This time around, installing the three drivers shown in the lead-in screencap required at least 24 mouse clicks. For the record, those drivers were (numbers at right count clicks for each one):

  • Wireless Bluetooth Drivers (9)
  • 11th-14th Gen Processor Graphics (10)
  • Wi-Fi Drivers (5)

This time around it actually took me 4 additional mouse clicks to get from item 2 to item 3, because I was installing the GPU driver for the first time. Thus, I had to reboot my system, because DSA got “stuck” on “installing” for item 2, and wouldn’t advance to item 3. Sigh. I didn’t count those “extra” clicks in my reported total.

Achieving Intel Driver Update Silence

Believe it or not, that’s the title of a blog I posted on April 27, 2023. That was another time when the sheer number of clicks involved in running DSA hit me hard. It remains noticeable. Today, it struck me as excessive. So I’m formulating this plea to the Intel DSA developers:

Please add a silent mode switch to DSA. Let users tell the tool to run the installs without requiring minutes of babysitting to get through routine maintenance.

I wonder if anybody is listening. Then, I wonder if they’ll respond. Here in Windows-World the silence can sometimes be deafening. Let’s see what happens, shall we?

 

Facebooklinkedin
Facebooklinkedin

Revo Roots Out Relics

I’ve been meaning to do this for a while. But this morning, I found the fabled “round tuit” for an app clean-up on Flo6 using Revo Uninstaller. Using that tool, I reduced my count of installed apps from 95 to 83, eliminating an even dozen items. When I claim that “Revo roots out relics,” I’m claiming that the program helps stamp out no-longer-needed (or relevant) apps quickly and easily. Let me offer some details, and an explanation…

How Revo Roots Out Relics…

The intro screencap shows a partial list of all apps installed on Flo6. When I started this clean-up adventure, I was mostly beset with two sets of relics:

  • Leftovers from the ASRock B550 Extreme4 motherboard, which I replaced with an MSI MAG Tomahawk B500 MAX in January (3/12)
  • Leftovers from the Creative Sound Blaster AE-7 I installed earlier this month, but couldn’t get to working (5/12)

The other items were a hodge-podge of odds’n’ends including:

  • AIDA64, yet another system information tool that I don’t even remember installing, and never use
  • Angry IP Scanner: an alternative to Advanced IP Scanner that I tried a few times, before switching back to Advanced…
  • CPU-ID: I don’t need the plain-vanilla one any more, because MSI provides a customized version for the MSI MAG Tomahawk
  • CrystalDiskMark 8.4.0 still installed on Flo6, even though I’m running version 9.0.2. Removed it.

That’s it. Subsequent disk cleanup on Flo6 recovered 6 GB of disk space, too.

App Cleanups Should Happen Periodically

I consider this sort of review and removal part of a good Windows PC hygiene regime. Today was my day to clean up old apps. I’m glad I did. I’ll probably do it again at summer’s end, as I tend to pick up detritus like this over time. Here in Windows-World, if you don’t need it, or can’t use it, why keep it? Out it goes!

Facebooklinkedin
Facebooklinkedin

Canary Jump Sows Predictable Chaos

After recently clean installing the 2021-vintage Lenovo ThinkPad X12 Detachable Tablet Gen 1 I decided to leave it running a production build.  That means I needed a new Canary channel test machine. So this morning, I upgraded the 2025-vintage ThinkPad P16 Gen 3 to that Insider Preview level. Unsurprisingly, this “Canary jump” sows predictable chaos. Let me tell you what happened, and what I did to recover…

Why Say: Canary Jump Sows Predictable Chaos?

No sooner did I reboot into Canary Build 26300.8246 than did all hell start breaking loose. As is my usual practice, I remoted into that PC from my Flo6 desktop — but not for long. In under less than a minute the PC crashed, and threw a slew of interesting “Critical events” as it went down. You can see them depicted in the lead-in screencap.

Of the 6 items in that list, numbers two through five are relevant. That’s because all cluster in the same minute (11:02 AM) and all are related to my remote session failing, then Windows crashing. The X-Rite Color event simply reflects the program’s unhappiness with running in a remote session (it appears again as item 6, when I start my next remote session).

The others are worth visiting in a little more detail:
• Windows stopped working comes from a bugcheck. Copilot tells me this is most likely owing to firmware or driver issues between the laptop and this bleeding edge release
• This provoked the “not properly shut down” as Windows crashed
• It culminates in the “shut down unexpectedly” as Windows turned itself off
At the start of this sequence an illegal memory reference kicked things off. This is why firmware and drivers are suspects: they’re the most likely perpetrators of such untoward acts.

Chaos Cleanup on Aisle 7!

I now understand my cleanup, had it been performed before upgrading to Canary, might have prevented the crash that occurred. I visited Lenovo Vantage, found a new UEFI update, and installed it. I ran Intel DSA, found four new drivers, and installed them. I ran the NVIDIA app, found new driver version 596.36, and installed it, too.

Now the P16G3 laptop seems to be purring right along. I’ll take it as a lesson learned (and probably re-learned) that it’s a good idea to update firmware and drivers before making major OS changes. Now that I actually stop to THINK about it, that makes pretty good sense. Even in Windows-World, it’s better to plan and aim before firing…

Facebooklinkedin
Facebooklinkedin

Timing WinGet’s Update Pipeline

OK then, I just read at WinAero that a new PowerToys v0.99.0 is out. Checking via WinGet upgrade in PowerShell it’s not yet in the pipeline. Nevertheless, the app itself is happy to grab said update from its GitHub repository, as you can see in the lead-in graphic. I’m now conducting an experiment. I’ll be checking hourly as I work at my desk, to see when that new PowerToys version comes into WinGet’s ken. Should be interesting…

What’s Involved in Timing WinGet’s Update Pipeline?

Behind the scenes, lots of things must happen before WinGet catches up, and offers the PowerToys update:
1. MS publishes the new release on GitHub (that’s done)
2. A Pull Request (PR) is sent to winget-pkgs with info about the new version, URLs, hash values, and so forth (usually automated)
3. Pull Request validation runs: automated checks verify installer hashes, check URL resolution, and validate manifest schema
4. Pull request merges into the WinGet source: a maintainer approves the package and merges it into the public database
5. WinGet CDN propagates: the updated database index appears via the winget source in related commands (show, install, uninstall, etc.)

How Long Does It Take?

Because PowerToys comes from Microsoft, its timeline is about as short as such things get. Turnaround normally takes no less than 12 hours, nor more than 48 depending on timing. If a weekend gets in the way the delay can stretch out. Ditto if issues with the manifest show themselves, or if the software being packaged shows a bug. Thus, for example, PowerToys v.0.99 has a Command Palette crash bug, and may be slowed to accommodate suitable hotfix.

We’ll see how this one goes. There’s already a new V0.99.1 version on GitHub (which includes that very hotfix). It’s in the WinGet pipeline now: let’s see how long it takes to get through, shall we?

Note Added 1:05 Later…It’s HERE!

The original post went up at 1:05PM local time. It’s now 2:10PM and a check on the P16 Gen 1 Mobile Workstation produces the following WinGet output: It’s here…

Notice that version 0.99.1 is on offer. That means the PowerToys team got its hotfixes into the package before sending it off to WinGet. Good job, @ClintRutkas and team. I am impressed.

And, now that I’m running it on the suitably-configured X380 Yoga, I see that the PowerToys upgrade also flashes an icon. Impressed again:

Facebooklinkedin
Facebooklinkedin

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

Avoiding Excess Laptop Power Drain

Over the weekend, I transported one of my ThinkPad P16 Mobile workstations to a neighbor’s house. When I unpacked the unit from its knapsack, I noticed that it was pretty warm (and so was the interior of the bag). “What’s up with that?” I wondered. I’d closed the lid, but hadn’t shut the unit down. That was on me, as a little bit of investigating clued me into what’s needed when it comes to avoiding excess laptop power drain. Let me explain…

Power Options Key to Avoiding Excess Laptop Power Drain

Here’s the skinny: by default, my ThinkPad P16 Mobile Workstations go into S0 sleep but maintain network connection. Here’s how the powercfg /a command reports that state:

Basically, the network connection stays up even though the unit itself is mostly idle. Alas, when moving the unit by walking down the street, I’m entering and exiting WiFi domains at a pretty serious clip. Indeed, I’d bet big money that on Arbor Drive, not a single house has less than one active WiFi domain (I’ve got 4, if you count low- and high-bandwidth channels for SSIDs separately). That kept the NIC kinda busy and didn’t really idle the machine at all.

Hence the item shown as the lead-in graphic for this blog post. If you go into Power Options you can change the “Close Lid” setting to hibernate. That means the network connection goes quiet when the lid is closed, and the usual network traffic that might otherwise wake the machine does likewise.

Moving Around Makes Network Connection Iffy

If a laptop is on the move, making or using network connections is a chancy business. My neighbors may have SSIDs galore, but that doesn’t mean they’re sharing passwords with me. And it looks like most of them are smart enough to require WPA3-Personal these days, so guessing isn’t productive, either.

My point is that the network connection doesn’t really do anything except waste battery power when a laptop is on the move. For transport, that means the “Hibernate when lid is closed” setting shown above makes the most sense. That’s why it’s now my preferred move, before I shove the laptop into a knapsack or briefcase from now on.

All I need to do is remember to switch from hibernate to sleep when I get somwhere I plan to be (or work) for a while, and it’s all good. Here in Windows-World, responding to local conditions is a must, especially when it comes to conserving laptop battery life.

Facebooklinkedin
Facebooklinkedin

MS Kicks Off New Insider Channels

OK, then, today’s the day. Earlier, MS promised to change up its Insider Channel line-up. This morning, MS published an item to the Windows Insiders blog entitled “We’re moving to Experimental and Beta!…” Amusingly enough, this means that the former Canary and Dev channels are collapsing into a single Experimental channel, while Beta stays Beta (at least, for now). So, of course, I had to download and install the latest Beta onto X380 to see what things looked like, as MS kicks off new Insider Channels. Let’s check…

As MS Kicks Off New Insider Channels, I Wait…

As you can see in the lead-in graphic above, the latest Beta version shows up as a “Windows 11 Insider Preview Quality Update” (Build 26220.8283). It took about 5 minutes to download, but install seems poised to take somewhat longer. It’s been 3 minutes and it’s 12% done, so that means ~42 minutes total? Gosh, I hope that’s wrong… And indeed, it got to the “Restart now” button 27 minutes later. By the time I got through everything and back to the desktop total time elapsed was 35 minutes.

To my great disappointment, the view of Insider Channels from the latest Beta release is unchanged. It still shows Canary, Dev, Beta and Release Preview channels. Here’s what I used to (and still) see:

I guess I need to stand up a Canary PC or VM and see if it shows anything different. Here in Windows-World, I’m often reminded of the old French saw “The more things change, the more they stay the same.” I’m sure change is coming, but it hasn’t made it to Beta just yet.

 

 

 

Facebooklinkedin
Facebooklinkedin

Testing Catches Copilot Errors

I’m happy to admit that Copilot makes many of my Windows adventures easier to undertake. It certainly helps a great deal with PowerShell scripting stuff. But just this morning I was reminded that it’s always smart to question — and verify — everything Copilot tells me. In testing a USB4 NVMe enclosure just now, I asked it which of the ThinkPad X12 Detachable Gen 1 left-side USB-C ports is faster, remembering that one is 10Gbps (UASP) and the other 40Gbps (TB4). It replies “the lower port,” so I run CrystalDiskMark on both to check its answer. Once again, I confirm that testing catches Copilot errors. Let me explain.

How Testing Catches Copilot Errors

Simply put, checking what Copilot tells you will either confirm that it’s correct, or show that it’s wrong. As you can see in the lead-in graphic, which places the upper USB-C port left, and the lower one at right, large reads are MUCH faster on the left. That means the upper port MUST be the TB4 one because UASP/10Gbps can’t deliver more than 1,000 – 1,200 MB/s for either reading or writing.

When I showed Copilot the CDM results, it responded as follows:

I had it backwards — apologies for the bad call. The source I pulled from apparently described the ports in board-schematic order rather than physical top-to-bottom position as you see them on the tablet. Your bench test is the definitive answer.

And if you’re seeing typical UASP numbers (~1,000 MB/s sequential) from the lower port right now, that confirms it’s the USB 3.2 Gen 2 controller — exactly what you’d expect at 10 Gbps with protocol overhead.

At least, it doesn’t fight with me when I knock it over the head with contrary results. And when it writes scripts, the PowerShell mostly either works or it doesn’t. In the latter case, Copilot may fumble around for a while but it eventually gets things right.

Trust, But Verify

It’s not unreasonable to believe much, or perhaps even most, of what Copilot tells you. But if you don’t check its work, you’re setting yourself up for trouble. It’s good at finding stuff and presenting theories and explanations. It’s by no means infallible, as I have just shown. Take that into account, when you start leaning on it for help…

Facebooklinkedin
Facebooklinkedin

Making Boot/Recovery Media CA-2023 Compliant

OK, I confess. I’m more than a little OCD in keeping my Windows PCs updated. That applies to Secure Boot as much as anything else. And recently, in bringing my mini-fleet here at Chez Tittel up to snuff, I’ve found myself with old boot UFDs and current PCs. Yesterday, I blogged about that in a post about  “Checking Boot/Recovery Media…” Today, in reading the ElevenForum threads I learned that Garlin’s check script now includes boot media status. I also learned how to make my dozen or so bootable UFDs current.

Bootloader Is Key: Making Boot/Recovery Media CA-2023 Compliant

As you can see in the lead-in graphic the file named bootx64.efi is key to compliance. If the file is signed with CA-2023, it’s good; if it’s signed with CA-2011; it’s banned. Fortunately replacing a banned file with the good version is pretty straightforward. But because Windows doesn’t keep the C:\Windows\Boot\efi folder synched to what’s actually in the EFI partition, boot files are best garnered from the latter, not the former.

The steps in the process to provide a CA-2023 signed bootx64.efi therefore go best as follows:
1. Mount the EFI partition as an accessible drive: mountvol /S S:
2. Rename the existing UFD file to .old:
rename g:\efi\boot\bootx64.efi bootx64.old
3. Copy the CA-2023 bootloader into place:
copy S:\efi\boot\bootx64.efi to G:\efi\boot\bootx64.efi
4. Unmount the EFI partition for cleanup:

Note: On Macrium Reflect rescue disks you want to copy the CA-2023 version of bootx64.efi onto bootmgfw.efi instead.

Check Your Work: Run Garlin Script

You can use the latest version (be sure to download before use) of the Garlin Check_UEFI-CA2023.ps1 script to check your work. The correct syntax for this invocation reads (be sure to Unblock in advance):

.\check_UEFI-CA2023.ps1 -bootmedia -verbose

If all goes well the output should (nearly) match what you see in the lead-in graphic. If status shows BANNED, not ALLOWED, then the bootloader is signed with CA-2011, not CA-2023.

It’s pretty easy to fix, though. Hopefully you can do what I just did and bring all of your boot media into compliance. Cheers!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness