Category Archives: Insider stuff

Copilot+ PCs, Hardware Reviews, Insider stuff, Recent Activity, WED Blog, Windows 11

Yog7X2 Revisited, 10 Days In

June 5, 2026 Ed Tittel Leave a comment

One week ago Tuesay, Fed-Ex dropped a nifty new Lenovo Yoga Slim 7X Gen 11 at my door. That’s why it’s named Yog7X2 on my network, for “Yoga Slim 7X, Snapdragon X2 model.” TLDR version of my recent experience using it as a daily driver is: “It’s a peach.” Indeed this piece of review text about Yog7X2 revisited, 10 days into my experience is no mere first look. It reflects my experience on this laptop, chewing through deadlines, long-running scripting sessions, video calls and teleconferences, and extended Copilot sessions. My report is almost entirely positive, with only a few minor nits to pick.

Re-Speccing Yog7X2 Revisited, 10 Days In

Just for the record, here’s a quick overview of what Yog7X2 brings to the party. The 7X Gen 11 runs on Qualcomm’s Snapdragon X2 Elite (X2E-88-100) — that’s second-generation Snapdragon X Elite silicon, not a rebadge of the 2024 parts. That distinction matters more than the spec sheet suggests. The first wave of Copilot+ PCs was impressive hardware wrapped around a compatibility story with certain gotchas. Two years on, most of that has quietly sorted itself out. My daily toolchain — Edge, Word, PowerShell, a handful of Win32 utilities — runs natively or transparently through emulation without me having to think about it. That’s exactly how it should be.

The review configuration I’ve been running ships with 32GB of RAM and a 1TB SSD, paired with an 8-bit 1920×1200 OLED display. Lenovo’s configurator puts that at $1,650-1,750, depending on timing and promotions. The base model starts at $1,099. For what you get here, the price-to-capability ratio is genuinely competitive — but we’ll get to that.

The Battery Story

I want to be precise about this, because I won’t throw superlatives around lightly. I’ve been using laptops as my primary work machines since the early 1990s. In that entire span — Intel machines, AMD machines, ultrabooks, workstation-class slabs, every category you can name — I have never gotten genuine all-day battery life. Not once. There was always a charger within arm’s reach by mid-afternoon, if not sooner.

My normal workload is not gentle. On any given workday I’m running Edge with more tabs open than I care to admit, writing in Word, banging out blog drafts, running PowerShell scripts, diving into Windows event logs, and doing the kind of system tuning and troubleshooting that keeps the lights on around here. Not gaming. Not video rendering. But not exactly browsing cat photos either.

On the Yoga Slim 7X Gen 11, I routinely close out a full working day — eight-plus hours of active use — with battery to spare. I’ve stopped automatically reaching for the charger when I sit down to work. That is genuinely new behavior for me, and I’m not entirely sure I trust it yet. But nearly two weeks in, it keeps happening.

The published benchmarks back this up. PCMag measured 20 hours 16 minutes in their battery rundown test. CNET’s reviewer reported nearly 24 hours under their methodology. Real-world mixed-workload numbers will always differ from a controlled rundown script at 150 nits, but even my demanding day falls comfortably within the machine’s range. The math works.

The credit goes to Qualcomm’s Oryon v3 CPU architecture. These cores are built around aggressive power-gating and efficiency in a way that x86 designs still struggle to match at this thermal envelope — and remember, this is a machine that is 0.51 inches thin and weighs 2.9 lbs. There is no magic here, just a fundamentally different approach to how the chip uses (or doesn’t use) its power budget.

I’ve been doing this long enough to know not to take marketing claims about battery life at face value. This one’s different.

Display and Keyboard: Lenovo Keeps It Up!

The OLED panel — 1920×1200 resolution, 120Hz refresh rate, Dolby Vision certified, DisplayHDR True Black 1000 rated — is the kind of display that makes you look at everything twice. Laptop Mag measured it at 155% of the DCI-P3 color gamut. At 162 PPI on a 14-inch screen, text is sharp enough that I’ve caught myself checking whether anti-aliasing is doing anything at all. Blacks are genuinely black, not “dark grey in a dim room” black. It’s glossy, which means reflections are a real consideration in bright environments, but for document work and long writing sessions, it’s stunning.

The keyboard is excellent, and I say that as someone who has spent years on ThinkPads. Yoga Slim models skip the TrackPoint eraser puck that ThinkPad loyalists — myself included, some days — know and love. But they bring everything else. Key travel is satisfying, the layout is sensible, the function-row behavior is configurable, and the spacebar has never missed a beat. XDA Developers and Android Headlines both called it one of the best keyboards on any Windows ultraportable. Two weeks of heavy typing confirms that verdict.

The touchpad is large, accurate, and well-tuned. Lenovo’s touchpad calibration remains class-leading on the Windows side — no complaints there. One honest caveat: the keyboard deck does have a very slight flex under hard typing pressure. Not a dealbreaker, and honestly easy to forget about after the first day. But if you press down firmly in the middle of the deck, you’ll feel it. Worth knowing before you spend $1,600 or more…

Windows Hello Does the Job

The Yoga Slim 7X Gen 11 ships with a 9MP IR webcam — native resolution of 3840×2400 — which puts it in a completely different class from the pedestrian 1080p cameras most Windows laptops still ship with in 2026. The gap between “has Windows Hello” and “has Windows Hello that actually works well” is wider than most people realize until they use the real thing.

My experience: the face recognition fires quickly after lid open. No perceptible delay, no “hold still for a moment” pause, no second attempt. It just authenticates. More to the point, it recognizes me both with and without my reading glasses, without any hesitation either way. That is not trivially true of all Windows Hello IR cameras — I’ve owned machines where swapping eyewear or changing room lighting was enough to trip the thing up and send me to the PIN fallback. Not here.

The IR sensor handles varied ambient lighting without complaint. LED overhead lighting in my home office, dimmer evening conditions — it doesn’t care. It just works. The 9MP sensor also means video calls look genuinely good, not just “acceptable for a laptop camera.” The webcam supports up to 1440p video output, and on a call it shows. Touch screen support is pretty great, too. I miss that on the Zenbook A14 so I appreciate it even more here on the Yog7X2.

Windows Hello has been part of the Windows story since 2015. It has taken this long — and a camera this capable — to make the feature feel fully baked. Better late than never, I suppose.

Performance: Good for Any Laptop, Full Stop

The Snapdragon X2 Elite (X2E-88-100) delivers performance that I would describe as genuinely competitive with any thin-and-light laptop on the market. Not “impressive for ARM” — impressive, full stop. My daily workload of PowerShell scripting, multi-tab Edge browsing, Word, event log analysis, and general system tuning runs without stutter, lag, or hesitation. App launch times are snappy. The machine never feels like it’s working hard, even when I’m throwing a lot at it simultaneously.

Windows on ARM compatibility is no longer the obstacle it once was. The overwhelming majority of my tools run natively on Snapdragon. The few that still go through emulation do so transparently — no perceptible performance penalty, no workflow interruption. That was emphatically not the story two years ago, and it’s worth saying plainly: the platform has matured.

The machine handles all of this inside a 0.51-inch, 2.9-pound chassis, and it does it silently. Under my normal load, the fans are simply not a factor. That used to be the price of admission for real performance in this class — fan noise as a constant companion. Not here. Two weeks in, I’ve yet to find a workload that makes it flinch.

Net-Net: Nice-Nice

Two weeks in, the Yoga Slim 7X Gen 11 has done something rare: it has exceeded expectations on exactly the things that matter most to how I actually work. The battery life is the headline, full stop. The display and keyboard are the supporting cast that make every hour in front of the machine a pleasure. And Windows Hello, of all things, turns out to be the pleasant surprise that keeps on giving.

My only nits to pick are minor. My review unit shipped with Windows Home, which I immediately upgraded to Pro for remote access and Hyper-V support. Keyboard flex does occur in the middle. Surprisingly, there’s no headphone jack and the external speakers are noticeably mid-level in clarity and tone. Though it does have USB-C ports on both sides (2 left, 1 right) it has no USB-A nor HDMI. For me, none of these is a deal-killer. I’ve learned to like this laptop quite a bit, in fact.

I’ll have more to say about Windows on ARM compatibility and the Snapdragon X2 Elite’s full performance story in a follow-up post. There’s real depth there worth unpacking, and it deserves its own space. Stay tuned.

Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Fixing Windows Security Stays Blank

June 4, 2026 Ed Tittel Leave a comment

Normally, when you open the Windows Security app, there’s a brief pause during which the app window is blank (1-2 seconds is normal). But sometimes, that window remains empty. This morning, it popped up on my second Ryzen 7 5800X desktop. In turn, that had me seeking out ways for fixing Windows Security stays blank. Turns out there are two extremely easy fixes, though one takes longer and is more disruptive than the other. Here goes…

Note: the intro screencap shows mockups of the blank Windows Security window (light theme at left, dark theme at right). The key point is “Nothing to see here!” That’s a problem that turns out to be relatively easy to fix.

How-To: Fixing Windows Security Stays Blank

The quick and easy way is to use the app menu a little differently. On the affected machine, I observed that picking any subsystem inside Windows Security will cause it to open, after which “going home” inside the app works like a champ. Since I wanted to check “Device Security” anyway, I went straight there.

Instead of clicking the icon at top center, I clicked on “Device Security” (3rd from bottom in preceding screencap). It came right up and I saw what I needed to see (checking Secure Boot status info).

Another Fix: Reboot, Try Again

I also observed that a reboot brought Windows Security back to a normal, predictable state. Indeed, this is a workable technique to undo lots of everyday wonkiness in Windows, as many readers will know and appreciate. This has been a staple early stage activity in Windows troubleshooting as far back as I can remember (1991, 35 years ago).

Why Does This Happen?

Copilot attributes this reasonably common behavior to an outcome from its design as a UWP shell atop a set of back-end Windows services. It says “When the shell launches faster than its backend services are ready to respond — a classic race condition — the shell renders the window frame but has nothing to populate it with, so you get a blank canvas.” Sounds about right to me, especially noticing a slight delay between launch and population on other PCs I just checked (including the 2018 vintage ThinkPad Yoga X380, the 2022 vintage ThinkPad X16, and the 2020 vintage ThinkPad X12 Detachable Tablet).

Here in Windows-World thinks going wonky is part of the daily round. It’s nice to find a minor glitch that’s quick and easy to diagnose, and fix. I’ll take those wins where I can find them!

Cool Tools, Insider stuff, Recent Activity, Updates, WED Blog

GNUBG Shows WinGet Pin Rationale

June 3, 2026 Ed Tittel Leave a comment

Since Monday, I’ve noticed that WinGet is updating GNU Backgammon every day, aka GNUBG. You can see in the lead-in graphic this happens because the app reports its version number as unknown. Of course, that means WinGet wants to update it, even though that’s unnecessary. How to avoid this unwanted repetition: the WinGet Pin command. Thus, GNUBG shows WinGet Pin rationale, and lets me turn down the noise.

How GNUBG Shows WinGet Pin Rationale

The lead-in graphic also shows that the current installed GNU Backgammon version matches the one that WinGet wants to install. That proves it’s a reporting error from the app itself, not the typical “current version is less than winget database version” that supplies a usually valid reason to run the update process.

Obviously, this will go on until (or if) the developers fix the game, or until a real, new version comes out. So here’s what I did to stop the madness: I ran winget pin –id GNU.gnubg

Once pinned, WinGet stops its repeated GNUBG updates. Good!
[Click image for full-sized, more readable view.]

I’ve seldom had to use WinGet Pin on the PC fleet here at Chez Tittel. But every now and then — as with GNUBG here — something pops up that calls for a timeout. Now, I just have to remember to keep an eye on the app so I can unpin or force-update when a REAL one shows up. That’s just one of the small things that keeps me on my toes, here in Windows-World.

Device drivers, Insider stuff, Recent Activity, USB devices, Windows 11

USB Ports Need More Storage Bandwidth

June 2, 2026 Ed Tittel 2 Comments

In reading over Computex coverage I’m impressed by an array of newer, faster computing platforms and storage technologies. At the same time I’m depressed that USB-attached storage is not swimming in this rising tide of increased performance and capability. Simply put: USB ports need more storage bandwidth so they can hold up their end while ushering in a brave new world of performance computing. Let me explain…

Why USB Ports Need More Storage Bandwidth

Thunderbolt 4 tops out at 40 Gbps — that’s a theoretical ceiling of roughly 5 GB/s, and real-world storage transfers run well below that. It was impressive when it arrived. It isn’t anymore. Thunderbolt 5 moved the needle, pushing up to 120 Gbps on the read side and 40 Gbps on writes. Indeed, its asymmetric bandwidth design delivers somewhere in the neighborhood of 6–7 GB/s of actual storage throughput under optimal conditions.

That’s a real boost, and to give credit where it’s due: Intel’s Thunderbolt 5 is the current high-water mark for USB-attached external storage performance. But here’s the problem — “high-water mark for external” and “keeping pace with internal” are two very different things. Alas, the gap between them is widening fast.

Phison’s PCIe 5 Controllers: Lapping the Field

Let’s talk about what’s happening inside the box right now. Phison’s E26 controller — the flagship PCIe 5.0 x4 part — pushes sequential reads up to roughly 14 GB/s and writes near 12 GB/s. That’s not a roadmap promise. That’s shipping silicon, today, in drives like the Crucial T705 and Seagate FireCuda 540. And the reason those numbers are possible is that PCIe 5.0 x4 delivers approximately 32 GB/s of raw bus bandwidth — a figure Thunderbolt 5’s best-case scenario can’t remotely approach.

I’ll be blunt: Thunderbolt 5 running at its theoretical maximum is still less than a quarter of PCIe 5’s available bus bandwidth. External storage users are working with a narrow pipe while internal NVMe users are drinking from a fire hose. And here’s what makes it even more galling — PCIe 5 SSDs themselves are already hitting their ceiling and looking nervously at what comes next. The interface they’re starved for is PCIe 6, which is already coming down the pipe.

Phison PCIe 6 Controllers: Next Tier Is Here

Computex 2025 was where Phison first made the PCIe 6.0 future feel real, and the momentum has only built from there. The next-generation Phison controller roadmap targets PCIe 6.0 x4 — an interface that theoretically delivers around 64 GB/s of raw bandwidth per slot, thanks to PAM4 signaling running at 64 GT/s per lane. Real-world sequential read targets are north of 20 GB/s.

Think about what that means for Thunderbolt 5’s ceiling. A single PCIe 6 SSD — one drive, one M.2 slot — could in principle saturate nearly five simultaneous Thunderbolt 5 connections running flat out. The Thunderbolt bandwidth ceiling doesn’t just look inadequate at that point; it looks comical. External storage users are so far behind that “catching up” is a massive understatement. Instead, designs must condider a completely different approach.

What Needs to Change?

USB4 Gen 3×2 sits at 40 Gbps — identical to Thunderbolt 4, still not enough. USB4 v2 bumps that to 80 Gbps, which helps at the margins but still lands less than a third of PCIe 5’s bus bandwidth, let alone PCIe 6’s. These are incremental improvements on an interface that needs a fundamental rethink, not a spec bump.

The industry needs a paradigm shift. Either Thunderbolt 6 or USB5 — whatever we end up calling it — must arrive with dramatically higher bandwidth, we’re talking 200+ Gbps as a floor, not a ceiling. Alternatively, PCIe tunneling over external cables needs to mature to the point where it can fully exploit NVMe speeds without overhead that kills performance today. One or the other. Probably both, eventually.

Until one of those paths becomes real and shipping, external storage users are locked in a performance ghetto. Internal SSD buyers are sprinting ahead with every product generation. The storage industry owes external storage users a credible, substantive answer. I’m not talking about another incremental spec revision, not another narrowly defined workaround. Computex 2026 is the right venue and this is the right moment. USB silicon designers need to envision, then deliver something worth getting excited about. So far, I can’t see it. Let’s hope for something amazing, shall we?

Cool Tools, Copilot+ PCs, Insider stuff, Recent Activity, WED Blog, Windows 11, Windows OS Musings

NVIDIA Extends ARM on Windows’ Reach

June 1, 2026 Ed Tittel Leave a comment

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!

Cool Tools, Copilot+ PCs, Insider stuff, Recent Activity, WED Blog, Windows 11

WinRE Ignores Inactive HDMI Output

May 28, 2026 Ed Tittel Leave a comment

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!

Cloud PC, Cool Tools, Copilot+ PCs, Insider stuff, Recent Activity, Troubleshooting, USB devices, WED Blog, Windows 11

ASUS Snapdragon Shows Odd Boot Anomaly

May 27, 2026 Ed Tittel Leave a comment

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!!!

Backup/Restpre, Cloud PC, Copilot+ PCs, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Bizarre ASUS Disk Layout Is Intentional

May 26, 2026 Ed Tittel Leave a comment

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…

Insider stuff, Recent Activity, Secure Boot, Security, WED Blog, Windows 10, Windows 11

Explainer: Secure Boot Chain of Trust

May 21, 2026 Ed Tittel 1 Comment

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.

The UEFI firmware initializes hardware and activates Secure Boot mode.
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.
The signed bootloader (Windows Boot Manager, for example) takes over and verifies the OS kernel’s signature using its own embedded certificates.
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.

Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

Another Toolset for Secure Boot Checks

May 20, 2026 Ed Tittel Leave a comment

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.