Category Archives: Windows Update

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

Pending Update Hangs WinGet

Leave a comment

Yesterday was Patch Tuesday (Aug 11), so I got a change to watch something go down I’d  not yet seen. Just before lunch, I fired off a quick winget upgrade --all --include-unknown. I figured it would chew through those updates in time for me to switch to sandwich construction. Wrong! Instead, WinGet got stuck and sat frozen, spinning its wheels on a package install. Only slowly did it dawn on me I’d just gone through the monthly update cycle. Further inspection showed … sure enough … a pending update hangs WinGet (or rather, a pending restart from said update gums up the works). Let me explain…

Why Pending Update Hangs WinGet

The most common culprit is a prior installation that never cleanly resolved or completed. Windows Package Manager tracks install state in its internal database, and if a previous run was interrupted (by a power cut, forced close, network drop, etc.) that package can stay flagged as “installing” or “pending.” As a result, subsequent upgrade attempts collide with that ghost state and stall out.

In addition, App Installer (Microsoft.DesktopAppInstaller) itself may be out of date. WinGet is delivered as part of App Installer via the Microsoft Store, and an outdated build can exhibit hang behavior. That goes double after a major Windows update reshuffles underlying framework dependencies. Therefore, ruling out a stale WinGet client is always step one before you go deeper.

Source index staleness is another common trigger. WinGet pulls its package catalog from indexed sources. When those indexes go stale or become partially corrupted, upgrade queries can time out or loop indefinitely. Finally, UAC and permission conflicts can silently block the installer process. This happens mostly often if you’re running without elevation or if a previous elevated session left a lock on a staging directory. Watch for exit code 0x8A15000F (installer still running). That’s Windows Package Manager’s way of telling you it thinks something is already in flight. (See the WinGet exit codes reference for deets.)

What happened to me yesterday was that the pending restart left some unresolved packages in limbo, including the AppInstaller itself. A quick restart took care of those gotchas, and allowed WinGet to do its thing unimpeded.

Fixing a WinGet Pending Update Hang

Work through these fixes in order. Each one resolves a progressively deeper layer of the problem, so start at the top and stop as soon as WinGet is moving again.


winget upgrade --all --include-unknown
winget source update
Install-PackageProvider -Name NuGet -Force Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery Repair-WinGetPackageManager -Force -Latest
winget upgrade --id --silent
winget source reset --force

And, of course, if it’s Patch Tuesday, or some kind of Windows Update has been applied recently, check for an restart notification first. If one is pending, get it out of the way. That’ll keep it out of WinGet’s way, too. Here in Windows-World, it never pays to overlook the obvious. Cheers!

Tip: Check the Logs
When a hang is stubborn, the logs will tell you exactly where the process is choking. Run winget --info to find your log directory, or navigate directly to:
%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_
8wekyb3d8bbwe\LocalState\DiagOutputDir (reassemble onto single line to cut'n'paste, or do like me and point Everything at DiagOutputDir).
You can also append --logs or --verbose-logs to any WinGet command to capture a full diagnostic trace of that specific run.

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

Insider Preview Build Expiration

Leave a comment

In today’s coverage at Windows Central, I found an interesting item. Indeed, the title is a little scary “Windows Insiders have one week to update their PCs, or else.” It seems that Insider Preview builds come with “flight certificates” that include an expiration date, and numerous builds will be hitting that date next Tuesday, August 11. Insider Preview build expiration comes with some gotchas, so it’s a good idea to update in advance to avoid them. Let me explain…

What Does Insider Preview Build Expiration Mean?

Thankfully, any Insider Preview expiration date is easy to find. If you look at the snippet of winver.exe output above, you’ll see it identifies itself as “[t]he Windows 11 Pro Insider Preview operating system…” It also provides expiration data, i.e. “Expires 10/31/2027 6:43 PM.”

As it happens, Microsoft embeds time-limited cryptographic certificates in every Windows Insider Preview build. These are called flight certificates, and when they expire, things get weird, fast. This post covers what flight certificates actually are, how to check whether your build has been renewed, and what happens if you let that clock run out.

Not Just a Pun:  Flight Certificates

A flight certificate is a code-signing certificate that Microsoft embeds directly into every Windows Insider Preview build. The name comes from Microsoft’s internal terminology for Preview builds — “flighting” — the practice of distributing pre-release builds to rings of volunteer testers. Think of the certificate as both a seal of authenticity and a built-in expiration thing.

Both of the flight certificate’s jobs are straightforward. First, it authenticates that the preview build you’re running is genuinely from Microsoft. That is, it’s not some 3rd-party repackage of dubious origin. Second, it acts as a gentle but insistent timer. As the certificate approaches its expiration date, the system begins reminding you to update. Let it fully expire, and the nudging stops being gentle.

There are some things a flight certificate is not: it has nothing to do with product activation, your MSA, or installed apps and files. Your activation status is unaffected by certificate renewal. The cert lives at the build level, not the license level.

Flight Certificates Come and Go Regularly

Microsoft renews flight certificates routinely, with an updated cert inside each new Insider Preview build. What’s unusual about the current renewal cycle is its scope. Historically, certificate renewals have mainly been a Canary Channel issue. This time, the renewal covers all channels (Experimental, Beta, and Canary). That’s a broader reach than typical and tells us that the flight certificate now applies across all active Insider flighting channels.

Here’s the thing (and the reason for the clickbait style Windows Central article title). The old certificate expires August 11, 2026. For Beta Channel on 25H2, the minimum renewed build is 26220.9022, which has been available since July 31, 2026. If you’re on that build or later, you’re already good through October 2027.

If not, unpleasant things may happen to your PC if you don’t upgrade in advance. As the Windows Central article states: “You will also stop receiving automatic background updates once the flight certificate expires.” See next section for more icky details.

Finding Flight Expiration Info

Checking your expiration date takes about ten seconds. Press Windows key + R, type winver, and hit Enter. The About Windows dialog that pops up will show an Evaluation copy line near the bottom, followed by an expiration date. If that date is after August 11, 2026, congratulations — you’re already on a renewed build and can stop worrying.

If your date is on or before August 11, 2026, you’ll want to act before the deadline arrives. Here’s what happens if you don’t:

  • A persistent “This build will expire soon” watermark appears on your desktop. You can’t dismiss, minimize, or right-click it away.
  • Automatic background updates stop arriving. You fall off the flighting pipeline entirely.
  • The machine doesn’t stop working, but it does become an isolated island: no new Insider Preview builds, no flight certificate renewal, no path forward except a manual update (clean install).

The fix is mercifully simple. Head to Settings > Windows Update > Check for updates. Then, let it find and download whatever’s on offer, install it, reboot. One update cycle and you’re current. The renewed certificate ships with the build, the watermark goes away, and normal flighting resumes.

I’ll admit: I’ve watched cert expirations play out on test machines over the years. But this one genuinely caught me off guard — not because it snuck up on me, but because my Beta Channel machine had already sorted itself out entirely on its own before I’d even noticed there was a deadline to worry about. Silent competence from Windows Update. Here in Windows-World that counts as success.

Further Reading

If you’re running multiple test PCs across channels the way I do, this is worth bookmarking now rather than rediscovering in a scramble on August 10th. For a solid news-side breakdown of the timeline and urgency, start with Sean Endicott’s Windows Central report, which does an excellent job of framing the stakes for everyday Insiders.

For the authoritative technical detail straight from Microsoft, including channel-by-channel minimum build numbers and step-by-step renewal instructions, Microsoft’s flight certificate renewal FAQ is the definitive doc. And if you’re new to the Insider Program or just want a solid orientation on how the whole flighting system works, the Windows Insider Program on Microsoft Learn is a good starting point. For a comprehensive look at which builds are available in which channels right now, the Windows Insider Flight Hub tracks the complete build-by-channel matrix.

Stay current if you can. The whole point of Insider Preview build expiration is to keep the testing community on builds that reflect where Windows is headed, not where it was six months ago. Keeping up is part of the Insider credo. You’ll get used to it: I sure have!

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

Overhauling WU Orchestrator and Arbiter

Leave a comment

Windows Update (aka WU) has always been something of a “black box.” One clicks “Check for updates,” and watches a progress bar lurch along. At it sticks at various points along the way to completion, one wonders what’s going on inside the PC. The answer comes from two little-known components that handle updates behind the scenes. These are the Windows Update Orchestrator and Arbiter. As MS promises it’s overhauling WU Orchestrator and Arbiter, it’s a good idea to dig in and understand what they are, and what they do. Buckle up! Here we go…

Why Is MS Overhauling WU Orchestrator and Arbiter?

Simply put, the progress bar as it currently works doesn’t do its job. Also, when the update process finishes, post-update cleanups don’t exactly bring Windows up to full performance any time soon. TLDR version: this overhaul intends to address those things, probably in the upcoming August 11 Cumulative Update, due next Patch Tuesday.

What Is the Windows Update Orchestrator?

The Windows Update Orchestrator — formally the Update Orchestrator Service, or UsoSvc — is the scheduling brain of the entire update pipeline. It decides when your PC checks for updates, when downloads begin, and when installation kicks off, all without direct user intervention.

Think of the Orchestrator as an air traffic controller. It coordinates between your active hours, battery and network conditions, and Microsoft’s own delivery servers. When conditions align, it clears the update to land.

The Orchestrator talks to Windows Update’s policy engine, reads Group Policy and MDM settings on managed machines, and queues work for downstream services. It runs quietly in the background, even when you’re not thinking about updates at all. You can see a schematic of this workflow as the lead-in graphic above.

What Does the Arbiter Do?

If the Orchestrator is the scheduler, the Arbiter is the referee (as its cognomen is meant to declare). The Arbiter’s job is to resolve conflicts between competing update requests — for example, when a driver update and a cumulative security patch both want to run at the same time, or when a pending restart faces an active user session.

The Arbiter also decides which updates take priority. It weighs patch criticality, determines if a reboot is already pending, and whether or not the device is on a metered connection. When the Arbiter approves an update, it signals the Orchestrator to proceed. Without that handshake, nothing moves.

Together, the Orchestrator and Arbiter form a tightly coupled scheduling and arbitration layer that sits above the actual download and install services — but below what you see inside Settings.

Why They’ve Frustrated Users for Years

The problem has never been that the Orchestrator and Arbiter do their jobs poorly. Generally, they do not. The problem is that they remain nearly opaque to the progress reporting layer that feeds  Settings. It’s more than a bit of a disconnect, in fact!

For example, you might see the Windows Update progress bar freeze at 0 percent, spike to 74 percent, then crawl back to 12 percent. That odd behavior is not the update failing. It’s the Orchestrator and Arbiter operating normally. Alas, their internal state isn’t accurately mapped to a UI percentage value. The progress bar has essentially been guessing. When it guesses wrong, things jump around. That happens…pretty regularly.

Post-update sluggishness is a related phenom. Once installation completes, Windows leaves temporary staging files, old component-store fragments, and residual update scaffolding behind. It then cleans up lazily over the next few minutes. On lower-powered PCs (the kind that technically meet Windows 11’s TPM 2.0 and CPU requirements but aren’t exactly fast) such cleanup makes some systems feel broken right after reboots.

What Microsoft Is Fixing Right Now

In builds 26200.8968 and 26100.8968 Microsoft has shipped two targeted improvements. These represent the latest Release Preview updates for 25H2 and 24H2, respectively and just appeared last week.

First, progress reporting among the Orchestrator, Arbiter, and the Settings UI is rebuilt. The percentage displayed now reflects actual download and installation state rather than a guesstimate. Going forward, a progress bar that stalls at 45 percent genuinely means the update is 45 percent complete. It’s no longer because the Orchestrator just stopped talking to the UI.

Second, post-install cleanup runs more aggressively at the end of the update cycle rather than spreading work across the next several minutes. Systems should reach full responsiveness faster. This should be a welcome change for anyone who reboots after Patch Tuesday and wonders why things feel sluggish for the next 10 minutes (or more).

When Will Orchestrator and Arbiter Change?

These changes are in Release Preview now and should show up for mainstream Windows 11 users via a Patch Tuesday cumulative update within one to two months. I’m thinking August 11, but it could be September 8, depending on telemetry from these latest Release Preview CUs. MS will hold them back if it needs to tinker some more. Hopefully, it happens sooner, not later.

Neither fix is glamorous, but both address complaints that Windows users have logged for years. A trustworthy progress bar and a snappy post-update experience are not unreasonable expectations for a modern OS. Here in Windows-World, we’ll wait and see how things go. Stay tuned: I’ll keep you posted…

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
Backup/Restore, Insider stuff, Recent Activity, WED Blog, Windows 11, Windows Update

Nearly Perfect PITR Makes Windows 11 Debut

Leave a comment

Point-in-Time Restore (PITR) is one of the most interesting recovery features Microsoft has added to Windows 11 in recent memory. It arrived quietly through cumulative update KB5095093 in June 2026. Yet it brings a welcome new option for users who want a fast way to roll back their systems. PITR works by capturing snapshots of key system areas. These snapshots let you return your PC to an earlier state when something goes wrong. The idea is simple, and the execution is surprisingly smooth. In fact, I’d say MS has delivered a nearly perfect PITR to the OS.

What Makes It Nearly Perfect PITR, and Nor More or Less?

PITR creates restore points that include system files, settings, and some application data. These snapshots live on the local drive. They also tie into Microsoft’s cloud services when available. This hybrid approach gives PITR more flexibility than older tools like System Restore. It also makes the feature more resilient when local files become damaged. With the release of KB5095093, PITR gained a major upgrade: it now appears directly inside WinRE. That means you can access PITR even when Windows won’t boot. You can see it as a Troubleshoot option in WinRE in the lead-in graphic.

Seeing PITR listed in the WinRE Troubleshoot menu feels like a big step forward. It signals that Microsoft wants PITR to serve as a real recovery tool. You can boot into WinRE, choose Point-in-Time Restore, and pick a snapshot to roll back to. The process is quick and clear. It also avoids the complexity that sometimes comes with older recovery methods. For many users, this will be enough to fix common problems.

What Limits Warrant a “Nearly Perfect” Label?

Still, PITR is not a full replacement for image-based backup solutions. Tools like Macrium Reflect and Hasleo Backup Suite offer deeper protection. They create complete disk images that capture every sector of a drive. These images can be mounted like virtual disks. That means you can browse them, copy files out of them, and inspect their contents. PITR cannot do that. Its snapshots are not mountable. They do not support file-by-file access. They also do not cover the entire disk.

This difference matters when you need more than a simple rollback. If a drive fails, PITR cannot help. If you need to recover a single file from a past state, PITR cannot help there either. Image backups shine in these situations. They give you full control over your data. They also let you restore a system even when the internal drive is gone. PITR is faster and easier, but it is not as complete.

Even so, PITR fills an important gap. It offers a middle ground between System Restore and full image backups. It is quick, lightweight, and built into Windows. The addition of WinRE support makes it far more useful. You can now rely on PITR when Windows refuses to load. That alone makes it worth enabling.

Worth Enabling, But Not A Panacea

In the end, PITR is a welcome addition to Windows 11. It is not perfect, but it is close. For everyday problems, it may be all you need. For deeper issues, image backups remain essential. The best approach is to use both. PITR gives you speed. Image backups give you safety. Together, they create a strong recovery strategy for any Windows system.

To check PITR and it settings visit, Settings > System > Recovery > Point-in-time restore. On my systems it’s enabled by default with a single PITR restore point every 24 hours, 72 hour retention, and a space ceiling 2.0% of disk capacity. YMMV. Check it out: seems like a nearly perfect addition to Windows 11’s recovery capabilities.

To learn more about PITR, read this June 23 Windows IT Pro blog post “Point-in-time restore for Windows 11 is now generally available.” Lots of good stuff in there!

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

Patch Tuesday Delivers Odd Recycle Bin Glitch

Leave a comment

Take a look at the lead-in graphic. It shows the File Explorer listing for a recently deleted file in Recycle Bin, with the confirmation dialog below. Notice the original filename is Update-UEFI.bat (above) but the confirmation identifies that file as $RXE56IL.bat. All Windows versions with the June 9 updates show such a changed file name. Hence my claim that Patch Tuesday delivers odd recycle bin glitch.

What Patch Tuesday Delivers Odd Recycle Bin Glitch Means

Two things. First, something is exposing the internal filenames that the Recycle Bin always employs to users. Second, the glitch is benign. You can go ahead and confirm the deletions, even though the name appears to point at something unknown and unrelated. It’s just another little Windows glitch. Fortunately, it’s nothing to worry about.

You can read more about it in the Windows 11, June 2026 Issues List. The relevant item is entitled “Deleting a file from the Recycle Bin displays an internal filename in the dialog.” It ties the issue to KB5095051. MS also says further:

We are working to release a resolution in a future Windows update and will provide more information when it is available.

Not Much to See; Go About Your Business

While interesting and possibly amusing or annoying, depending on your inclination, this little glitch doesn’t appear to pose any threats. Even though the name has changed, the recycle bin functions as it always has. As you can see from the lead-in screencap, you can keep things straight by dropping the confirmation dialog atop the File Explorer window in which Recycle Bin is open.

Just another brick in the wall, I guess, here in Windows World. It gave me a chuckle, though. I hope you find it likewise diverting. Cheers!

Note Added 1+ Hours Later…

Just saw Kevin Okemwa’s story at Windows Central right now. It’s equally odd that he and I would come up with nearly identical titles for our coverage of this topic independently. Have to give props and recognition to observe this occurred by coincidence, not copying.

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

Lenovo PC SVNs Can Vary

Leave a comment

I have multiple Lenovo machines in my office. This morning I was checking a ThinkPad P16 Gen 3 mobile workstation and a ThinkStation P3 Ultra desktop in the wake Patch Tuesday’s update. Both run Windows 11, with Secure Boot enabled. While poking around in their Secure Boot UEFI settings, I noticed something that stopped me cold. These two machines report different Secure Boot SVN values. Same vendor. Roughly the same generation. Same security feature switched on. So why the difference? As it turns out, the answer is genuinely interesting, and it matters if you manage a mixed fleet of Lenovo hardware. Bottom line: Lenovo PC SVNs can vary. Let’s explore…

How Is It That Lenovo PC SVNs Can Vary?

SVN stands for Secure Version Number — a monotonically increasing counter (meaning it only ever goes up, never down). It’s embedded directly in UEFI firmware. Its job is to record how many Secure Boot security revisions a device has seen over its lifetime.

Let’s distinguish the Secure Boot SVN from two things it often gets confused with. First, it is not the same as the Secure Boot DB/DBX (the UEFI allow-list and deny-list databases that control which bootloaders and drivers are trusted or revoked). Second, it is not the same as your plain BIOS version number. The BIOS version tracks firmware feature releases; SVN tracks security-policy changes.

The practical muscle behind the SVN is its rollback prevention. If a piece of firmware or a bootloader carries a Secure Boot SVN lower than the minimum value stored in non-volatile memory, the UEFI stack simply refuses to load it. That makes it much harder for an attacker to downgrade your firmware to a vulnerable older version — a classic attack vector the SVN is designed to close.

Lenovo P16 Gen 3 vs. ThinkStation P3 Ultra

The lead-in graphic shows the output from Garlin’s check script and the get-SecureBootSVN command on the P16. Here’s what I found on the P3 Ultra, by way of contrast and comparison:

For the P16 Gen3 SVN is 8.0; for the TSP Ultra, it’s 9.0. WTF?

My first instinct was that something was misconfigured. It was not. These two machines serve quite different market segments. The P16 Gen 3 is a mobile workstation, designed for road warriors and power users who demand both portability and security. The ThinkStation P3 Ultra is a compact desktop workstation, built for workstation-class compute in a fixed location, where stability and long-term reliability tend to trump rapid update cycles.

Critically, the two platforms ship from separate firmware engineering teams inside Lenovo, each running its own BIOS release cadence. ThinkPad-family machines — including the P16 series — have historically received more frequent UEFI updates, driven by the constant churn of mobile power-management tuning, thermal firmware, and rapid security patch integration. ThinkStation platforms, by contrast, follow a slower, more deliberate update cadence that prioritizes stability for long-running workloads. Neither approach is wrong. They just produce different Secure Boot SVN trajectories over time. This time, however, the usual order got stood on its head: the ThinkStation preceded the ThinkPad.

How the SVN Update Pipeline Works

To really understand the divergence, you need to know how the Secure Boot SVN update pipeline actually flows. It is a three-layer process, and each layer operates on its own schedule.

  1. Microsoft issues a Secure Boot policy change or DBX update. A concrete example: the revocation of vulnerable bootloaders tied to CVE-2023-24932 (the so-called BlackLotus UEFI bootkit vulnerability). Microsoft publishes updated Secure Boot DB and DBX payloads, and the associated policy mandates a new minimum SVN level.
  2. OEMs like Lenovo incorporate updated SVNs into a new BIOS/UEFI release. Here is where the divergence begins. Lenovo’s mobile and desktop firmware teams each pick up the Microsoft changes on their own schedules. The ThinkPad team typically ships updated BIOS builds faster; the ThinkStation team takes longer to validate the changes against its broader ISV (independent software vendor) compatibility matrix.
  3. Windows Update stages Secure Boot DB/DBX changes to end-user systems in controlled waves. Microsoft doesn’t push Secure Boot policy changes to every machine simultaneously. It uses a staged rollout — sometimes spanning months — so different machines in your fleet can legitimately sit at different SVN levels even if they have all received recent Windows updates.

One more wrinkle worth noting: Lenovo now pre-configures newer-generation machines from the factory with both the legacy CA 2011 and the new CA 2023 Secure Boot certificates already in place. Older units, however, need a BIOS update to pick up those 2023 trust anchors. That factory-level difference alone can produce an SVN gap between otherwise-similar machines.

ℹ️ Key Insight

SVN divergence across a mixed fleet is a normal artifact of the staged update pipeline — not a sign of a compromised or misconfigured machine. The goal is parity over time, not instant uniformity.

What Should You Do?

The good news is that remediation steps here are straightforward. Here is what I recommend:

  • Update BIOS/UEFI on all machines to the latest Lenovo-published version. Head to the Lenovo Support site (support.lenovo.com), search for your specific model, and grab the current BIOS update. For the ThinkStation P3 Ultra in particular, confirm the release notes explicitly mention CA-2023 certificate integration. Do not rely on Windows Update alone to deliver BIOS updates; go direct to Lenovo.
  • Verify CA-2023 is present in the Secure Boot DB using PowerShell. Run the following one-liner on each machine to confirm the 2023 trust anchor is actually installed:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

A result of True means the CA-2023 certificate is in the DB and your Secure Boot SVN should reflect the update. A result of False means the machine still needs the BIOS update or the Windows Update wave has not yet reached it.

  • For managed fleets, track SVN parity via Intune or MECM compliance policies. Build a compliance rule that surfaces machines whose Secure Boot SVN falls below your defined minimum baseline. That way you can proactively identify stragglers before 2026 certificate expiration forces your hand.

Bottom line: Secure Boot SVN divergence across a heterogeneous fleet of Lenovo machines is normal, expected behavior. It’s no red flag. The firmware update pipeline simply operates in waves, and different product families move at different speeds. What matters is establishing a consistent minimum Secure Boot SVN across all your machines well before the 2026 CA expiration deadline arrives. Start the BIOS update sweep now, and you’ll have plenty of time to close gaps without deadline pressure.

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

Canary Jump Sows Predictable Chaos

2 Comments

After recently clean installing the 2021-vintage Lenovo ThinkPad X12 Detachable Tablet Gen 1 I decided to leave it running a production build.  That means I needed a new Canary channel test machine. So this morning, I upgraded the 2025-vintage ThinkPad P16 Gen 3 to that Insider Preview level. Unsurprisingly, this “Canary jump” sows predictable chaos. Let me tell you what happened, and what I did to recover…

Why Say: Canary Jump Sows Predictable Chaos?

No sooner did I reboot into Canary Build 26300.8246 than did all hell start breaking loose. As is my usual practice, I remoted into that PC from my Flo6 desktop — but not for long. In under less than a minute the PC crashed, and threw a slew of interesting “Critical events” as it went down. You can see them depicted in the lead-in screencap.

Of the 6 items in that list, numbers two through five are relevant. That’s because all cluster in the same minute (11:02 AM) and all are related to my remote session failing, then Windows crashing. The X-Rite Color event simply reflects the program’s unhappiness with running in a remote session (it appears again as item 6, when I start my next remote session).

The others are worth visiting in a little more detail:
• Windows stopped working comes from a bugcheck. Copilot tells me this is most likely owing to firmware or driver issues between the laptop and this bleeding edge release
• This provoked the “not properly shut down” as Windows crashed
• It culminates in the “shut down unexpectedly” as Windows turned itself off
At the start of this sequence an illegal memory reference kicked things off. This is why firmware and drivers are suspects: they’re the most likely perpetrators of such untoward acts.

Chaos Cleanup on Aisle 7!

I now understand my cleanup, had it been performed before upgrading to Canary, might have prevented the crash that occurred. I visited Lenovo Vantage, found a new UEFI update, and installed it. I ran Intel DSA, found four new drivers, and installed them. I ran the NVIDIA app, found new driver version 596.36, and installed it, too.

Now the P16G3 laptop seems to be purring right along. I’ll take it as a lesson learned (and probably re-learned) that it’s a good idea to update firmware and drivers before making major OS changes. Now that I actually stop to THINK about it, that makes pretty good sense. Even in Windows-World, it’s better to plan and aim before firing…

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

OOB KB5086672 Pops Up

Leave a comment

I just got back from my morning constitutional. Windows prompted me for a PIN upon login. Then, the “Welcome” screen took 30-plus seconds to spin before I got to the desktop. “Hmmm,” I said to myself, “whaddya bet an update’s been applied to Flo6?” And indeed, upon inspection of the Update History, out-of-band (OOB) KB5086673 pops up at the head of the Quality Updates list.

Why Say: OOB KB5086672 Pops Up?

Flo6 is set up for maximum stability. Thus, it doesn’t sleep. So, for it to prompt me for system entry, I was pretty sure the PC had rebooted. So I asked Copilot to write me a PowerShell check. And sure enough, the results of running said script (see lead-in graphic) show two quick reboots back-to-back just after 1:30 this morning.

The boot type for both shows up as “0x0” which indicates a cold boot that otherwise proceeded and concluded normally. And indeed certain updates — including this one, as shown — do require a pair of reboots to successfully complete their efforts. Copilot says “That 95-second gap is textbook CU finalization timing” and “the reboot…was Windows completing the update you saw in Update History.” Good stuff!

How the Pop-Up Happened

I’ve got the toggle for “Get the latest updates as soon as they’re available” turned on. I’ve also got active hours set from 7AM to 6PM. So when the update triggered last night nothing stopped it from getting downloaded, applied, and rebooting on its own schedule. That’s how the pop-up happened, and why I saw a login prompt when I sat down in front of Flo6 this morning.

Here in Windows-World, things work the way they’re supposed to quite often behind the scenes and (mostly) unnoticed. The login prompt drew my notice, and I’m happy to say “nothing more to see here.” Let’s get back to work, shall we?

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

CU Aftermath: One TPM Update Elicits WTF?

1 Comment

Microsoft’s February 2026 cumulative update, KB5077181, brought most Windows 11 25H2 systems up to build 26200.7840. At least, that’s what I was expecting. But as I rolled out the update across a mix of systems here at Chez Tittel, I noticed something odd. My Lenovo ThinkPads and an ASUS Zenbook A14 quietly updated and rebooted into 26200.7840. The DIY desktop (built on an ASRock motherboard with a Ryzen 5800X) threw a TPM warning and required multiple reboots after a forced cold startup. You guessed it: that one TPM elicits WTF as I must respond to “Update Y/N” for things to proceed.

One TPM Update Elicits WTF, Others Don’t

Let’s unpack what happened. First, the update itself. KB5077181 is a standard cumulative update, but it also includes boot-chain changes that affect Secure Boot and TPM values. On systems with stable firmware and well-behaved TPM implementations, these changes get absorbed quietly. That’s what happened on my Lenovo and ASUS laptops. They rebooted twice and landed on build 26200.7840 without a peep. Copilot tells me that the first reboot is for a servicing stack update, the second for the aforementioned CU.

The ASRock-based Ryzen system, aka “Flo6,” had a different reaction. Upon reboot it froze on a black screen. After I cycled power and forced a cold boot, it presented a UEFI-level prompt. That prompt  warned about changes to the TPM and Secure Boot configuration, and asked me to enter “Y” to confirm, or “N” to deny. This signals that the Platform Configuration Register 7 (PCR 7) that tracks Secure Boot components has detected a change. The system requires manual confirmation to proceed and reseal the TPM, followed with an additional reboot. But man, is that a cryptic message or what? (It appears as the lead-in graphic above.)

Why this discrepancy? It comes down to platform differences. OEM systems like Lenovo and ASUS laptops benefit from tightly integrated firmware, drivers, and update pipelines. Their UEFI implementations are mature. Also, their TPM and Secure Boot configurations get validated against Microsoft’s updates. Thus, they handle PCR changes gracefully and typically reseal the TPM silently with no user intervention.

The ASRock Difference

ASRock, on the other hand, does things differently. Though their firmware is functional and generally reliable, but it’s not as polished or tightly integrated as enterprise-grade or premium OEM systems. ASRock tends to use more standard, out-of-the-box AMI firmware. It offers only minimal validation for Secure Boot and TPM changes. Combine that with AMD’s fTP (known to be more sensitive to boot-chain changes than Intel’s PTT), and you get a prompt for TPM confirmation after updates like KB5077181.

You Get What You Pay For

That’s not to say ASRock is bad. For enthusiasts and DIY builders, their boards offer decent value and performance. But when it comes to firmware maturity and seamless integration with Windows security features, they’re noticeably behind the big OEMs.

The takeaway? Platform matters. As Windows continues to evolve its security posture, particularly around Secure Boot, TPM, and boot checks, users should expect some variation in how different systems respond to updates. OEM systems generally offer a smoother ride. DIY builds like my ASRock-based Flo6, appear to need more attention and manual intervention.

For those who live in the trenches of Windows-World, it’s just another reminder of how things sometimes work, or not. The best antidote is to know your hardware, expect the unexpected, and keep recovery media handy, just in case something goes awry. I’m glad I didn’t need recovery for this update. Indeed, I started wondering when I had to cycle power for a cold start, and an extra reboot to get to the desktop.

Facebooklinkedin
Facebooklinkedin