Category Archives: Troubleshooting

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

Building X12 Boot Media

Leave a comment

As I’ve recently reported, the ThinkPad X12 Hybrid Tablet has two USB-C ports and no USB-A ports. Worse yet, a USB-A to USB-C adapter does not work to boot this machine, as I discovered the hard way. Compound that with FAT32’s 4 GB per-file ceiling and a install.wim that routinely tops 5 GB. That makes a straight Windows 11 ISO write impossible. Thus, I’ve worked through a repeatable solution that splits the WIM, mirrors the ISO source tree with Robocopy, stamps a proper bootable ISO with oscdimg, and finally writes it to a native USB-C drive with Rufus — no errors, no drama. It’s my way of building X12 boot media, though you can use MCT instead, if you prefer.

Manually Building X12 Boot Media. Step-By-Step

Just for grins I wanted to start from an official Windows 11 ISO, and create the boot disk from scratch. Here’s what I did:

Step 1 — Download the Windows 11 ISO

First, head to Microsoft’s official software download page at microsoft.com/software-download/windows11 and choose the “Download Windows 11 Disk Image (ISO) for x64 devices” option. Select your preferred language and grab the multi-edition ISO — it weighs in at roughly 6.5 GB, so make sure your destination drive has ample free space before you start. Save it somewhere you can easily reference in the steps that follow. I grabbed mine from the Downloads folder/library.

Step 2 — Mount the ISO and Split install.wim

Next, mount your downloaded ISO in File Explorer by right-clicking it and choosing Mount. In response, Windows assigns it a drive letter automatically (I’ll use D:\ here, though it shows as H:\ in the lead-in screencap). Then open an elevated command prompt and use DISM to split install.wim into 3,500 MB chunks, small enough to fit safely inside FAT32’s 4GB per-file limit (if you cut’n’paste the following, it should be a one-liner at the command line):

dism /Split-Image /ImageFile:D:\sources\install.wim
/SWMFile:C:\X12Media\sources\install.swm ^      /FileSize:3500

DISM writes install.swm, install2.swm, and any additional parts directly into your target sources folder. Windows Setup picks them up automatically at install time — no extra configuration required.

Step 3 — Build the ISO Source Folder with Robocopy

Then, use Robocopy to mirror nearly all files from the mounted ISO into a clean working folder — but explicitly exclude the oversized install.wim you’ve already replaced with the split .swm files:

robocopy D:\ C:\X12Media\ /E /XF install.wim

The split .swm files you created in Step 2 are already sitting in C:\X12Media\sources\, so the result is a complete, well-formed ISO source tree ready for imaging. Everything Setup expects is present and correctly sized.

Step 4 — Generate Bootable ISO with oscdimg

Next, you need a copy of the MS Operating System CD Imaging utility, aka oscdimg.exe. You may need to install the Windows ADK (Assessment and Deployment Kit) from Microsoft if you haven’t already (oscdimg.exe ships with it). I found one inside the MiniTool Partition Wizard (MTPW), and used that version instead (worked like a charm). Wherever you get it, oscdimg.exe is the right tool for stamping a proper dual-purpose ISO. The command below targets both legacy BIOS (etfsboot.com) and UEFI (efisys.bin) boot sectors in a single pass:

oscdimg -m -o -u2 -udfver102 ^   -bootdata:2#p0,e,bC:\X12Media\boot\etfsboot.com ^   #pEF,e,bC:\X12Media\efi\microsoft\boot\efisys.bin ^   C:\X12Media C:\Output\Win11_X12.iso

The -m flag overrides the 4 GB maximum image size limit, while -u2 enables the UDF file system for broad compatibility. The resulting Win11_X12.iso in C:\Output\ is your custom X12 Hybrid boot media image.

Step 5 — Write Bootable USB Media with Rufus

Finally, download Rufus from rufus.ie and launch it as administrator. For the drive, I needed a native USB-C flash drive — I ordered a Kingston DataTraveler 70. Do not reach for a USB-A to USB-C adapter: the X12 Hybrid will not boot from one, full stop.

Select the Kingston DataTraveler 70 in Rufus, point the “Boot selection” field to Win11_X12.iso, and set the partition scheme to GPT with target system UEFI (non CSM), leaving the file system at FAT32. Rufus handles the split .swm files correctly because they are already embedded and sized within the ISO — no special Rufus settings needed. Click START, accept any warnings about erasing the drive, and within a few minutes you have fully functional X12 Hybrid boot media ready to go.

The Proof’s In the Booting…

I was relieved when the X12 finally booted from the Kingston UFD entry in the UEFI boot menu. That had been a LONG time coming. Even so, the extra steps described above add perhaps 15 minutes to a typical USB media build. That said, they reliably eliminate the frustrating “Windows cannot install required files” errors that plague direct installs on picky devices. Give this workflow a try on your X12 Hybrid — or on any device where you run into issues booting from USB media— and let me know how it goes in the comments below.

I’m glad to have the X12 back on the working roster. Indeed, I’m getting ready to upgrade it to a Beta Channel build shortly, Hopefully, I won’t need the repair/recovery media I just built. But if I do, I’ve got it handy. Here in Windows-World “better safe than sorry” are words to live by!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, Troubleshooting, Uncategorized, WED Blog, Windows 11

Two Reboots ARE Better Than One

Leave a comment

During the repair process for the X12 Hybrid Tablet (see Friday’s blog for details), I got to the point where I was ready to reboot after a couple of repairs. Those involved (1) running bcdboot to rebuild my boot files from scratch, and (2) telling Garlin’s update_UEFI... script to emplace SkuSiPolicy.P7b. After a first reboot, the boot screen showed red error text for a Secure Boot mismatch error (reporting that what’s in firmware differs from what wants to run). After a second reboot, the system came up clean with no errors at all. Indeed, that’s what’s supposed to happen and why I claim that two reboots are better than one!

To begin, it’s worth noting what those two steps actually do. Running bcdboot rebuilt the EFI System Partition boot files and restored a working Windows Boot Manager entry. The Garlin script then installed the production-variant SkuSiPolicy.p7b, which writes itself as a UEFI firmware variable enforcing production-level Secure Boot signing rules — rules stricter than the defaults many machines ship with. Consequently, the UEFI firmware suddenly had new staged SVN values sitting alongside the existing committed values in NVRAM. The first reboot is, therefore, where things got genuinely interesting.

Exploring Why Two Reboots ARE Better Than One: First Reboot

When the X12 attempted its first boot after the script ran, the firmware compared the newly staged SVN (Security Version Number) values against whatever was already written into UEFI NVRAM. Naturally, they didn’t match — because the new policy was not yet committed. That mismatch triggered the Secure Boot error you see mocked up as the lead-in graphic. However, and this is the critical part, that same first boot is exactly when Windows Boot Manager wrote the new SVN values out to the UEFI NVRAM, permanently committing the production policy into the chip’s non-volatile storage. The error, in other words, was not a failure. In fact, it was the system doing its job exactly as designed. The Secure Boot commit phase looks alarming on the surface; nonetheless, it is entirely intentional behavior.

Microsoft engineered this two-phase mechanism deliberately so that a mid-commit crash or power loss cannot brick the machine. Old NVRAM values stay valid until the new ones are fully written and confirmed. As a result, if the lights go out halfway through the commit, the firmware simply falls back to the previous known-good state. It is a genuinely elegant safety net (one that I have come to deeply appreciate after years of watching less careful UEFI implementations leave machines unbootable).

Reboot Two: Verifying a Clean Bill of Health

Furthermore, once the X12 had committed the new values on reboot one, the second reboot was simply the verification phase. With the NVRAM now holding the freshly committed data, the firmware ran its Secure Boot checks again. This time, FirmwareSVN, BootManagerSVN, and StagedSVN all agreed — and the machine booted clean, no error, no complaint. Running Get-SecureBootSVN from an elevated PowerShell prompt confirmed the result:

At this time, in fact, 9.0 is the current maximum enforced SVN — so this is a perfect result, not merely a passing grade. All three values align, and the ComplianceStatus line says exactly what you want it to say. The Secure Boot commit phase had done its work on reboot one; verification simply confirmed it on reboot two. The X12 was, in every sense, fully compliant with proper Secure Boot policy.

Two Reboots Makes a Pattern…

Moreover, this two-reboot pattern is not unique to my ThinkPad X12 repair scenario. It is the same deliberate mechanism Windows uses for DBX enforcement updates such as KB5012170. Microsoft designed it this way intentionally — if the machine loses power or crashes mid-commit, the old NVRAM values remain valid until the new ones are fully written and confirmed by a clean second boot.

IMO, the mismatch error on reboot one is a feature, not a bug. The Secure Boot commit phase genuinely requires two boots to complete safelyIndeed, that’s by design, not by accident. So next time you see a Secure Boot mismatch error on the first reboot after a repair or a policy update — don’t panic, don’t reach for the BIOS reset jumper, and definitely don’t call Microsoft support just yet. Just reboot again. Chances are, you’ll be greeted by a perfectly clean boot and Secure Boot status check outputs that make you smile.

Here in Windows-World, we take those smiles as we can get them, cheerfully and with good humor. Once the panic subsides, that is…

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, Recent Activity, Secure Boot, Troubleshooting, WED Blog, Windows 11

USB-C UFD Restores X12 Boot

Leave a comment

I wasn’t sure Copilot was right. Even some of my regular commenters here at edtittel.com were sure Copilot was wrong. Fact is, I couldn’t get into WinRE to repair my damaged BCD until I inserted a brand-new USB-C based Kingston Data Traveler 70 (US$28) into the X12 Hybrid Tablet (Gen 1). Now it’s working. More explicitly using the USB-C UFD restores X12 boot capability.

Before that, I had tried known, good working USB-A UFDs via a USBA2C adapter. I’d also tried native USB-C NVMe SSDs as well. Apparently — as Copilot averred and my experience shows — it will only boot to a real USB-C UFD. Same format, same files, same creation approach on the other devices just didn’t result in a boot into WinRE for on-disk boot repairs to the C: drive. That much of the travail, at least, is now over…

After USB-C UFD Restores X12 Boot, Then?

Now I need to fix Secure Boot (SB), which is what got me in trouble in the first place. Right now, the unit boots fine with SB disabled. I’ve run the Garlin check script and have installed SkuSiPolicy.P7b. But still, I get the red text “Secure Boot mismatch” error info when I try to book with SB turned on. I’m going to reset the keys to factory default, and pick up from there to see what happens next.

But first, after I rebooted again on the X12 without making any changes, it took me to the Windows 11 lock screen. Windows Security gives the system its blessing (green checkmark on the Secure boot entry). So I may already be over the hump, because of the second reboot.

If at First You Don’t Succeed, Reboot Again…

On a third reboot, I get the spinning circles while the OS loads and get right to the Windows 11 lock screen. No more boot issues, no more “boot mismatch” refusals. I seem to have things working again.

As the old saying goes “Get the right tool for the job.” In my case I had to learn the hard way that I MUST use a USB-C UFD to boot the X12 into anything. Now I know. It’s in my little plastic bin of UFDs and I guess I know how to use it. Case closed, I hope!

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

X12 Boot Fix on Hold

4 Comments

Boy, howdy. I just spent the best part of a day figuring out I can’t fix a boot problem on one of my laptops. The Lenovo ThinkPad X12 Hybrid is a capable and compact Windows device, but its UEFI firmware has strict requirements for external boot media. After extensive troubleshooting, it’s clear that continuing repair attempts without a native USB-C flash drive won’t work. This post explains why that process must pause until the correct media shows up. Until it does, I’ve put the X12 boot fix on hold. Let me explain…

Why Put the X12 Boot Fix on Hold?

The X12 Hybrid’s UEFI boot environment is designed to recognize and boot only from a narrow set of external devices. Specifically, it supports:

  • Native USB-C flash drives
  • Native USB-A flash drives (when connected directly to a built-in USB-A port; my X12 has only two USB-C ports & no USB-A ports)
  • SD cards (on models equipped with an SD slot)

Alas, I’ve confirmed by experiment that it does not boot from:

  • NVMe enclosures
  • SATA enclosures
  • USB-A drives connected through USB-A-to-USB-C adapters
  • USB hubs or multiport dongles

Even when such devices appear in the boot menu, the firmware rejects them during handoff to the bootloader. My problem right now is that I don’t own a USB-C flash drive.

Why the Current Media Fails

During troubleshooting, multiple external boot media were tested:

  • USB-A flash drives: Not recognized as bootable when connected through an adapter.
  • Modern NVMe enclosures: Enumerated in the boot menu but immediately returned to the boot selector when chosen.
  • Older NVMe enclosures: Presented themselves correctly as USB Mass Storage devices but were still rejected by the firmware.

These behaviors indicate that the X12 Hybrid’s boot ROM enforces strict transport and device-class requirements. Only a native USB-C flash drive meets all these constraints. Sigh: I’ve got a US$28 Kingston DataTraveler 70 on order from Amazon (delivery : 7/1).

Why a USB-C Flash Drive Is Required

A native USB-C flash drive provides:

  • Direct USB-C connectivity without adapters or bridges
  • USB Mass Storage Class (BOT) compatibility
  • Reliable FAT32 formatting for UEFI boot
  • Full compatibility with Windows installation media

This combination ensures that the X12 Hybrid’s firmware can properly read and execute the Windows bootloader.

The Practical Decision: Pause and Wait

Given the firmware limitations and the consistent rejection of all other media, I can do no further troubleshooting until a USB-C flash drive appears. Once in hand, the following steps will occur:

  1. Format the USB-C drive as GPT + FAT32
  2. Rebuild the Windows installation media
  3. Boot the X12 Hybrid from the new drive
  4. Repair or rebuild the EFI System Partition (ESP)

Pausing now avoids wasted effort and boosts the odds that my next troubleshooting step will help.

Still Waiting…

The troubleshooting process for the X12 Hybrid now sits where the correct hardware is needed. A native USB-C flash drive is the only reliable path forward for UEFI boot and system repair. Once it arrives, the repair process can continue with confidence. Or so I hope: here in Windows-World there’s always the chance that a (nearly) sure thing turns out otherwise. Sigh again: I’ll be finding out!

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

Long Trip From 26H1 To 25H2 On P16G3

Leave a comment

Now that I have a Snapdragon X2 PC with a “REAL” version of Windows 11 26H1 installed, I no longer needed the “experimental” version on the Lenovo ThinkPad P16 Gen 3 Mobile Workstation. SO I decided to clean install Windows 11 Pro for Workstations 25H2 on that machine instead. Wow! Did I ever choose a wicked path to follow. It turned out to be a long, long trip from 26H1 to 25H2 on P16G3 (machine name for the afore-named ThinkPad). Buckle up!

Why Such a Long Trip From 26H1 To 25H2 On P16G3?

TLDR answer: Secure Boot foul-ups. After the install, I ran garlin’s Check_UEFI-CA2023.ps1 script on my ThinkPad P16 Gen 3, fully expecting the usual audit output I see on other Windows 11 machines. Instead, I got something that stopped me cold — a warning that certain Secure Boot certificate operations were blocked. The focus keyword here is Secure Boot Deployed Mode ThinkPad P16 Gen 3, and if you’ve landed on this post, you’re probably staring at the same bewildering output I was.

Here’s the short version: the machine was stuck in UEFI Deployed Mode — the strictest Secure Boot state in the UEFI specification. Windows reported Secure Boot as “On,” everything looked fine in Windows Security, and yet the Secure Boot certificate update operations the script needed to perform were completely blocked. No error. Just a quiet wall.

As it turns out, Lenovo began shipping 2024-and-newer ThinkPads — including the P16 Gen 3 — in Deployed Mode by default. That’s a deliberate policy change, not a quirk or a misconfig. And once I understood what it meant, the fix turned out to be a two-minute BIOS menu operation. Let me walk you through it.

What Is UEFI Deployed Mode, Exactly?

The UEFI specification defines four platform security modes, and it helps to know all of them before you go poking around in the BIOS.

Mode Platform Key (PK) DeployedMode Flag Can Modify Secure Boot Variables?
Setup Mode Not installed Off Yes — fully open
User Mode Installed Off With proper authentication
Audit Mode Not installed Off Yes — for testing only
Deployed Mode Installed On No — physical BIOS access required

Deployed Mode is the strictest of the four. The vendor’s Platform Key (PK) is installed, and a separate DeployedMode flag is set to active — which means no software running inside Windows, no matter how privileged, can touch the Secure Boot variables: PK, KEK, db, or dbx. The firmware physically refuses those writes. Therefore, any tool that tries to update Secure Boot certificates from within the OS is going to hit a hard stop.

Here’s the generational split that matters: ThinkPads from 2023 and earlier shipped in User Mode, where the PK is installed but the DeployedMode flag is off, leaving the certificate database accessible via authenticated software. The P16 Gen 3 — along with other 2024-and-newer Lenovo models — ships in Deployed Mode by design. That’s a meaningful architectural difference, and it’s why older tutorials and community scripts don’t account for it. [Source: Lenovo CDRT Docs — Guide to Secure Boot Modes]

Garlin’s Scripts Hit A Wall

Let me be clear: garlin’s PowerShell scripts are excellent community work. The Check_UEFI-CA2023.ps1 and Update_UEFI-CA2023.ps1 scripts are the most thorough tools available for migrating from the expiring 2011 UEFI CA to the 2023 UEFI CA. That’s a transition Microsoft is pushing hard as it tightens Secure Boot enforcement. However, they presuppose a machine in User Mode, where certificate variable writes are at least possible with the right credentials.

On a machine in Deployed Mode, that presupposition falls flat. The firmware’s DeployedMode flag instructs the UEFI runtime to reject all Secure Boot variable modifications originating from the OS environment — full stop. Garlin himself acknowledges as much: you can’t make certain changes while the vendor’s PK is in place and the DeployedMode flag is active. The scripts detect this condition and report it, which is exactly what I saw.

There’s a second layer to this on my specific machine. The P16 Gen 3 runs Windows 11 Pro for Workstations — a meaningfully different edition from Home, Pro, or Enterprise. Pro for Workstations ships with Virtualization-Based Security (VBS) and HVCI enabled by default and uses an edition-specific SkuSiPolicy.p7b file. In addition, it’s designed for domain and enterprise management workflows. The scripts were built around the more common consumer and business editions; Pro for Workstations introduces just enough architectural divergence that some operations require extra care. As a result, even if Deployed Mode weren’t in the picture, this wouldn’t be a straight plug-and-play situation.

The Fix: Exiting Deployed Mode via BIOS

Here’s what I did. The good news is that Lenovo provides a clean, supported path to exit Deployed Mode directly from the BIOS Setup interface — without clearing Secure Boot keys, without entering Setup Mode, and without reinstalling anything. The machine transitions from Deployed Mode to User Mode: the PK stays installed, Secure Boot stays on, and the OS-level certificate update path opens back up.

⚠ Warning — Read Before You Touch Anything

Do NOT select “Reset to Setup Mode” or “Clear All Secure Boot Keys” in the BIOS menu. Either action removes the Platform Key entirely, disables Secure Boot, and requires full manual key reinstallation to recover — a process that is very much not two minutes. If you’re unsure at any step, “Restore Factory Keys” is a safe fallback that gets you back to Lenovo’s shipped state.

Step-by-Step: Exit Deployed Mode on the ThinkPad P16 Gen 3

  1. Enter BIOS Setup. Restart the machine. Press F1 (or Fn+F1 if function-key lock is on) repeatedly at the Lenovo logo during POST. The ThinkPad UEFI BIOS Setup menu opens.
  2. Navigate to Security → Secure Boot . Use the arrow keys. You’re looking specifically for the sub-entries one level down.
  3. Select “Exit Deployed Mode.” This is the one you want. Confirm the action when prompted. This clears the DeployedMode flag only — the Platform Key remains installed and Secure Boot stays active. The machine moves from Deployed Mode to User Mode.
  4. Save and exit. Press F10 and confirm the save. The system reboots.
  5. Verify in Windows. Open msinfo32 (Win+R → msinfo32 → Enter). Under System Summary, confirm: Secure Boot State = On and Platform Mode = User Mode. Both should now read correctly.
  6. Re-run garlin’s Check script. Open an elevated PowerShell prompt and run Check_UEFI-CA2023.ps1 again. The Deployed Mode warning should be gone, and the script should now report actionable certificate update steps as intended.
💡 Tip

If “Exit Deployed Mode” doesn’t appear in your Key Management menu, confirm you’re running a current BIOS version. Lenovo has updated the P16 Gen 3 firmware several times since launch — older BIOS revisions may expose the option differently or label it under a slightly different path. [Source: Lenovo Support HT515493]

Bottom Line

The ThinkPad P16 Gen 3’s Deployed Mode is a feature, not a bug — Lenovo added it to give enterprise customers the highest available firmware integrity assurance right out of the box. Garlin’s scripts are genuinely excellent community tools for the Secure Boot CA 2023 migration, but they presuppose User Mode and a standard Windows edition. Alas, on the P16 Gen 3 running Pro for Workstations, those assumptions don’t hold without first making one BIOS menu change. That said, once you exit Deployed Mode and land back in User Mode, the standard Windows Secure Boot update path works exactly as intended — and the whole detour costs you about two minutes and one reboot.

One more thing: Garlin will tell you to edit the registry and run a scheduled Secure-Boot-Update task. Works on most Windows editions, but not on Pro for Workstations. Follow his advice, unless you’re running that version. I wasted hours until I figured out it just wouldn’t work. Sigh.

Facebooklinkedin
Facebooklinkedin

Insider stuff, Recent Activity, Remote Desktop (RDP), Troubleshooting, WED Blog, Windows 11

Rare Update BSOD Proves Benign

Leave a comment

When better ways to shoot myself in the foot become available, I’ll invariably make use of same. Today, I found myself cleaning up after a surprise bluescreen (aka BSOD for “Blue Screen of Death”). This time, I did it to myself because I used a remote access session to drive updates for both my Intel and NVIDIA GPUs on the Lenovo P16 Gen 3 Mobile Workstation. Indeed, upon investigation, this rare update BSOD proves benign. You can see the error cascade from the Intel GPU update in the lead-in graphic (click that image to see the whole thing: it includes a “Shut down unexpectedly” error).

Why Say: Rare Update BSOD Proves Benign?

I couldn’t find any lingering bad behavior or unwanted side effects from this unexpected crash. Indeed, both Intel DSA (the tool I used to update the Intel ARC GPU) and the NVIDIA app (the tool I used to update the RTX Pro 5000 GPU) reported clean, successful installs when I fired them up to check what happened.

Indeed, that raises the interesting question: “Exactly what happened that caused the P16 Gen 3 to BSOD?” Short answer: me. Longer answer, courtesy of Copilot:

When you install a graphics driver over Remote Desktop:

  • Windows switches to a virtual display driver (RDPDD / Remote Display Adapter)
  • The real GPU driver is still being installed in the background
  • This creates a weird overlap between:
    • kernel graphics stack (dxgkrnl)
    • RDP virtual driver
    • the new GPU driver being initialized/unloaded

That’s exactly the kind of situation that can cause: KERNEL_MODE_HEAP_CORRUPTION (0x13A) → driver stomping memory during unload/reload. Even a perfectly “healthy” driver can crash in that transition.

The Devil Made Me Do It!

I confess: I prefer to work from my production desktop, even when I’m working on another PC. It’s a combination of convenience and laziness. Convenience, because I’ve got two big, clear 27″ monitors I can work from. Laziness, because I don’t have to get up from one chair in my office and move 8 feet over to the other desk where the P16 Gen 3 is running.

Occasionally, this means I get bitten or borked because I’m remoting in, rather than working on the machine directly. Here in Windows-World, I’ve learned to troubleshoot with a certain wry appreciation that I am often the cause of my own woes. Today was one of those days! That said, it all ends well because the system recovered completely upon a successful reboot.

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

Fixing Windows Security Stays Blank

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!

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

ASUS Snapdragon Shows Odd Boot Anomaly

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

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

Bizarre ASUS Disk Layout Is Intentional

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…

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

Troubleshooting Flo6 S3 Sleep Oddities

Leave a comment

Now that I’m back to a normal work pattern, I couldn’t help but notice that the power button on my Flo6/MSI B550 Tomahawk PC was blinking this morning. That means it’s sleeping and needs a touch to wake itself back  up. Indeed, that blinking power button is the unmistakable signature of S3 sleep — Suspend to RAM — where the system cuts power to everything except memory. Nobody asked it to do that. Time to find out why it thought that was a good idea. Hence, I found myself troubleshooting Flo6 S3 sleep oddities.

Troubleshooting Flo6 S3 Sleep Oddities: Step 1

My first move with any uninvited sleep behavior is to open an elevated command prompt and run powercfg /a. This dumps a plain-English summary of every sleep state the OS currently considers available — and, crucially, tells you which ones are actually enabled. The lead-in graphic shows what Flo6 reported.

That told me everything I needed to know at a glance. S3 was alive and well. Hibernate was also active. Windows had a full menu of power-down options available to it, and apparently it was helping itself. The next question was: what power plan setting was pulling the trigger?

Step 2: Drilling deeper

To see exactly what the current power scheme was telling Windows to do with sleep, I queried the sleep sub-group directly with powercfg /query SCHEME_CURRENT SUB_SLEEP. The output is verbose, so here’s the relevant section I was hunting for:

0x00004650 is 18,000 decimal — 5 hours on AC power. So Windows was faithfully sleeping Flo6 after 5 hours of perceived inactivity, exactly as I’d told it to in recovering from a recent, ill-advised troubleshooting test that reset all my sleep options. Nothing malicious, nothing mysterious. Just a setting I’d explicitly configured sitting where I’d put it, also wrong. Time to kill it.

Pulling the Plug on the Sleep/Wake Timers

I wanted three things gone: the Sleep After timer, Hybrid Sleep, and Wake Timers. Setting any timeout value to 0 disables it. I ran the following commands, covering both AC and DC (battery) power states for completeness, even though Flo6 is a desktop that will never run on battery:

As a belt-and-suspenders measure, I also went into Device Manager, expanded the Universal Serial Bus controllers node, and for each USB Root Hub, opened Properties > Power Management and unchecked Allow the computer to turn off this device to save power. USB Selective Suspend has a well-documented history of nudging systems toward sleep states in ways that aren’t immediately obvious from power plan settings alone. Worth the two minutes it takes to disable it across the board.

The EC Reset: Clearing the Firmware’s Memory

OS-level changes are necessary, but they don’t always flush stale power-state data that’s been cached at the firmware level. The MAG B550 Tomahawk MAX has an Embedded Controller that can hold onto a previous power state even after you’ve changed every relevant Windows setting. The fix is straightforward: shut Flo6 down cleanly, flip the PSU switch off, unplug the AC cord, then hold the case power button for 15 to 30 seconds. This drains the residual charge and forces the EC to reinitialize from scratch. Reconnect everything, power on, and let the board POST fresh. It’s a small step, but it closes a gap that software alone can’t address.

Verdict: Flo6 Should Stay Awake

Hopefully, Flo6 makes it through the night — and several nights after that — without a single uninvited nap. No blinking power button at 6 AM, no dead monitors, no manual wake required. For extra confidence, I’ve got a scheduled Task Scheduler job logging system uptime to a text file every hour overnight. If S3 ever comes back uninvited, I’ll have a timestamp trail to work from. IMO, one week’s worth of clean logs is good enough for me to call this one closed.

If I’ve missed anything, the blinking power button will be back. I hope not, but here in Windows-World anything is possible. If it’s not “case closed” I’ll report back with an addendum here. Fingers crossed that won’t be needed…

Facebooklinkedin
Facebooklinkedin