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

Jumping WinGet’s Install Technology Hurdle

Leave a comment

Wow! It’s hard to believe that WinGet has been around for over 6 years now (it made its debut on 5/19/2020). Over those years I’ve seen the upgrade block shown in the lead-in graphic many times. I’ve also learned to deal with it in more roundabout ways. Let me call this jumping WinGet’s install technology hurdle, so I can explain one particular technique worth investigating.

What Jumping WinGet’s Install Technology Hurdle Means

The text at the head of the screen cap recommends “Uninstall each package, then install the newer version.” This will work if there’s no other way. But if — as you can see is the case with Oh My Posh (OMP) — there’s an internal update mechanism, this often works just fine without requiring wholesale removal (uninstall old version) and replacement (install new one).

Indeed, it just so happens that OMP will happily update itself at the command line using the built-in command

oh-my-posh upgrade --force

So that’s what I did instead of running one WinGet command to remove the old package, and another to install the new one. This situation pops up when WinGet detects that a normal upgrade is not feasible. It blocks upgrades whenever the install technology changes from one release to the next. That’s how it avoids potential problems with the package and its supporting infrastructure that might otherwise occur.

But the teams who develop such packages know their inner workings. They can (and often do) support such upgrades because they understand how to hand off from the older install technology to the newer one. When I run into this situation, I look for a built-in update mechanism in the package (or its related app) itself. It will often jump the hurdle for me, and let me keep using WinGet thereafter. Indeed, I’ve done this myself with Adobe Acrobat too. Furthermore, GitHub documents similar cases with MS Edge, PowerShell 7, Oracle VirtualBox, LocalSend, and other packages as well.

But Wait…There’s More!

Even after I got to the latest version, I found a couple of older versions of OMP also installed. Ultimately, I DID have to uninstall those to make them go away. That’s because OMP lets multiple versions run in parallel. This time, I used msiexec and the GUIDS (for the no-longer-wanted versions) for that purpose

msiexec /x "{97557535-43B6-44EF-BA97-86563C1AC80A}"
msiexec /x "{85B43182-5A11-40E5-9E09-7EF6EB1CFDF7}"

Now, I’ve got just the one (updated) version and a clean Oh-My-Posh setup. Here in Windows-World, it’s always something. Thank goodness that Copilot was able to help me steer through the wreckage, and clean up the older versions properly. Now I see only the latest version when I run winget list, and OMP is working as it should be. AND I solved a problem I didn’t know I had. Good-oh!

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

P3 Ultra Insider Enrollment Falters

Leave a comment

Having returned a couple of loaner units to Lenovo, I recently decided to enroll the  Lenovo ThinkStation P3 Ultra — a beast of a workstation — in the Windows Insider Program to start testing preview builds. The machine was running Windows 11 Pro, TPM 2.0 was enabled, Secure Boot was on, and I had a personal Microsoft account linked. By every measure, this machine should have sailed right through that process. But alas, P3 Ultra Insider enrollment falters, and thereby hangs this tale.

Why P3 Ultra Insider Enrollment Falters

Enrollment hung. Indeed, I hit a brick wall: an eligibility error that blocked enrollment dead in its tracks. I got no clear explanation, no obvious next steps. Just a vague message and a dead end. If you’re in the same boat, you’re not alone, and there’s an easy fix. Here’s exactly what I did to get it working.

What This Error REALLY Means

The error Windows surfaces during Insider enrollment is frustratingly generic. Depending on your exact configuration, you might see language about the device not being “eligible,” a “policy restriction” preventing enrollment, or a note about account requirements — sometimes all three in the same dialog. There’s rarely a useful error code attached.

What makes this especially maddening on a machine like the P3 Ultra is that the hardware is fully compliant. TPM 2.0? Check. Secure Boot? Check. Windows 11 Pro? Absolutely check. The error fires anyway, leaving you staring at a dialog that tells you almost nothing useful about where the actual blocker is hiding.

There’s Something About the (Original) MSA

I can’t figure out what it is, but there’s something about my primary MSA that stymied the enrollment. As soon as I switched to a backup MSA and authenticated (using the MS Authenticator app on my iPhone), the process went through correctly. After a reboot, the Insider update showed up and downloaded (as you can see, it’s installing right now):

Troubleshooting Tips for Insider Enrollment

If a change of MSA doesn’t fix your issues, try looking for Group Policy that blocks preview build enrollment, or check to see if diagnostic data level is too low. Additional deets follow.

Fix the Diagnostic Data level

Navigate to Settings > Privacy & Security > Diagnostics & feedback and make sure “Diagnostic data” is set to Optional — or at minimum confirm it isn’t being suppressed or overridden by a policy. Without this, enrollment may silently fail even if everything else is correct. If the toggle is greyed out, a Group Policy or MDM policy is controlling it, and you’ll need to address that first via gpedit.msc or your MDM console.

Reset the “Manage preview builds” Group Policy

Open gpedit.msc (run as Administrator), then navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business. Find the policy named “Manage preview builds” and set it to Not Configured or, if you prefer explicit control, set it to Enabled with the sub-option that allows preview builds. Once done, open an elevated Command Prompt and run gpupdate /force to apply the change immediately without waiting for the next Group Policy refresh cycle.

Try a Personal MSA

MSAs can be of type “Work or School” or “personal.” The Insider program wants one that’s strictly personal. If all else fails, you can use a gmail, yahoo or icloud email address. MS free options include Outlook.com (though existing hotmail and live.com addresses still work, no new signups for those domains are allowed).

Insider Enrollment Issue Takeaways

Insider Program enrollment errors on modern workstation-class hardware almost always come down to one of three things: the diagnostic data level is too low, Group Policy is actively blocking preview build enrollment, or there’s an account type mismatch — a work or school identity where a personal MSA is needed. It is almost never the hardware itself.

The ThinkStation P3 Ultra is a fully Insider-capable machine. It meets every technical requirement Microsoft publishes. The blocker, in my experience and in most reported cases, is configuration — either something an IT department put in place, or a default that Windows didn’t surface clearly during setup.

Work through the three steps above in order, and there’s a very good chance you’ll be selecting your Insider channel within a few minutes. And if you hit a variant of this error that the steps above didn’t resolve, drop the details in the comments below — include the exact error message text, whether the machine is domain- or Entra-joined, and what your gpresult output shows for the Windows Update for Business policies. The more detail you share, the faster we can help narrow it down.

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

X12 Gets New Insider Look

Leave a comment

OK then. Now that I’ve fixed the boot problems on the X12 Detachable Tablet Gen 1, and rejoined the Insider Program, I’m looking around at what’s there (and what’s not, just yet). At long last. I can see the primary Insider channels (Experimental and Beta) as shown in the lead-in graphic. So finally, the X12 gets new Insider look and feel in Settings > WU > WIP and elsewhere. So glad!

As X12 Gets New Insider Look, Now What?

i can finally start looking for new features and capabilities under the Windows 11 umbrella, as MS continues working toward the upcoming 26H2 release. So far, as is often the case, I’m looking for things — such as the new-look Shut Down controls (see this WinAero story for info & screencaps) — that haven’t made it onto the X12 just yet. I know, I know: I can use ViveTool to turn them on. But I’m determined to wait and see how things emerge as MS widens its controlled release coverage.

That said, I am delighted to see my Insider Program options finally synch up with the Experimental and Beta channel offerings (with option to turn on Release Preview, as you see at bottom right in the screen cap). Now, I just need to be patient, and wait for more new features to start showing up.

Items of Particular Interest, IMO

Since I’ve got suitable boot media, I want to see if I can spot the Cloud Recovery option when booting into WinRE. Alas, Copilot says that’s an Experimental feature only, so I may need to switch the ThinkStation P3 Ultra Gen3 over to that channel.

Today’s Patch Tuesday, so I can check later (via Update History) to see the new Unified Update Experience at work. It should also be interesting to see if anything else shows up in today’s update announcements. Stay tuned! I’ll keep you posted…

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

Despite Throwing Error, Old_mscopilot_proxy.exe Is MIA

Leave a comment

Here’s something interesting and mildly mystifying. If you use Reliability Monitor to keep tabs on Windows stability, you may have spotted old_mscopilot_proxy.exe as a problem item — I certainly have. My most recent entry occurred July 6, 2026, at 12:02 PM. That naturally sent me hunting for the file so I could understand what it was doing and if I could delete it safely. What I found — or rather, what I didn’t find — tells a nifty story about how Reliability Monitor actually works. Despite throwing error, old_mscopilot_proxy.exe is MIA when I try to search (and perhaps root) it out.

Despite Throwing Error, Old_mscopilot_proxy.exe Is MIA

Take a look at the lead-in graphic. It shows the error details from Reliability Monitor. Basically, it’s saying that the app has quit working. To be more specific, it says the program has “stopped interacting with Windows and was closed.” The version number provided — 149.0.4022.80 — follows a Chromium-based versioning scheme Microsoft adopted for its Copilot app. That’s an important and concrete clue about the file’s true origin.

Key factoid: the old_ prefix is a standard artifact of Microsoft’s in-place updater for Copilot. Before dropping a new executable, the updater renames the currently running binary to old_[filename].exe as a rollback maneuver. Once the new version installs successfully, that old_ file should be cleaned up automatically. In practice, that cleanup step fails silently with some regularity, leaving an orphaned executable on disk — and a crash record in the event log when the system subsequently tries to invoke it.

Seeking Old Copilot Files/Versions

Knowing where the file should be is not the same as finding it. I ran Get-ChildItem searches against C:\Windows, LocalAppData, Program Files, and the notoriously ACL-locked C:\Program Files\WindowsApps folder — all with -ErrorAction SilentlyContinue to suppress access-denied noise. Every search returned immediately with no output. I then queried the Windows Error Reporting archive and queue folders using Select-String to look for any .wer report referencing the file. Nothing there either. Finally, I launched Voidtools Everything as administrator, triggered a full C: rescan, and searched again. The file is completely absent, gone MIA.

Why Does ReliMon Report This Error?

Here’s the part that catches people off-guard, including your humble author. Reliability Monitor does not verify live disk state before displaying an error entry. It reads the Windows Application Event Log — specifically Event ID 1000 Application Error records. These persist independently of whether or not the executable they name still resides on disk. Such log entries cannot be selectively deleted in Windows, either. You’d have to clear the whole Application log to remove them, which is far too blunt an instrument for this situation.

When in Doubt, Do No Harm (Nothing)

There’s really no need to do anything about this error, except to recognize its (in)significance. The file is gone, the Windows Error Reporting reports are gone, and the Application event log entry from July 6 will age out of Reliability Monitor’s 28-day display window naturally — in my case, by August 3, 2026. If you want to confirm that the event log is the sole remaining source of the entry, run this command string in an elevated PowerShell session:

Get-WinEvent -LogName Application | Where-Object { $_.Message -like "*mscopilot_proxy*" } | Select-Object TimeCreated, Id, Message | Format-List

When I run it, I get hits from 7/6, but also 6/19, 6/12, 5/28, and then weekly back to 4/14. This, apparently, is a pretty constant (if bogus) error on the Flo6 system. Indeed, Copilot tells me “the ghost error pattern — where a file that no longer exists keeps appearing in Reliability Monitor — is surprisingly common and poorly documented.”

But once you understand that Reliability Monitor reads historical event log records rather than interrogating live disk state, these apparent mysteries resolve themselves. The file is gone, the risk is zero, and the entry will vanish from ReliMon on its own (though it remains in the error log). Sometimes the best fix is no fix at all, particularly when there’s nothing wrong, nor anything to repair. Here in Windows-World, doing nothing can come as a welcome relief. That’s my take, anywho…

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

WinGet List/Install Orders Seldom Match

Leave a comment

If you run winget upgrade --all --include-unknown regularly, you have probably noticed something odd. The packages listed in the upgrade table rarely install in the order they appear. I hit this recently on my ThinkPad X12 Hybrid Tablet, where six packages needed attention: Google Chrome, Microsoft Teams, MiniTool Partition Wizard Free, Oh My Posh, Patch My PC Home Updater, and Windows App. They were listed in one sequence but installed in a noticeably different one. The explanation stems from WinGet’s dependency resolver. It’s worth understanding, and explains why WinGet list and install orders seldom match each other.

Why Do WinGet List/Install Orders Seldom Match?

As you can see in the lead-in screencap, the upgrade table that WinGet displays before installation is sorted alphabetically by package display name — that is the first (Name) column, not the Id column. It’s purely cosmetic: WinGet queries its source index, collects available updates, and orders the results for human readability. The order in that table carries no weight when determining which package installs first. Think of it as a shopping list arranged by aisle label, not a build sequence.

Install Order Shows a Dependency Graph

Before the first installer touches the PC, WinGet’s dependency resolution engine reads every package manifest in the upgrade set. It constructs a directed acyclic graph (DAG) of declared dependencies. Next, it runs a topological sort namedGetInstallationOrder() on the winget source. That produces an install sequence where no package arrives before its pre-reqs are satisfied. This re-ordered queue need not follow name or ID order.

The X12 Hybrid Tablet Run

In the screencap, you see the raw WinGet output from a recent run on the X12 Hybrid Tablet. Six packages are available, listed in alphabetical order by display name — Chrome, Teams, MiniTool, Oh My Posh, Patch My PC, Windows App. The three declared VCLibs and Windows App Runtime dependencies follwing that list reinforce that notion that other elements than those that appear are in the mix. In the end, the actual install order was MiniTool Partition Wizard, Patch My PC…, Chrome, Teams, Windows App, and finally, Oh-My-Posh.

When List Order and Install Order Do Align

Occasionally the two sequences match — but that is coincidence, not design. It happens when none of the packages in the upgrade set declare inter-package dependencies and WinGet’s internal queue order happens to mirror alphabetical sequence. As soon as one package declares a dependency on another — or on a shared runtime — the topological sort reshuffles the queue and the coincidence evaporates.

A Practical Takeaway

No need to manage this manually. Winget’s dependency resolver handles the sequencing reliably. Indeed, fighting it with flags like --skip-dependencies is rarely worth the risk. Tyring to drive this yourself, you might end up with a package that installs against a runtime version it does not actually support. Trust the DAG, watch the dependency notice block that appears before the first installer fires, and you will get a clear picture of why the WinGet upgrade install order looks the way it does.

Next time you notice that WinGet installs packages out of listing order, check the dependency notice block at the top of the install run. That block is where WinGet “shows its work.” That’s where the topological sort result gets laid out in plain text. It is one of those quiet, well-engineered behaviors that rewards users who take a moment to read the output carefully.

Further proof of my earlier contention (see this June 27 post) that “WinGet knows more than it says.” I think so, but you can make  your own judgement. Here in Windows-World, there’s plenty of room for multiple takes on what’s REALLY going on. This is mine…and I’m sticking to it!

 

Facebooklinkedin
Facebooklinkedin
Hardware Reviews, Insider stuff, Recent Activity, WED Blog, Windows 11

Readying Evals for Lenovo Return

Leave a comment

When you evaluate hardware for OEMs, returning loaner units is as routine as unboxing them. But before you seal the box and hand it to FedEx, there’s a discipline worth building: systematically clearing the device from every Microsoft service it touched. I recently returned two Lenovo systems: a ThinkPad P16 Gen 3 Mobile Workstation and a Yoga Slim 7x Gen 11. The cleanup checklist I used is worth walking through step by step. Having learned the hard way that simply sending them back as-is can raise issues later on, I’ve now got a process when readying evals for Lenovo return. Here goes…

What’s Involved in Readying Evals for Lenovo Return?

Skipping any of the upcoming steps  leaves your Microsoft account linked to hardware you no longer control. That creates two concrete problems. First, the device continues to count against Store app device limits, potentially blocking installs on other machines. Second, a lightly wiped eval unit could retain enough account metadata to give the next user — or Lenovo’s refurb process — unwanted access to your digital identity. A five-step cleanup eliminates both risks entirely. Those five steps are:

Step 1 — Back Up and Sign Out First

Before touching any Microsoft account settings, make sure anything worth keeping is backed up to OneDrive or an external drive. Next, sign out of OneDrive on the device itself so that the sync relationship is severed cleanly. Finally, if you signed into Lenovo Vantage, Lenovo ID, or any Lenovo warranty and support services, sign out of those as well before the Windows reset.

Step 2 — Reset Windows to Factory Condition

On each laptop, navigate to Settings → System → Recovery → Reset this PC, then choose Remove everything. Select the option that also removes apps and settings — not just personal files — and, if prompted, choose to clean the drive thoroughly rather than just removing files. This ensures that your account credentials, app data, and Windows Hello biometrics are gone before the device leaves your hands.

Step 3 — Remove Device from MSA

Head to account.microsoft.com/devices and sign in with the Microsoft account you used on the eval units. Locate the ThinkPad P16 Gen 3 and the Yoga Slim 7x Gen 11 in the device list. For each one, select Remove device and confirm the prompt — Microsoft formally removes the PC from your registered devices list, which tidies your account and eliminates that association permanently.

Step 4 — Unlink from MS Store Device List

The Store maintains a separate device roster that governs app license limits — removing a device from the main account list does not automatically update this list. Go to account.microsoft.com/devices/content, find each Lenovo system, and click Unlink. Once unlinked, neither machine counts against your Store device limits, so your remaining systems can claim those license slots without any manual intervention.

Step 5 — Verify Before You Box & Ship

Refresh both pages — account.microsoft.com/devices and account.microsoft.com/devices/content — and confirm that neither the P16 Gen 3 nor the Yoga Slim 7x appears any longer. Only after both are clear should you box the units up. This verification step takes thirty seconds and removes any doubt that the cleanup completed successfully.

Return Workflow Summary

It’s worth noting that these steps apply any time you intentionally let a Windows PC (or laptop) out of your hands: sale, gift, return. donation, or whatever. It helps you make sure the next recipient gets a clean machine, and keeps your count of registered devices in synch with what you’ve got. Here’s a super-brief list of to-dos:

  1. Back up everything needed and sign out of OneDrive.
  2. Sign out of Lenovo Vantage, Lenovo ID, and Lenovo support services.
  3. Reset Windows: Settings → System → Recovery → Reset this PC → Remove everything.
  4. Remove device at account.microsoft.com/devices.
  5. Unlink device at account.microsoft.com/devices/content.
  6. Verify both pages are clear, then box and ship.

Building this habit pays dividends over time — especially if, like me, you work with a steady stream of hardware. The whole process takes less than an hour per device. And it leaves your Microsoft account in a clean, accurate state that reflects exactly what you actually have and use. Ship with confidence knowing your digital footprint stayed behind. Here in Windows-World, it’s best to tread lightly and carefully when you can.

Facebooklinkedin
Facebooklinkedin
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
Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

X12 Runs Production Win11 After Boot Repair

Leave a comment

Here’s an odd one. I just  fixed a broken boot environment on my ThinkPad X12 (Gen 1) Hybrid Tablet. Oddly enough, Winver is now showing Windows 25H2 Build 26200.8737. What makes that odd? Prior to the fix, I’d been running the Beta release, Build 26220.8370. Hence my conclusion that the X12 runs production Win11 after boot repair. All I can say is: WTF?@*

Why X12 Runs Production Win11 After Boot Repair?

That’s the question I asked Copilot right away once I figured things out. Here’s what it said (bold emphasis mine):

bcdboot reconstructed the EFI boot environment from the on-disk Windows 25H2 partition, laying down a clean, production-signed bootloader baseline with no awareness of the machine’s prior Beta channel enrollment. The Garlin script then installed the production-variant SkuSiPolicy.p7b, which writes itself as a UEFI firmware variable and enforces production-level Secure Boot signing rules. This blocked the pre-release trust chain that Beta channel builds rely on, so Windows Update classified the device as a retail endpoint. It then served it the latest production-signed CU, build 26200.8737, not a Beta flight.

Whoa! Who knew that could happen? But sure enough when I visit Settings > Windows Update > Windows Insider Program on the X12, it tells me to “Join the Windows Insider Program.” This PC is clearly unenrolled and running a production build. Amazing!

Plus ça change…

Here in Windows-World, strange is just part of the day-to-day game. This latest little wrinkle, however, ranks pretty high on my own Strange-O-Meter. But as long as the laptop is working and doing what it should, I’m happy. In fact, I’m bemused because the official word is you can’t leave the Insider Builds unless you do so at a precise moment when it’s allowed, or perform a clean install. Seems like — at this moment, at least — here’s another way!

 

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

USB-C UFD Restores X12 Boot

2 Comments

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

Author, Editor, Expert Witness