All posts by Ed Tittel

Full-time freelance writer, researcher and occasional expert witness, I specialize in Windows operating systems, information security, markup languages, and Web development tools and environments. I blog for numerous Websites, still write (or revise) the occasional book, and write lots of articles, white papers, tech briefs, and so forth.

NVIDIA Extends ARM on Windows’ Reach

Just a couple of weeks ago, Lenovo sent me the Qualcomm X2-based Yoga Slim 7X Gen 11 laptop. Over the weekend, NVIDIA upped the ante with a Computex announcement of its RTX Spark CPU, also ARM-based. Developer in collaboration with MediaTek, this new CPU family, aka N1 and N1X, shows that NVIDIA extends ARM on Windows’ reach. Indeed Microsoft has announced a “Surface Laptop Ultra” build around this silicon, and ASUS, Dell, HP, Lenovo and MSI are also on the bandwagon. Acer and Gigabyte will follow shortly after that, and we’ll have both laptops and desktops running RTX Spark to choose among. Big news!

What NVIDIA Extends ARM on Windows’ Reach Means

Let me be clear about what’s going on with this upcoming architecture and systems that will use it. It’s aimed squarely at the top end of the market. I’m guessing such systems could easily cost upwards of US$5K, because they are aiming at high-end creators and AI developers.

Here’s a list of noteworthy features that NVIDIA and the OEMs are touting as relevant to potential buyers of such top-flight PCs:

  • Up to 6,144‑core Blackwell RTX GPU for high‑performance graphics, AI acceleration, and workstation‑class compute in thin‑and‑light designs.
  • 20‑core Arm‑based Grace CPU (co‑developed with MediaTek) delivering strong performance‑per‑watt for mobile and small‑form‑factor desktops.
  • Up to 1 petaFLOP FP4 AI compute enabling local execution of large AI models, agentic workflows, and advanced inference without cloud dependency.
  • Unified memory architecture (16–128GB LPDDR5X) shared between CPU and GPU, reducing bottlenecks and enabling massive 3D scenes, large‑context LLMs, and high‑resolution media workflows.
  • Ultra‑low power envelope (single‑digit watts to ~80W) allowing OEMs to build ultra‑slim laptops with all‑day battery life while retaining workstation‑class performance.
  • Full RTX software stack support (CUDA, TensorRT, DLSS 4.5, OptiX, Reflex, G‑SYNC) for creators, developers, and gamers on Windows.
  • Native support for on‑device AI agents via NVIDIA OpenShell and Windows 11 optimizations, positioning PCs as proactive “teammates” rather than passive tools.
  • High‑bandwidth NVLink‑C2C interconnect (600 GB/s) between CPU and GPU for low‑latency, high‑throughput compute.
  • Advanced media engines including 4:2:2 hardware encode/decode, AV1 encoders, and Blackwell‑class video pipelines for 12K editing and pro‑grade content creation.

A LOT to Take In, MORE Left to Understand

Whoa! That’s a lot of capability with a pretty rarified set of target buyers. Given current RAM and storage pricing, and rising costs for PC hardware in general, it’s clearly a small sliver of the market. But it’s got huge potential, and could ultimately redefine how Windows works — for a certain subset of users/consumers.

I think it’s pretty cool. I hope I’ll get  a chance to check one out later this year. In the long run, though, what will make the difference is how and when such special capabilities trickle down to garden-variety PC users. I’m intensely curious to watch this unfold, and see how it all plays out. Stay tuned: I’ll keep you posted!

Facebooklinkedin
Facebooklinkedin

Windows Outgrows 100 MB ESP

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:

Name Year ESP (MB)
X380 2018 100
X12 Hybrid 2021 100
P16 Gen 1 2022 100
Tsp3Ultra2 2024 260
P16 Gen 3 2025 260
AsusSnap 2025 260
Yog7X2 2026 450

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!

Facebooklinkedin
Facebooklinkedin

WinRE Ignores Inactive HDMI Output

I guess it figures. If you examine yesterday’s blog post carefully, you’ll see it includes an obvious iPhone shot of a Windows boot screen. I’d hoped to replace it with a real screencap. Instead, I learned something interesting: my AGPTEK HD Video Capture device works fine with Windows OS running; not so with WinRE/WinPE at the helm. That’s because WinRE ignores inactive HDMI output ports thanks to its slimmed-down minimal graphics. Let me explain…

Why Say: WinRE Ignores Inactive HDMI Output

Simply put, if the runtime environment doesn’t require HDMI graphics, WinRE doesn’t use them. Given that the ASUS Zen14 has a perfectly good built-in display, with its own video channel, WinRE doesn’t feed any signals to the external HDMI port when it’s running.

My AGPTEK HD Video Capture box will cheerfully record any signals sent its way, once its “Record” button is pushed. It writes output to a UFD, from whence it may be copied and edited. I could have used it to capture a frame from said video showing the boot screens I wanted, but the box couldn’t grab them.

What WOULD Work?

It turns out I need an active frame-grabbing device not a passive, pass-through capture device if I want to grab WinRE and other WinPE-based screens through the HDMI port on the A14. Most of them cost between US$240 and 450, whereas the AGPTEK cost me US$65. Here in Windows-World, once must make sure to pay for what one needs. Otherwise, when one gets what one has paid for, it may not suffice to meet them! Live and learn, I always say…so obviously, I’ve learned that I need to buy another box!

 

Facebooklinkedin
Facebooklinkedin

ASUS Snapdragon Shows Odd Boot Anomaly

Here is a puzzle that took me longer than I care to admit to fully unpack. I built a recovery USB — clean DISM export, proper bootloader, everything by the book — set it first in the UEFI boot order, and rebooted an ASUS A14 Zenbook expecting to land in a familiar Windows Recovery Environment. Instead, I got the ASUS recovery stub. Every single time. I moved the USB higher in the boot order. I tried the firmware boot menu. I watched the machine apparently select the USB and then, silently and without apology, drop me into ASUS’s own mini-recovery UI anyway. The drive was not defective. The boot order was correct. The machine just did not care. This is my reason for saying: ASUS Snapdragon shows odd boot anomaly.

Getting Past ASUS Snapdragon Shows Odd Boot Anomaly

What I kept landing in was not Microsoft’s WinRE. It was ASUS’s recovery stub from firmware. It’s a minimal launcher, typically just a few hundred megabytes, that presents three or four tiles: Reset this PC, ASUS Recovery, and Advanced options. It looks vaguely like WinRE. It shares some ancestry with winre.wim. But it is ASUS’s gatekeeper, not Microsoft’s recovery environment, and it exists specifically to intercept the boot process before you can get anywhere else.

Here is the mechanism. ASUS, like most Tier-1 OEMs, configures its UEFI firmware with a hardcoded recovery boot path that fires during the BDS (Boot Device Selection) phase. It hits before the standard UEFI boot manager even looks at the user’s boot order. The firmware scans the internal NVMe for a partition stamped with a specific GPT partition type GUID — not the ordinary Microsoft Basic Data GUID, but a dedicated Recovery GUID or a custom OEM namespace. When it finds that partition, it hands control to the stub immediately. Your carefully ordered boot menu is consulted afterward, if at all. The USB was never really in the running.

Secure Boot adds a second layer of obstruction. Let’s say your hand-built USB carries an unsigned or self-signed bootloader (common with DISM-assembled media not signed against Microsoft’s KEK). Then,  the firmware rejects it silently and falls through to the next trusted entry in its internal list. That entry is the ASUS stub. So even when the BDS phase does get as far as examining external media, an unsigned USB is invisible. The machine looks like it’s ignoring you. It is, technically, but for a specific cryptographic reason (yes, really).

The WIM Recompression Tax

Once you understand why your DIY USB is being locked out, it helps to understand what the OEM actually ships in its place. It also explains why making a genuine ASUS recovery drive takes the better part of an hour. It starts with WIM compression. Microsoft’s stock winre.wim uses LZX compression and typically lands somewhere between 500 MB and 1 GB on disk. Manageable. Sensible. But ASUS’s customised image, once you add the recovery launcher, platform drivers, UI payloads, and potentially a full factory image, can balloon to several gigabytes of uncompressed data before anyone has touched the compression knob.

When you kick off the “Create ASUS Recovery Drive” process in MyASUS, what actually happens under the hood is a DISM /Export-Image /Compress:max operation (or its functional equivalent)  applied to an enormous source WIM. Maximum LZX compression, and on newer builds you may even see solid-block LZMS compression, which squeezes harder but runs even slower.

Here’s the critical detail: WIM compression in DISM is largely single-threaded. It reads every file, applies the compression algorithm, writes the output, and verifies integrity as it goes, all on one logical core (yes, really). On an otherwise fast NVMe-equipped laptop, that process still takes 40 to 55 minutes, not because the machine is slow, but because the algorithm is doing an enormous amount of intense, serialised work. The hardware isn’t at fault; the workload is.

Getting to USB-Based (Alternate) Boot

Here’s where the rubber meets the road. Getting external media to boot on an ASUS machine requires working around the firmware, not just the boot order. There are two reliable paths. First: disable Secure Boot in UEFI setup (DEL at POST, not F8 — more on that distinction in a moment). With Secure Boot off, unsigned bootloaders no longer get silently rejected. Second: on older platforms with CSM support, enabling CSM forces a legacy BIOS boot path that bypasses the UEFI BDS handoff to the stub.

The Bottom Line: Build Custom Recovery Media

Whether you use the MS supplied “Create a recovery drive” facility, or turn to the MyASUS toolbox to do likewise, the best way to protect an ASUS Zenbook A14 is to build recovery media from that PC. As I learned through a series of failed recovery attempts with other, supposedly generic, all-purpose recovery media, that stuff doesn’t fly inside the Zenbook’s firmware envelope.

Learn from my mistake, and follow this advice as soon as  you can. Otherwise, you too, will fumble around until you find the MyASUS in WinRE tool that does cloud-based image reconstruction instead. If all you want is WinRE running a command prompt, that’s not a good alternative. Do it now: don’t delay!

The Secure Boot Perspective (2 Days Later)

I just ran the Garlin scripts on the recently rebuilt ASUS Zenbook A14. Looks like one benefit of a constantly updated cloud-based restore is the ability to slipstream new stuff in (or replace older, outdated images with newer, current ones). The concluding status report from  that check script is pretty telling:Shoot! They’ve even revoked the CA-2011 certificate. Good stuff!!!

Facebooklinkedin
Facebooklinkedin

Bizarre ASUS Disk Layout Is Intentional

Wow! Wow! Wow! What an adventure I just went through. After examining the weird, seemingly fragmented disk layout shown in the lead-in graphic, I went nuts. I decided to clean install Windows 11. That’s when I learned a bunch of stuff I didn’t want to know. Chief among those things (more to follow): the bizarre ASUS disk layout is intentional. Indeed, it came back after typical clean install manuevers failed repeatedly. Ultimately, I used the “My ASUS in WinRE for USB” app to bring the unit back to life.

Why Say: Bizarre ASUS Disk Layout Is Intentional?

Short answer: because it came back on its own after running a cloud restore on the Windows 11 image on the Zenbook A14. Longer answer: the unit simply wouldn’t boot into any kind of standard recovery media that I could build by hand. I wasted more than a day trying to brute force my way into a clean install, only to realize ASUS has barred the “boot to USB” door very tightly and narrowly. Indeed, I’m very, very glad that I was able to get the unit up and running again. I’d been contemplating a run to a nearby repair shop. I’m glad it didn’t come to that — but it was close!

I’m not sure WTF is going on, that ASUS needs nine OEM partitions on its SSD drive (the 16MB one is undoubtedly the MSR). But I’ll be darned if I was able to figure out how to get rid of them. I think there are two recovery partitions (reagentc says it’s tied to Partition 15) because one is for normal Windows use, the other for ASUS’s no-doubt murky purposes.

If It Ain’t Broke…

Honestly, I should’ve known better. The unit was behaving and peforming as expected. Just because I didn’t — and still don’t — like what I see for disk layout, doesn’t mean I should’ve taken the clean install route. Now I know better.

A painful lesson learned, a day-and-a-half spent chasing phantoms. Sounds like my idea of a good time. Here in Windows-World, I take my jollies where I can find them. Think I’ve had enough of those to last me for a while, though…

Facebooklinkedin
Facebooklinkedin

Superb Yoga Slim 7x Gen 11 Unboxing & Setup

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!

Spec Snapdragon X Elite (X1) Snapdragon X2 Elite (X2)
Launch May 2024 September 2025
CPU Architecture Qualcomm Oryon v1 (Hamoa) Qualcomm Oryon v3
Process Node TSMC 4nm TSMC 3nm (N3X/N3P mix)
Transistor Count ~20 billion ~31 billion
Max CPU Cores 12 (homogeneous, 3 clusters of 4) 18 (12 Prime + 6 Performance)
Peak Single-Core Boost 4.3 GHz (X1E-00-1DE dev SKU) 5.0 GHz (X2E-96-100 Extreme)
All-Core Sustained Clock ~3.8 GHz ~3.4–3.6 GHz (more cores to feed)
CPU Cache (L2+L3) 42 MB L2 53 MB L2 + 9 MB L3
GPU Adreno X1-85; 4.6 TFLOPS; 1,500 MHz Adreno X2-90; up to 1,850 MHz
GPU API Support DX12 (not DX12 Ultimate) DX12 Ultimate
NPU (AI TOPS) 45 TOPS (Hexagon) 80 TOPS (Hexagon, 64-bit NPU)
Memory Type LPDDR5x-8448 LPDDR5x-9523
Memory Bandwidth (peak) ~136 GB/s 152–228 GB/s (SKU-dependent)
Memory Bus Width 128-bit 128-bit
USB USB 4.0 / Thunderbolt 4 USB 4.0 x3 / Thunderbolt 4
PCIe for NVMe PCIe 4.0 (up to 7.9 GB/s) PCIe 5.0
Display Output Up to 3x 4K 60Hz Up to 3x 5K 60Hz
Wi-Fi Wi-Fi 7 (HBS Multi-Link) Wi-Fi 7 (HBS Multi-Link, enhanced)
Bluetooth Dual BT (Snapdragon Sound) Dual BT (Snapdragon Sound)
5G Optional Optional (up to 10 Gbps peak)
Security Qualcomm SPU + Microsoft Pluton Qualcomm SPU + Microsoft Pluton + Snapdragon Guardian
Copilot+ PC ✅ (inaugural platform) ✅ (enhanced)
Emulation Performance x86-32 and x86-64 via Prism Improved Prism; more native apps available
TDP / Power Envelope Up to ~80W (peak) Comparable; better perf-per-watt at 3nm
Notable SKUs X1E-84-100 (most common); X1E-80-100; X1E-78-100 X2E-96-100 Extreme; X2E-88-100; X2E-84-100; X2E-80-100; X2 Plus (6–10 core)
Review Slim 7×2 SKU X2E-84-100 (12 Prime + 6 Perf; 4.7 GHz boost; 152 GB/s)

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!

 

 

 

Facebooklinkedin
Facebooklinkedin

Explainer: Secure Boot Chain of Trust

Here’s an uncomfortable, seldom considered truth: your operating system isn’t the first thing that runs when you power on your PC. The firmware goes first. Then the bootloader. Then the OS kernel. Malware creators figured this out a long time ago. Get in early enough — before the OS loads — and you can own a machine invisibly, surviving reboots, reinstalls, and even antivirus scans. All this explains why the secure boot chain of trust is vital to modern Windows security.

The threat is real and it’s present right now. BlackLotus, a UEFI bootkit sold on criminal forums, made headlines in 2023 for bypassing Secure Boot on fully patched Windows 11 systems. BootHole exposed a critical flaw in GRUB2’s boot process that affected both Linux and Windows. PKFail (2024) revealed that dozens of device vendors had shipped products using a leaked “do not ship” test Platform Key — meaning the root of the entire trust hierarchy was compromised straight out of the box. Then, in January 2025, ESET researchers disclosed CVE-2024-7344: a Microsoft-signed UEFI recovery application that could silently load unsigned bootkit code — on any UEFI system, regardless of whether Secure Boot was enabled. Microsoft pulled the vulnerable binaries in the January 14, 2025 Patch Tuesday update.

Boot-time attacks aren’t theoretical. They’re happening. Under-standing Secure Boot’s chain of trust is the first step toward knowing whether your defenses are actually holding.

Understanding the Secure Boot Chain of Trust

Think of the chain of trust as a series of checkpoints at the border. Each checkpoint must vouch for the next before anything is allowed through. No vouching, no entry, and the boot process stops dead.

In technical terms: every component in the boot sequence verifies the digital signature of the next component cryptographically before handing off execution. The firmware checks the bootloader. The bootloader checks the OS kernel. The kernel checks drivers. If any link in that chain can’t be verified — wrong signature, no signature, a signature that’s been revoked — the process stops. Your PC refuses to proceed rather than run untrusted code. That’s the whole point. Always safe means never sorry, even if it also means a PC that won’t fire up and run.

The chain only works, of course, if the first link is trustworthy. That’s where the UEFI key hierarchy comes in.

The Key Players: PK, KEK, db, and dbx

UEFI Secure Boot manages trust through four interlocking databases baked into your firmware. Get familiar with them — they come up constantly whenever something goes wrong at boot time.

Key / Database Full Name Role
PK Platform Key Root of trust. Set by the hardware manufacturer. Controls who can update KEK.
KEK Key Exchange Key Authorized to update the signature databases (db and dbx).
db Signature Database Hashes and certificates of trusted bootloaders allowed to execute.
dbx Forbidden Signatures Database Revoked signatures and hashes. Anything here is blocked unconditionally.

The PK sits at the top. Your motherboard manufacturer owns it. Below the PK, the KEK authorizes who gets to update the lists of trusted and forbidden signatures. In practice, Microsoft functions as the de facto Secure Boot Certificate Authority for the consumer PC ecosystem. Nearly every machine you buy ships with Microsoft’s certificates pre-loaded in db — exactly why CVE-2024-7344 was so broadly dangerous. A legitimately Microsoft-signed binary became a usable attack vector!

Worth Knowing: PKFail and the Test Key Problem

In 2024, the PKFail vulnerability revealed that over 200 device models from multiple vendors shipped with a Platform Key originally marked “DO NOT TRUST” — a sample key from AMI’s reference firmware that was never meant to leave the lab. When your PK is public knowledge, the entire root of trust collapses.

How the Chain Is Created at Boot Time

Power on your PC, and here’s what actually happens — fast, invisible, and mostly taken for granted.

  1. The UEFI firmware initializes hardware and activates Secure Boot mode.
  2. The firmware reads the bootloader from the EFI System Partition and checks its signature against db. It also checks against dbx — if it’s there, execution stops immediately.
  3. The signed bootloader (Windows Boot Manager, for example) takes over and verifies the OS kernel’s signature using its own embedded certificates.
  4. The kernel loads and verifies signed drivers. On Windows, this is enforced through Driver Signature Enforcement — unsigned kernel-mode code is blocked by default.

Every handoff is cryptographically verified before it happens. Compromise any link — plant an unsigned binary, exploit a signed-but-vulnerable loader, sneak past a misconfigured dbx — and an attacker owns your machine below the OS waterline. That’s precisely the attack surface that BlackLotus, BootHole, and CVE-2024-7344 each exploited in different ways.

Maintaining a Strong Chain of Trust

Secure Boot isn’t a “set it and forget it” control. Maintaining a healthy chain of trust requires ongoing attention from both Microsoft and from you.

The most important maintenance lever is the dbx — the blocklist. When a bootloader is found vulnerable (as happened with a batch of 2011-era Microsoft-signed binaries in 2023, and again with the CVE-2024-7344 binaries in January 2025), Microsoft issues dbx updates through Patch Tuesday. Your firmware then refuses to execute those specific binaries even if they’re somehow placed on the system. Keeping Windows Update current is how those revocations reach your PC.

Firmware updates matter just as much. Vulnerabilities in the UEFI firmware itself require OEM-supplied updates delivered via Windows Update or manufacturer tools. The NSA and CISA have both issued guidance recommending that organizations periodically audit their Secure Boot configuration — confirming the correct keys are enrolled, the dbx is current, and no rogue Platform Keys are in place (a lesson PKFail drove home hard).

Complementing Secure Boot is the TPM’s Measured Boot capability. While Secure Boot enforces what can execute, Measured Boot records cryptographic measurements of everything that did execute into TPM Platform Configuration Registers (PCRs). Remote attestation tools can then verify those measurements after the fact. Think of Secure Boot as the bouncer at the door; Measured Boot is the security camera logging who actually got in.

Why the Chain of Trust REALLY Matters

Secure Boot isn’t perfect — BlackLotus, BootHole, PKFail, and CVE-2024-7344 all proved that. But “not perfect” is a long way from “useless.” It raises the cost and complexity of boot-level attacks significantly, and when the ecosystem keeps the revocation databases current, it closes known attack paths quickly.

Do yourself a favor: open System Information (msinfo32), find BIOS Mode (should read UEFI) and Secure Boot State (should read On). If either is wrong, fix it. Keep your firmware updated. Keep Windows updated. The chain of trust is only as strong as its weakest, most-neglected link — and that link is usually sitting right between the keyboard and the chair. Here in Windows-World keeping track of key security concerns is darned important. The Secure Boot chain of trust should be at the top of everyone’s list.

Facebooklinkedin
Facebooklinkedin

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

MS Readies Copilot Key Remap

How often do I use Copilot? Multiple times a day, sometimes for hours at a go. How often do I use the Copilot key on a Copilot+ PC to access same? NEVER (I tried it out on an early laptop, saw it worked, and never used it again). I’m pretty sure most other users work the same way. Thus it came as no surprise and something of a relief to read news that MS Readies Copilot key remap in some upcoming Windows 11 update.

Why MS Readies Copilot Key Remap

This plan surfaced in a recently published Microsoft Support Note entitled ” Understand updates to the Copilot key on Windows devices,” Copilot finds no publication date for this item, but guesstimates it appeared on May 18  (yesterday, as I write this post).

Here’s how that note starts out:

Starting in 2024, hardware manufactures released new Windows 11 devices that include a dedicated Copilot key that provides quick access to Copilot experiences in Windows. This Copilot key sometimes replaces the Right Ctrl key or Context Menu key on select devices.

Customers who rely on the Right Ctrl key or Context menu key for keyboard shortcuts or assistive technologies (such as screen readers) experienced some challenges to their workflows when using these devices.

The important info comes next, and explains how things will work once this update appears:

A Windows 11 update will ship later this year that will add a setting option to let you remap the Copilot key to act as the Context menu key or Right Ctrl key. When available, you can find this setting in: Settings > Bluetooth & devices > Keyboard

What Does Copilot Key Remap Mean?

It’s an implicit ACK from MS that some (or many) people don’t use the key. Better, however, it’s a means for those who need the key that used to sit where the Copilot key now rests will get an official way to restore it (or rather, its functions as the Right CTRL or Context menu key) on their keyboards. Good enough for me!

When will this appear? MS isn’t saying yet. But they wouldn’t dangle it out there if they weren’t already working on it. My best guess is months, not longer. I’ll keep an eye on things and let you know when more news is available.

And here’s a concluding irony: I’m current working on a Logitech  Wave Keys keyboard on the Flo6 desktop. No Copilot key here, and I don’t miss it at all, not even one little bit.

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