Yesterday, I launched Intel Driver & Support Assistant (aka Intel DSA) on my Lenovo ThinkStation P3 Ultra Gen 3. Then I watched it sit there, seemingly forever, with Intel DSA hanging at “Scanning your system…” interminably. The spinner spun. And spun. And kept right on spinning.

First, I did what any reasonable Windows veteran does: I refreshed the browser tab. Then I restarted Intel DSA. Then I cleared the browser cache. Then — because hope springs eternal — I uninstalled and reinstalled the whole tool. Nothing worked.

Finally, after roughly 20 minutes of increasingly creative nattering about, I decided to actually dig in and find the culprit. Ultimately, I was able to determine that Hyper-V hangs up Intel DSA. When Hyper-V is running (with one or more VMs in tow), DSA gets stuck. When Hyper-V is off and its VMs shut down, DSA does its thing.

Discovering That Hyper-V Hangs Up Intel DSA

My first instinct was Task Manager. I scanned the process list for anything suspicious chewing up CPU or disk I/O. Nothing obvious jumped out — DSAService.exe was running, but it was barely registering any activity. Interesting.

Next, I pulled up Windows Services and confirmed that the Intel DSA Service was running and set to automatic. So the service itself wasn’t the issue. I then checked Event Viewer, hoping for a clear error message. However, Event Viewer offered nothing but a wall of routine informational noise. As helpful as usual (not much).

Then I glanced over at my taskbar — and something caught my eye. Hyper-V Manager was open. And sitting right there in the Virtual Machines list was my Windows 10 ESU VM, happily showing a Running state. I hadn’t touched it in days. I’d simply forgotten to shut it down.

That was my “aha” moment. I had a hunch. It was time to test it.

The Fix Is In — and Dead Easy, Too

I right-clicked the running VM in Hyper-V Manager and chose Shut Down — not Pause, not Save State, but a full, clean shutdown. Note state showing “Off” in the lead-in graphic: that’s what you want. Then I closed Hyper-V Manager entirely. Finally, I switched back to my browser and relaunched Intel DSA. The scan completed in about four seconds. Four seconds. After sitting frozen for half an hour!

So why does this happen? Here’s the short version. Intel DSA’s local service performs low-level hardware enumeration — it interrogates drivers, firmware, and system components directly. However, when Hyper-V has an active virtual machine running, the hypervisor layer sits between the operating system and the physical hardware. It intercepts certain hardware queries to protect the VM’s virtualized environment. As a result, Intel DSA’s scan requests can stall waiting for responses that never arrive. The tool doesn’t time out gracefully — it just hangs there, looking busy while doing absolutely nothing.

What to Do If Intel DSA Hangs on Your PC

If you’re seeing Intel DSA hanging at “Scanning your system…” with no end in sight, work through this list before you do anything drastic.

1. Check Hyper-V Manager for running VMs. Open Hyper-V Manager and look at the State column. If anything shows “Running,” that’s your prime suspect.
2. Shut down — don’t just pause — any running VMs. Right-click the VM and select Shut Down. Wait for the state to change to “Off” before moving on.
3. Close Hyper-V Manager entirely. Don’t just minimize it. Close the window completely so the management layer releases its handles.
4. Relaunch Intel DSA in your browser. Navigate back to the Intel DSA page and let it load fresh. The scan should complete within seconds.
5. If it still hangs, try the IP listen fix. Open an elevated Command Prompt and run: netsh http add iplisten 127.0.0.1 Then, restart the DSAService via Services or with net stop DSAService && net start DSAService. This resolves a separate but related port-binding conflict that can also cause Intel DSA to freeze.

With luck, DSA will get unstuck for you, too. It worked for me. Here in Windows-World that may not guarantee it will work for you to. But at least, it’s worth a try. Give it a shot!

ESP is an abbreviation for the EFI System Partition, where a PC uses its contents to boot a PC far enough along to start loading Windows. For almost as long as I can remember, that partition has been created and sized during Windows installation at 100 MB. But this is changing. Here’s a “known issue” for  KB5089549, Microsoft’s May 2026 Patch Tuesday cumulative update for Windows 11. It can fail mid-installation on systems with a critically full EFI System Partition (10 MB or less free space). What do we, and OEMs, do as Windows outgrows 100 MB ESP? Get bigger!

Other Evidence That Windows Outgrows 100 MB ESP

I polled the 7 PCs (2 desktops, 5 laptops) here in my office at Chez Tittel to check their ESPs and observed something interesting. Here’s what I found:

Notice that the ESP sticks at the 100 MB mark until 2024, at which point it jumps to 260 MB. Then, on this year’s May-delivered Lenovo Yoga Slim 7X Gen 11 (X2 Snapdragon) it jumps again to 450 MB. There’s no doubt about it: the EFI is getting bigger!

What is the ESP, Anywho?

The EFI System Partition — ESP, in the shorthand everyone actually uses — is a small, dedicated FAT32 partition that lives on GPT-formatted disks and serves as the staging ground for everything the system needs before the operating system proper gets involved. Boot loaders live there. Firmware drivers live there. UEFI utility executables live there. If the system can’t find and read the ESP at power-on, it goes nowhere. It is, in other words, foundational infrastructure — and like most foundational infrastructure, nobody pays attention to it until something breaks.

Microsoft’s own documentation has recommended a minimum ESP size of 200 MB for UEFI/GPT systems since at least the Windows 8 era, with 260 MB or larger as the preferred target for new installations. That guidance has been sitting in plain sight on Microsoft Learn for years. OEMs, however, have a long tradition of shipping machines with a 100 MB ESP because, at the time those machines were built, Windows fit comfortably within it. The margins were thin, but they existed. That era is over.

Why 100 MB Isn’t Enough Anymore

Every Windows feature update — and, increasingly, every cumulative security update — must write updated boot files, recovery sequences, and language-specific font sets into the ESP. As the Windows boot stack has grown over successive releases, the items demanding ESP real estate have multiplied: Secure Boot validation assets, BitLocker metadata, UEFI capsule drivers, and a collection of per-locale font files for the pre-OS boot interface that can alone consume several dozen megabytes. If 100 MB was ever “enough,” Windows has long since moved those goalposts.

The specific tripwire for KB5089549 is tight, but telling. Microsoft confirmed that the failure triggers when the ESP has 10 MB or less of free space remaining. On a 100 MB partition that has been hosting Windows through several years of cumulative updates, that threshold is entirely realistic. The update proceeds normally through its initial phases — progress bars, the usual theater — and then dies during the restart phase, right around the 35–36% completion mark. The CBS.log entries are unambiguous: SpaceCheck: Insufficient free space and ServicingBootFiles failed. Error = 0x70. The accompanying companion error code, 0xc1900104, surfaces during feature-update upgrade attempts and carries the same root cause. The partition is simply full.

Increasing ESP Lebensraum

The community has converged on two main workarounds, and it is worth being clear-eyed about both of them.

The first is the “fonts delete” trick. You mount the ESP using mountvol Y: /S from an elevated command prompt, navigate to EFI\Microsoft\Boot\Fonts, and delete everything inside — typically recovering somewhere between 30 and 60 MB in a single sweep. It is fast, it is effective, and it is entirely unsupported by Microsoft. The risk is real: those font files support non-English boot environments. If your machine ever needs to display Cyrillic, Japanese, or Arabic characters in the pre-OS recovery interface, you will have a bad time. For an English-only deployment sitting quietly in a US office, the practical risk is low. In any multilingual environment, it should be treated as a last resort only.

Microsoft has also offered its own short-term registry tweak for KB5089549 specifically: running reg add “HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc” /v EspPaddingPercent /t REG_DWORD /d 0 /f from an elevated prompt, followed by a reboot. This reduces the padding buffer the update engine reserves in the ESP, giving just enough headroom to slip the update through. It buys time. It does not fix the underlying problem.

The second, more durable option is partition resizing — shrinking the C: volume and extending the ESP to somewhere between 260 MB and 512 MB. Tools like MiniTool Partition Wizard (MTPW) can accomplish this from within Windows on many configurations. That said, a WinPE offline environment is the proper path since you are modifying a sometimes live boot partition. This is the correct fix. It is also disruptive, carries a non-trivial risk of data loss if anything goes wrong mid-operation, and absolutely requires a verified backup before you touch anything. Done properly, you will not need to revisit this for years. Done carelessly, you will spend an afternoon with recovery media and a sinking feeling. I experienced this myself recently on an ASUS Zenbook A14 laptop.

MS Is Mum on Remediation

Microsoft has not, as of this writing in mid-2026, provided an official, automated remediation path. There is no inbox tool that detects an undersized ESP and expands it gracefully. Ditto no Setup-phase blocker with a clear, actionable error. There is a Known Issue Rollback for KB5089549, which automatically propagates to consumer and unmanaged devices and prevents the broken update state — useful, but it leaves the machine unpatched. Enterprise admins can deploy the associated Group Policy to apply the KIR on managed fleets. None of this changes the underlying geometry of the partition. Something’s got to grow — and soon!

The other day I said it was coming. Yesterday, it arrived at my door about noonish. Today, I want to share my first impressions. TLDR version: I expected a lot from the Snapdragon X2, and I wasn’t disappointed. In today’s post, I’ll describe Lenovo Yoga Slim 7x Gen 11 unboxing & setup. In subsequent posts I’ll go into more detail. Here goes…

Digging Into Yoga Slim 7x Gen 11 Unboxing & Setup

Lenovo’s getting pretty good at the notion of low-footprint, low-carbon packaging and delivery. The box includes 2 eggshell carton style cradled for the laptop, a bamboo fiber sleeve for same, a cardboard holder for the one-piece 65W brick, which comes wrapped in a disposable paper sleeve. That last is black, and easy to miss: I didn’t even notice it until I checked it for the power rating info. Good job, packaging team!

I jostled the power switch (right edge of keyboard deck) as I picked up the unit, and it came right up with a full charge. I’m happy to report that “instant-on” remains as fast and reliable on X2 models as it was on their X1 predecessors. I logged right into the Lenovo review account and got going, and jumped into the setup process. That has its own story (complete with interesting bumps in the road). First, let me offer a table to compare Snapdragon X1 and X2 laptops:

Snapdragon X1 vs. X2: Good Gets Better

The key points to absorb from the following info are: more and faster cores, more cache, DX12 Ultimate, 80 TOPS NPU, PCIe 5.0. This laptop is noticeably faster than my 8 core Ryzen 7 5800X desktop with 64GB RAM, especially on CPU-intensive tasks. Impressive!

One Small Little Gotcha…

My only real disappointment with the review unit was that it shipped to me running Windows 11 Home. That’s because I rely on RDP (through Remote Desktop Connection, aka mstsc.exe). Thus, I had to upgrade to Windows 11 Pro to make that work. However, this is a minor beef, and one easily remedied at purchase time for an extra US$50.

Here’s the configuration Lenovo sent (aside from the already-mentioned OS): X2E Elite 88-100 CPU, 32GB RAM, 1TB PCIe Gen4 SSD, 1920×1200 OLED display. As configured, the Lenovo store currently lists the price at US$1,795.49. Comparatively speaking, I believe this is a good deal, given current prices for RAM and SSD.

Setting Up the Yoga Slim 7X Gen 11

Things got interesting right away. I made a misstep and associated my MSA with the Lenovo review account — not smart. As a result, I ran a factory reset to see what would happen. Indeed, it took about 22 minutes all told (pretty darn fast, AFAIK). That put me back into the base OOBE for Windows 11. Then, I burned an MVP key to upgrade from Home to Pro, which went amazingly fast — less than 2 minutes from hand-off to the Pro desktop. Overall, given intense non-gaming workloads, this unit screams!

Along the way, I learned that you can target ARM CPUs in WinGet using the --architecture ARM parameter and argument during installs. That helped me get the right versions of CrystalDiskMark, PowerShell 7, and a couple of other odds and ends up and running on the X2 laptop. In addition, I used a combination of PatchMyPC Home Updater and WinGet to get all the usual tools and applications up and running. On the whole, that process took about 2 hours and was pretty enjoyable.

I did hit a typical snag in getting RDP to work. Specifically, I was unable to get into the laptop (machine name: Yog7X2) using a Microsoft Account (MSA), despite various well-known fixes — namely, requiring Hello compliance for all logins, and making sure to sign in with the password at least once to get the MSA registered with the LSA. Consequently, I resorted to the equally well-known workaround of setting up a local account and using that instead.

First Impressions: Bedazzled and Enthused

I’ve actually purchased two Snapdragon X1 laptops for our household already (in 2025). For instance, I own an ASUS Zenbook A14. Meanwhile, my son has a ThinkPad T14s Gen 6 that we bought to replace a ThinkPad X390 after its display cracked. Obviously, I’m already enamored of the value proposition: decent performance, great battery life, and a slim, portable form factor. Indeed, both of us emphatically like those older models.

Surprisingly, the Slim 7X Gen 11 runs noticeably faster than most of the fleet here at Chez Tittel. To be clear, that fleet includes high-end Lenovo models like the ThinkPad P16 Gen3 Mobile Workstation and the ThinkStation P3 Ultra — so that’s a significant statement.

In addition, the unit is incredibly light at 1.17 kg (2.58 lbs). At the same time, even the low-end OLED display is brilliant and easy on the eyes. Astonishingly, reviews published so far (it’s early in the life cycle) put battery life in a range from 25 hours (mixed real-world usage) to 31 hours (local video playback), with Lenovo claiming “up to 29 hours” in its CES 2026 announcement. Naturally, I’ll see how that pans out in my own testing and usage.

All in all, this is a machine I wanted to see and use. Now that I’ve gotten started, I’m favorably disposed. Furthermore, I’m expecting my ardor and appreciation to grow as I get more time with this snazzy little laptop. Stay tuned: I plan to post three more items about this device in the next two weeks.

One More Things (Added 1 Day Later)

The Yoga Slim 7X Gen 11 also offers another feature I definitely appreciate. I concur with Michael Crider’s recent PC World story that OEMs should provide USB-C ports on both sides of their laptops for ease of access to chargers and docks in cramped conditions and on on office desktops. And guess what? Lenovo provides 3 (!) USB-C ports on this model: 2 on the left side, and one on the right. Good stuff!

Here’s a fun way to start a Monday: you fire up a PowerShell script you’ve run many times — maybe it provisions a batch of AD accounts, maybe it sweeps stale GPOs — and it simply vanishes. No error dialog. No event log entry. Quarantine warnings not provided, either. The file is just gone, like it offended someone. Which, as it turns out, it did.

The culprit? Recent changes to Microsoft Defender’s Attack Surface Reduction (ASR) rules — specifically, tightened enforcement arrived with Windows 11 23H2. And it has only grown more aggressive in 24H2/25H2. If you manage Windows endpoints for a living, this one deserves some notice.

How and Why Windows Defender May Delete PowerShell Scripts

Microsoft has been steadily ratcheting up ASR rules over the past couple of years. Two rules in particular have become dramatically more assertive: “Block execution of potentially obfuscated scripts” and the newer “Block execution from known script interpreter paths” (rule GUID 9e6c4e5a-1037-4377-92f4-2db0f7e629e7). The latter now matches elevated execution paths that have nothing to do with user shell startup, which means your perfectly legitimate admin scripts can get caught in this net.

Here’s the insidious part. Starting with the 23H2 and 24H2 Defender sensor updates, script-blocking ASR rules are now enforced at the kernel driver layer (via WdFilter.sys, Defender’s minifilter drive) — before process creation even occurs. That means scripts launched via WMI, COM+, or scheduled tasks can be silently killed or quarantined without generating an event log entry. You get no breadcrumbs. The script just doesn’t run, and the script file itself may disappear.

This has caused a wave of false positives hitting legitimate PowerShell scripts, SCOM monitoring agents, Active Directory management tools, and enterprise deployment scripts. If you experienced déjà vu reading that, you’re not wrong. In January 2023, a faulty Defender signature update (builds 1.381.2134.0 through 1.381.2163.0) caused the “Block Win32 API calls from Office macro” ASR rule to go haywire and mass-delete Start menu and taskbar shortcuts across enterprises. Microsoft had to ship a dedicated recovery script (AddShortcuts.ps1) and a taskbar repair utility to clean up the mess. Consider this the sequel — quieter but just as disruptive.

How to Recover Deleted or Quarantined Files

If Defender has eaten your scripts, don’t panic. Work through these steps in order:

1. Check Defender’s quarantine via the GUI. Open Windows Security → Virus & threat protection → Protection history. Filter by “Quarantined Items.” If your script is there, select it and choose Restore.
2. Browse the quarantine folder directly. Quarantined files live in C:\ProgramData\Microsoft\Windows Defender\Quarantine. They’re encrypted, but they show that Defender took them.
3. Use PowerShell for deeper inspection. Run Get-MpThreatDetection and Get-MpThreat to list recent detections and see exactly which ASR rule fired. To restore from the command line, use MpCmdRun.exe -Restore -ListAll followed by MpCmdRun.exe -Restore -Name <ThreatName>.
4. Add targeted exclusions. Use Add-MpPreference -ExclusionPath “C:\Scripts” or configure per-rule exclusions via Intune or Group Policy to prevent recurrence.
5. Restore from backup. If the file is gone from quarantine entirely, fall back to File History, system restore points, or your backup solution of choice.
6. For enterprise environments: check the Microsoft 365 Defender portal’s quarantine and Action Center — detections from managed endpoints often surface there even when local logs stay silent.

That leads to what I’ll call a “Pro tip” for admins to consider. Before enabling any new or aggressive ASR rule, set it to Audit mode first (value 2) rather than Block mode (value 1). Audit mode logs what would be blocked without actually deleting anything. Run it for a week or two, review the results in Event Viewer under Microsoft → Windows → Windows Defender → Operational (Event IDs 1121 and 1122), and then flip to Block. This single practice would have prevented most of the heartburn described above.

You Win Some, You Lose Some…

Let me be clear: Defender’s tighter ASR rules are genuinely good for security. Blocking script execution at the kernel level before a process even spawns is a meaningful defense against fileless malware and living-off-the-land attacks. But Microsoft badly needs to improve logging transparency when scripts get blocked at the kernel driver layer. Silent enforcement with no audit trail isn’t “defense in depth” — it’s “debugging in the dark.”

Until that gets fixed, the playbook is straightforward: keep good backups, audit before you block,  and test ASR changes in a staging ring before pushing to production. Remember: your antimalware solution is only as smart as its latest signature update. As the January 2023 shortcut debacle proved, even Microsoft’s own rules can bite the hand that feeds them. I think these just bit me. Don’t let it happen to you!

But Wait! There’s More…

In my usual ElevenForum readover this weekend, I stumbled on a thread that mentioned scripts — and an encrypted password file — disappearing from the poster’s Windows 11 PC. As I responded to that thread “This is deeply disturbing.” It just doesn’t seem right that Defender can cause scripts (and more) to vanish via rule enforcement. You need to steer around this pothole until it gets filled. Not an unfamiliar strategy, alas, here in Windows-World.

When it comes to my Microsoft Accounts (MSAs), I must laugh at what historian Hayden White unsmilingly called “the burden of history.” That is, it seems I’ve acquired quite a number of MSAs over the years. Thus, I had to shoulder that burden recently when I decided to clean things up a bit. Last week witnessed my own “great MSA massacre of 2026.” Indeed, I rid myself of 4 old MSAs and cleaned up what remained. It wasn’t exactly bloody, as such things go, but it was indeed a burdensome task.

What Spurred the Great MSA  Massacre of 2026?

As the lead-in graphic should suggest, the impetus came from devices associated with my many and varied MSAs. Indeed, I discovered numeous evaluation units from Lenovo, Dynabook, HP, MSI, and others. Some went as far back as the early 2020s.

One source of issues is that I didn’t practice good “eval return hygiene” on many loaner units. I would log in to them using an MSA, but didn’t unenroll them from device lists before sending them back. This, it seems, could cause them to persist for up to 6 months after return and presumable oblivion. At least, as far as logins from my MSA were concerned.

I spent about two weeks of concerted effort, visiting the managed devices page for my still-active MSAs. Each day, I would remove all stale entries (I call them “zombies”) only to see them pop up again. But over time, and with grim repetition, I finally consigned those stubborn devices to rest in eternal peace (hopefully).

What’s Left to Do?

I’ve got one MSA that’s a bit of a zombie itself. Its home email server was shut down last year, as its owner went out of business. I want to keep that account alive because it carries 20 years of — please don’t laugh out loud — Microsoft Solitaire history that I don’t want to lose. It’s tied to my cell number, so I can still prove my identity as long as that sticks with me, so I should be good.

I’m now shuffling all of its devices over to my primary MSA, so I can keep the ones I actually use all in one place. Going forward, I have a plan as I return eval units to Lenovo (or whomever else might send me a review unit). I’ll make sure to unenroll them from my registered device and MS Store device lists to keep things current and correct. Copilot opines further it’s a good idea to factory reset those units, too, to wipe all MSA traces. I’ll do that, too.

As IRL, in Windows-World actions have consequences. I’m doing my best to remember that using my MSA to login and play with eval units means I have to manage them more actively as they come and go. Fingers crossed I’ll do that properly from now on…

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!

In poking around the fleet here at Chez Tittel lately, I can’t help but notice that my Windows PCs seem to pick up detritus at a good clip. Nearly every time I run a tool such as Disk Cleanup (cleanmgr.exe), PC Manager, or even the ancient but still servicable UnCleaner utility, I put at least 800MB-1GB  of storage back into the free pool. One of my mottos has been (and remains): “Keep your Windows clean.” And there’s more to suggest driven by that impetus…

What Keep Your Windows Clean REALLY Means

As you can see in the lead-in graphic, even after running PC Manager’s “deep clean” facility, Uncleaner still finds another GB of trash to take out. Indeed, multiple tools often focus on multiple sources of unwanted or unnecessary stuff. Using them in combination will usually take out more trash than a single item can ferry into oblivion on its own.

But wait: there’s more! Other things in Windows besides file storage need an occasional cleanup. Here are some examples:

• Use a tool such as RAPR (DriverStore Cleaner) to remove obsolete or duplicate device drivers from the Windows driver store
• Use DISM to do likewise for the Windows Component Store (e.g. DISM /Online /Cleanup-image /StartComponentCleanup)
• Various identity and authentication cleanups, including credential manager, Windows Hello/NGC, AAD/Workplace Join, cached identity tokens, and more

I’ll blog about this final item tomorrow, because I’ve been spending a lot of time on that kind of stuff lately, and have some useful PowerShell to share along those lines. Stay tuned.

And remember: a clean Windows install is a happy and healthy Windows install. Cheers!

A routine UEFI firmware update brought unexpected trouble to the Flo6 system yesterday. What should have been a simple BIOS flash turned into a boot failure. The cause? A major change in Secure Boot keys. This event highlights how firmware updates can affect system trust and stability. As I was figuring out how UEFI flash overturned Flo6, I had to work my way through another CMOS reset, GPU disconnect, and more. Buckle up: here come the deets!

How UEFI Flash Overturned Flo6, and Killed Normal Boot-up

The BIOS update for Flo6 included more than microcode or AGESA changes. It replaced the Secure Boot Platform Key (PK), Key Exchange Key (KEK), and the Allowed Signatures Database (DB). These new keys came from Microsoft’s 2023 certificate chain. They replaced the older 2011 certificates that had been in use since Windows 8. This was a full trust-chain rollover, not a routine patch.

Why Did Boot Balk Afterward?

After the update, Flo6 failed to boot. The reason was a mismatch between the new firmware keys and the bootloader signatures. Windows had already staged boot components signed with the 2023 certificates. But the firmware update reset the trust chain. The system no longer recognized the bootloader as valid. Secure Boot rejected it, and the system dropped into firmware setup.

Recovery and Realignment

Once the firmware finished installing those new keys, Windows rebuilt its boot entries. It aligned its bootloader with the new DB. The system re-entered User Mode and Secure Boot resumed normal operation. Flo6 booted successfully again. The trust chain was restored, and the system stabilized.

Along that seemingly simple path, however, I had to reboot Flo6 at least a dozen times. Maybe more than that: I kinda lost count. At one point I had to pop the CR2032 CMOS battery. At another, I unpowered the GPU so the system would be forced to reset GOP stuff during a next restart, destined and designed to fail. Along the way I worked through nearly ever aspect of the ASRock board’s Secure Boot capabilities, setting things back to rights.

Lesson Learned

Firmware updates that modify Secure Boot keys are not routine. They change the foundation of system trust. If the OS and firmware are not aligned, boot issues can result. Understanding how PK, KEK, and DB work helps prevent surprises. Always check BIOS release notes for Secure Boot changes before flashing.

The Flo6 incident shows how a UEFI flash can affect more than performance or features. It can change the system’s trust model. With Secure Boot evolving, it’s more important than ever to understand what firmware updates really do.

Secure Boot has definitely  made life more interesting here in Windows-World. I’ve just ordered an MSI MAG Tomahawk B550 board to replace the ASRock model. Hopefully, it will show itself more robust in the face of Secure Boot changes. We’ll see…

Here at Chez Tittel, I’ve been on something of a Secure Boot tear lately. Late last week, it dawned on me that this might require a change in recovery media, too. I checked: it does. Indeed, MS spells out the notion that secure boot recovery means new media in a couple of MS Learn Documents:

• Secure boot
• Signing with the new 2023 Microsoft UEFI certificates: what submitters need to know (MS Tech Community, MSA req’d)

Basically, this boils down to the following data points, all of which determine whether or not recovery media will work properly after enabling Secure Boot:

• Recovery media must use MS-signed UEFI bootloaders
• Bootloaders signed with a certificate trusted in db
• Bootloaders signed with the old 2011 CA blocked in dbx
• Updated WinRE images (incl. new recovery media) signed with the 2023 CA

What Secure Boot Recovery Means New Media Comes Down to…

Simply put: once a PC has secure boot enabled and reports the presence of CA 2023, it needs matching secure boot media for recovery and repair. Older media won’t work because it lacks the new CA 2023 certificate. Bootloaders will fail, and/or WinRE won’t run. This will provoke a “Secure Boot violation” error or “invalid certificate” message in the bootloader. Sounds bad, eh?

The fix is easy, as long as you’ve turned Secure Boot on, and have installed the CA 2023 certificate (Garlin’s scripts at ElevenForum do this job nicely). With all these pieces in place, your current runtime meets the afore-stated requirements. Then, you can use Windows built in “Create a recovery drive” feature to build new recovery media to match this new state. Done!

Here in Windows-World when things change the supporting infrastructure must change to follow suit. Today that means generating fresh, new recovery media to match Flo6’s “secure boot on, CA 2023 installed” state. Takes only a few minutes, but means that future recovery efforts are far more likely to succeed. Good-oh!

On February 4th, I recounted the Secure Boot status of my local fleet, along with machines possessing CA 2023 secure boot certificates. At that time, I had 3 of 11 PCs with no CA 2023 secure boot certs. One also couldn’t enter UEFI with Secure Boot enabled. My secure boot report card is now perfected. All 11 machines have secure boot enabled AND CA 2023 certs in their credentials stores.

How Did I Get Secure Boot Report Card Perfected?

Short answer: time, effort and (in one case) a hardware purchase. Now for a somewhat longer answer. Both holdout machines with SB enabled, but no CA 2023 present were two ThinkPads. First, the X380 Yoga, a 2018 vintage 7th-gen Intel-based laptop. Second was X12Hybrid, a 2020 vintage 10th-gen Intel based tablet.

The same fix worked for both machines. The inestimable long-time member at ElevenForum.com named @Garlin has a terrific thread. It’s entitled garlin’s PowerShell scripts for updating Secure Boot CA 2023. It includes a script named Check_UEFI-CA2023.ps1. If you run that script it not only tells you if the CA 2023 cert is present or absent. If CA 2023 is absent, it also provides two commands to put it in place. That worked for both of my ThinkPad holdouts.

Note: The lead-in graphic for this story shows the following:
1. Invocation and output from the Check script just mentioned.
2. Execution of the reg edit and scheduled task to add CA 2023.
3. Final check string to show CA 2023 is present in the SecureBoot UEFI db (database).

The Third Holdout Proves a Bit Trickier

The old NVIDIA GeForce RTX 1070Ti installed in the upstairs ASRock B550/AMD Ryzen 5 5800X desktop named “RyzenOfc” wouldn’t enter UEFI with Secure Boot enabled. Turns out the firmware on its older GPU just couldn’t coordinate with TPM changes. I bought a Gigabyte RTX 5060 because it was compact enough to fit the smallish RyzenOfc Antec A-201 case. That got me back into UEFI where I could install the default keys and get secure boot working properly.

After that, the same Garlin script cited above also got CA 2023 into the credentials store on RyzenOfc. It’s taken a good chunk of the last two weeks, and cost me a chunk of change — I also bought a new mouse and keyboard that skips USB enumeration issues and Fn key gotchas in getting to UEFI, plus the GPU — to finish this journey.

Just for grins I checked CA 2023 status on the ThinkPad P16 Gen 3 that showed up on Monday. It didn’t have the new certs, either, so I fixed it with commands from the Garlin check script, too. All good!

But at last, all my machines are Secure Boot enabled with the CA 2023 certificate installed in that environment. What a long, strange trip that turned into. I’m glad it’s over, and I learned a LOT along the way. I also heartily recommend the Garlin scripts to anybody facing uncertainty or issues in getting CA 2023 Secure Boot certs onto their PCs. Great stuff!