Category Archives: Updates

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

Insider Preview Build Expiration

August 5, 2026 Ed Tittel 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.

WinGet List/Install Orders Seldom Match

July 10, 2026 Ed Tittel 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!

Cool Tools, Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet Upgrade Knows More Than It Says

June 27, 2026 Ed Tittel Leave a comment

In running through my usual morning Winget Upgrade drill, I noticed that it found 3 upgrades, but applied only 2. As you can see in the lead-in screencap, it concluded its efforts with a line that reads “1 package(s) have upgrades blocked because newer versions use a different install technology…” To me, this means that WinGet Upgrade knows more than it says, because process of elimination reveals that Microsoft Edge is the missing item.

Why Say: WinGet Upgrade Knows More Than It Says

Microsoft Edge is deeply embedded into the Windows 11 OS. Indeed, Windows 11 uses WebView 2 as a system component. That also powers the Settings app, widgets, Copilot, Teams, Outlook (new), the MS Store, and more. That’s why Edge usually updates more easily from within its own UI anyway.

In this particular case, something about the install technology changed moving from Version 149.0.4022.96 to Version 149.0.4022.98. That forces WinGet to keep its mitts off, unless users uninstall the old and then install the new in two separate operations.

I elected to jump into the app, do the upgrade, then returned to Windows Terminal to run WinGet Upgrade –all –include-unknown again. As you can see in the lead-in graphic (if you right-click that image to display it in its own browser tab), with Edge manually updated already beforehand, the next check returns “No installed package found matching input criteria.” In WinGet parlance that means “no items need updating here.”

In Windows-World, what you see can sometimes tell you more than what your app or tool output tells you. This is a definite illustration, and explains why I assert that the Windows package manager (i.e. WinGet) and its upgrade facility knows more than it says. Cheers!

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

Patch Tuesday Delivers Odd Recycle Bin Glitch

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

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

WinGet Copilot CLI Update Gets Interesting

June 18, 2026 Ed Tittel Leave a comment

By design, the WinGet package manager is pretty conservative about working on apps that are running. With Copilot now active on my desktop most of the time, and even accessible in Windows Terminal (or rather, Intelligent Terminal) this goes double. Yesterday, in fact, my attempt at a WinGet Copilot CLI upgrade gets interesting when it fails with an “access denied” error message. Let’s figure this out, and apply a dead-easy fix.

What to Do When WinGet Copilot CLI Update Gets Interesting

You can see the first Winget failure, the fix, and a successful upgrade in series in the lead-in screencap. That fix provides a way to get Copilot out of the way so WinGet can do its thing without the possibility of messing anything up. Figure that Copilot is nearly always on my systems these days into your consideration and the runtime context.

That fix is:

Stop-Process -Name Copilot -Force -ErrorAction SilentlyContinue

Now, let me explain what’s going on, and this fix does the trick.

Why the First WinGet Upgrade Failed

The root cause is straightforward Windows behavior. The operating system won’t let any process overwrite a running executable. If you had an active terminal session that loaded the Copilot CLI — or any background shell or process that previously invoked it — the old copilot.exe is locked. The installer cannot swap in the new binary, so it fails, and reports explanatory error info.

This is not a WinGet bug. But WinGet could arguably handle it more gracefully. It could detect running processes before the upgrade begins and warn the user. Instead, it downloads everything, then fails at the last step. That may be disconcerting, or perhaps even frustrating, but it’s easily fixed.

The Fix: Kill All Copilot Processes, Then Retry

The fix is a two-step sequence. First, kill any running Copilot processes. Then retry the WinGet upgrade. In PowerShell, do that by running these two commands in sequence:

Stop-Process -Name copilot -Force -ErrorAction SilentlyContinue
winget upgrade GitHub.Copilot

[Note the first two lines are actually a one-liner with a spillover resulting from local formatting; run as a single command.] That’s what the screenshot at the top of this post illustrates. The first command runs cleanly even if no matching process exists. The
-ErrorAction SilentlyContinue flag does that by design and intent.

The second winget upgrade command then finds the package again, verifies the hash, extracts the archive, and this time completes successfully. You will see two confirmations appear: “Overwriting existing file” for the WinGet Links path, and “Command line alias added: ‘copilot’.” Then, finally: “Successfully installed.”

Noteworthy Postscript

A couple of additional observations from this experience deserve mention. First, note that Copilot CLI lists Microsoft.PowerShell (version 7.0.0 or later) as a required dependency. If you have not yet upgraded to PowerShell 7.x, WinGet may attempt to pull that in first. In this case, PowerShell 7.6.2.0 was already current, so that dependency check passed instantly.

Second, if you run WinGet from within VS Code’s integrated terminal, Windows Terminal, or any shell that has previously invoked gh copilot, (gh = GitHub, and is the target for copilot requests in a shell environment) you may hit this exact error. Opening a completely fresh PowerShell window before running the upgrade is often enough to sidestep the issue entirely. In that case, no Stop-Process is needed.

Third, this pattern is not unique to Copilot CLI. Any WinGet-managed package that ships as a standalone executable can run into this same locked-file problem during upgrades. Ditto for Web browsers (e.g. Chrome, Edge, Firefox, etc.) which many users, including your humble correspondent, tend to leave running all the time. For browsers the update may fail, it may not run at all, or you may need to “Relaunch” the browser so the updater applies that change file.

A Predictable Bump in the Road

WinGet is a solid package manager. It delivers smooth, hands-off upgrades nearly all the time. When it stumbles — as it did here — its error messages are descriptive enough for a quick diagnosis and fix.

One command to kill the offending process, a second WinGet command to retry, and you’re done. It is a minor contortion, but now you know that two-step. Here in Windows World, it’s good to keep tools current. To that end, don’t let a transient file lock slow you down. Fixed!

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

GNUBG Shows WinGet Pin Rationale

June 3, 2026 Ed Tittel Leave a comment

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

How GNUBG Shows WinGet Pin Rationale

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

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

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

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

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

Resuming Work After Week-long Absence

May 13, 2026 Ed Tittel 2 Comments

OK, then. We dropped onto the runway about 20 minutes early last evening. Wife Dina and I returned from a trip to Boston, to watch son Gregory trot across the stage at Emerson College’s Wang Theater to pick up his diploma and graduate. It was quite a trip in many ways. This morning, I’m back at my desk, resuming work after week-long absence. So far, it’s mostly two things: catch-up and clean-up. Let me explain…

What’s Involved: Resuming Work After Week-long Absence

Here’s the drill:
1. run winget upgrade –all — include-unknown to catch all pending updates that winget can handle (7 items)
2. run PatchMyPC Home Updater to catch other stuff that WinGet doesn’t (Revo Uninstaller, in this particular case)
3. run PC Manager deep cleanup (3.2GB found/1.1 GB cleaned) and unCleaner (2.5 GB found, 2.1 GB cleaned)
4. Because today is Patch Tuesday for May 2026, I also applied all pending monthly updates (2 for Defender, 1 for .NET Framework, and the usual monthly MSRT).

All that stuff is pretty easy and straightforward. I did have to reboot, though, because updates via WinGet and PatchMyPC didn’t proceed properly. Something apparently gummed up my runtime. Fixed with the tried-and-true strategy of “Try a reboot, if Windows is balky.” Add a second restart after the Patch Tuesday updates completed, just for grins.

Now, the Real Work Begins…

Next I have to plow through about a thousand email messages that piled up while were off having fun and making family history. That will probably take me the rest of the day. Then I can start updating the rest of the fleet. Wish me luck!

To cap things off, here’s a photo of Gregory proudly presenting his diploma amidst absolute chaos on Boston Common (across the street from Emerson College) after the ceremony ended. Cheers to him, and all of us!

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

Timing WinGet’s Update Pipeline

April 29, 2026 Ed Tittel Leave a comment

OK then, I just read at WinAero that a new PowerToys v0.99.0 is out. Checking via WinGet upgrade in PowerShell it’s not yet in the pipeline. Nevertheless, the app itself is happy to grab said update from its GitHub repository, as you can see in the lead-in graphic. I’m now conducting an experiment. I’ll be checking hourly as I work at my desk, to see when that new PowerToys version comes into WinGet’s ken. Should be interesting…

What’s Involved in Timing WinGet’s Update Pipeline?

Behind the scenes, lots of things must happen before WinGet catches up, and offers the PowerToys update:
1. MS publishes the new release on GitHub (that’s done)
2. A Pull Request (PR) is sent to winget-pkgs with info about the new version, URLs, hash values, and so forth (usually automated)
3. Pull Request validation runs: automated checks verify installer hashes, check URL resolution, and validate manifest schema
4. Pull request merges into the WinGet source: a maintainer approves the package and merges it into the public database
5. WinGet CDN propagates: the updated database index appears via the winget source in related commands (show, install, uninstall, etc.)

How Long Does It Take?

Because PowerToys comes from Microsoft, its timeline is about as short as such things get. Turnaround normally takes no less than 12 hours, nor more than 48 depending on timing. If a weekend gets in the way the delay can stretch out. Ditto if issues with the manifest show themselves, or if the software being packaged shows a bug. Thus, for example, PowerToys v.0.99 has a Command Palette crash bug, and may be slowed to accommodate suitable hotfix.

We’ll see how this one goes. There’s already a new V0.99.1 version on GitHub (which includes that very hotfix). It’s in the WinGet pipeline now: let’s see how long it takes to get through, shall we?

Note Added 1:05 Later…It’s HERE!

The original post went up at 1:05PM local time. It’s now 2:10PM and a check on the P16 Gen 1 Mobile Workstation produces the following WinGet output: It’s here…

Notice that version 0.99.1 is on offer. That means the PowerToys team got its hotfixes into the package before sending it off to WinGet. Good job, @ClintRutkas and team. I am impressed.

And, now that I’m running it on the suitably-configured X380 Yoga, I see that the PowerToys upgrade also flashes an icon. Impressed again:

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

Pondering UEFI Updates

April 15, 2026 Ed Tittel Leave a comment

I’m still getting settled in with my new production desktop environment. ICYDK, it’s built around an MSI MAG Tomahawk B550 mobo, with Ryzen 5800X, NVIDIA 3070Ti GPU, and 64GB DDR4 RAM. This morning, I started digging into the MSI Center app that orchestrates other system utilities, and handles updates for drivers and firmware. In my investigation, I discovered a “new” update for the mobo firmware. In turn, that has me pondering UEFI updates.

Where Does Pondering UEFI Updates Take Me?

I had to figure out that MSI’s once-standalone “Live Update” utility now sits beneath its top-level Support tab (top middle of option bar in the lead-in graphic). Then I had to figure out that UEFI updates appear only when one clicks the “Advanced” button, rather than the more pedestrian “Scan” button (which scans only for driver updates).

As you can see in that graphic, the company shares its guidance in eye-catching red text at the head of the MB BIOS list. That guidance reads: “MSI does not recommend to update BIOS when system has no issue” in somewhat fractured English. However rough the wording might be, the guidance is still pretty good. Let me explain…

If It Ain’t Broke, Don’t Fix It!

The reason why I recently rebuilt my Flo6 desktop stemmed from UEFI problems with the previous ASRock B550 Extreme4 mobo. It kept sticking halfway between Secure Boot old/updated data sets. That resulted in extreme boot requirements, when I might sometimes have to reset CMOS just to get the PC to boot.

Most of the time I had to shut it down, and cut power, then wait a while to bring it back to life. That went on for weeks before I made the switch to the MSI board. Since then, boot and update operations have been blissfully boring. Things just work, and I can use all of the various boot options and related keyboard options to do exactly what I want.

Reading over Copilot’s summary of what UEFI v2.A0 brings me, as compared to the running v2.90, I don’t see anything I need. Nor do I see anything that would improve Flo6’s currently rock-solid and dependable, fully caught-up Secure Boot Status.

Hence my decision: I’m not going to update. Nothing is causing problems. Everything is working dependably and reliably. Secure Boot is golden. This time, I’ll pass… Maybe next time?