Category Archives: Troubleshooting

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

Long Trip From 26H1 To 25H2 On P16G3

June 12, 2026 Ed Tittel 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

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.
Navigate to Security → Secure Boot . Use the arrow keys. You’re looking specifically for the sub-entries one level down.
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.
Save and exit. Press F10 and confirm the save. The system reboots.
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.
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.

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

Rare Update BSOD Proves Benign

June 9, 2026 Ed Tittel 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.

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!

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, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11

Troubleshooting Flo6 S3 Sleep Oddities

May 14, 2026 Ed Tittel 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…

Device drivers, Insider stuff, Recent Activity, Troubleshooting, Updates, WED Blog, Windows 11

Firefox Update Fixes Weird Cursor Ripple

April 28, 2026 Ed Tittel Leave a comment

I’ve got to admit, I was misled this morning. After updating my NVIDIA Studio driver for the 3070Ti GPU, I noticed a strange “ripple” behavior around the on-screen cursor in Firefox. This occurred as I was scrolling inside today’s new posts and threads at ElevenForum.com. After reloading the graphics driver (WinKey+Shift+Ctrl+B), no change. So I asked Copilot: “Do I need to reboot?” “Nope,” it responded, “a Firefox update fixes weird cursor ripple” thanks to a fix for a DirectComposition code path error when using NVIDIA cards. It worked!

How Firefox Update Fixes Weird Cursor Ripple

A well-advised principle in troubleshooting relies on answering the question “What changed?” That’s what had me ready to blame the new NVIDIA driver as soon as Firefox got wonky. After taking advice from Copilot, I noticed further that the cursor ripple was indeed limited only to Firefox. It didn’t show up in Chrome or Edge, nor in other Windows apps. If it had been the GPU driver, all would have been affected.

Thus, I’m glad I thought to ask Copilot rather than start rebooting or rolling back the driver. Turns out the cause was obvious, indeed, but related to the specific program I was running as it interacted with the NVIDIA driver. Here in Windows-World, it’s wise not to overlook the obvious. But it’s also wise to cast a wider net, so as not to blame the obvious when something else could be — and in this particular case, was — at fault.

All’s well that ends well. I’m happily using my updated system. And Firefox — where I usually work to create this WordPress content — is working correctly now, too. Bonus: updating the browser is much faster than a driver rollback, and faster than a reboot. Good-oh!

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

Power Outages Mung LAN Addressing

April 16, 2026 Ed Tittel Leave a comment

With clear skies yesterday, our house nevertheless took two power hits yesterday. The first lasted 15 minutes, the second 11 (had to reset certain appliance clocks both times). When I tried to remote into the ThinkStation P3 Ultra this morning, RDP wouldn’t connect. So I tried pinging the host name (Tsp3Ultra2) and got “destination host unreachable.” Pretty conclusive proof that power outages mung LAN addressing, since that very string worked fine yesterday.

If Power Outages Mung LAN Addressing, Then?

For the time being I’ve got Advanced IP Scanner open, and am using the “Tools” option for each network node to call Remote Desktop Connection. That tells me which PC I’m trying to get at, and uses its IP address to make things work. Good enough for now, I guess.

I’ve observed that the name table will gradually correct itself over a 24-hour period. Since our last outage happened just before 5 PM yesterday, that means I can return to using machine names for remote access later this evening. In the meantime, I have a decent workaround.

A quick check tells me that only some PCs were affected by the outage. Not surprisingly, the laptops (kept alive by batteries durng the outage) retain their machine name-to-address relationships. The desktops and mini-PCs (except Flo6, which is on a UPS) have all been renumbered.

Here in Windows-World, it’s always something. Yesterday, it was a quick pair of power glitches. Who knows what’ll hit me today?

Note Added Next Day

As I had suspected (or hoped), the machine names are now all working again. As is typical here at Chez Tittel, a 24-hour period is long enough for DHCP to work itself into usable shape. Now I know that a power glitch (or two) can upset that delicate balance. I’ll probably be reminded again sometime soon, now that thunderstorm season here in Central Texas is getting started. This time, I think the glitch came from construction work at the edge of our neighborhood where power goes from overhead to underground lines.

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

X12 Tablet Gets Clean Install

April 6, 2026 Ed Tittel Leave a comment

Something cratered the Lenovo ThinkPad X12 Detachable Tablet this weekend. I’d been screwing around with Secure Boot, recent updates, and more. When I sat at my desk Sunday morning, it was refusing to boot, and throwing error code 0xc0000428, which signals a winload.efi signature mismatch with what’s in firmware (see lead-in graphic). I did get the machine booted to recovery media on a UFD. I could’ve repaired and recovered the previous installation. But I decided that X12 Tablet gets clean install instead, so I could check a bunch of things out about a fresh, clean Windows 11 install. Here goes…

After X12 Tablet Gets Clean Install, Some Initial Checks

Having wrestled so much with Secure Boot lately, my first check was on that security layer. Indeed, Garlin’s check script revealed it was present, and more-or-less up-to-date. With minimal effort I was able to bring the X12 into full compliance with modern Secure Boot settings.

Next, I checked Smart App Control in Windows Security. It is currently set to Evaluation mode. I’m supposed to be able to switch between the On and Off states now. I need to finish configuring this PC and get an image backup tool in place, before I start fooling around with things. But the signs are promising. Right now SAC is working, and behaving just the way it’s supposed to work.

More About OOBE

After the post-GUI installation in Windows 11, the Out-of-Box Experience (OOBE) appears to guide users through final steps of the process. This time, I did get to choose the machine name I wanted (kept it at X12Hybrid) where it works properly. The network setup found my WAP right away, and I was off and running right away, too. It was also amusing to see how many, many backups I could’ve used when installing this PC (including an older X12 version dating back to 2022). But since I wanted a clean install experience, I skipped all that stuff.

Now Comes the Rest of the Job…

I’ve got to set up and customize the X12 to my usual liking. That’s probably going to mean an hour or two a day for the next few days. This afternoon I think I’m going to try using WinGet to export most of my app set from Flo6 to X12, and see how that works.

Stay tuned! It’s possible that things in my little corner of Windows-World are about to get interesting. If so, you’ll get more follow-up from your humble correspondent. So far, so good, though.

Insider stuff, Recent Activity, Troubleshooting, WED Blog

Device Zombies Roam Among Us

March 25, 2026 Ed Tittel Leave a comment

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

1. Remove them from the list while they’re still under my control
2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.