Category Archives: Updates

Windows Store Auto-Update Policy Change

Once upon a time — and until pretty recently — Windows users could defer Windows Store updates indefinitely. No more. Starting with version 22309.1401.x which began rolling out in early September 2025, users can only pause updates for a period of 1 to 5 weeks. By the end of that month, this change had reached most Windows users. Why this Windows Store Auto-Update Policy change? Good question! Answers follow, but first check out the lead-in graphic. It shows the Pause updates control in Store Settings, and the permissible intervals (though the 5 week option is obscured, it’s there, I promise).

Why Make a Windows Store Auto-Update Policy Change?

According to Copilot MS instituted this change for 3 primary reasons (my paraphrasis follows):

  • To lower security risks outdated apps can pose.
  • To synch up Store update behavior with the WU pause model that’s long been in effect.
  • To keep users from skipping critical app patches or updates.

Note: enterprise-managed Windows devices (e.g via GPOs or Intune) aren’t affected by this change. Their app update policies work differently, and they continue to exercise full control.

There’s even an MS Support Note to cover this change. It’s entitled Keep apps and games up to date with the Microsoft Store (last updated 9/4/2025). For more details and administrivia, check it out.

Here in Windows World you can duck updates for a while, but you can’t avoid them completely — at least, not without using third-party tools like those mentioned in this WindowsClub roundup story. But that’s a topic for another post, should I find the “round tuit” necessary to bring it up!

Facebooklinkedin
Facebooklinkedin

Version Dev Gets No 25H2

On the last day of September, the Windows Experience blog announced “the availability of the Windows 11 2025 Update (aka Windows 11, version 25H2).” A little careful perusal of this info, and some checking from your humble author shows that availability not only includes production versions. It also includes Insider Preview versions in the Release Preview and Beta Channels as well. By extension that means Dev and Canary Channel fall outside this umbrella. That’s what I mean when I say “Version Dev Gets No 25H2,” as you can see in the lead in-graphic (shows an ambiguous “Version Dev” instead).

Version Dev Gets No 25H2 Means More Than It Says

On my Canary test PC (the stalwart, still kicking 2020 vintage Lenovo ThinkPad X12 Hybrid Tablet) the version line from winver.exe gives things away. It reads “Version Dev” instead of 24H2 or 25H2. Both Dev and Canary Channels fall outside the Windows 11 versions that can upgrade to 25H2 at present. That’s because they belong to a different Windows 11 Build branch, with higher build numbers that bypass 25H2 entirely. That’s probably why MS forgoes 24H2/25H2 nomenclature in identifying the version as shown in the lead-in screencap.

OTOH, I was able to use the Installation Assistant yesterday to upgrade my Beta Channel test PC to 25H2. It shows the latest build status in Settings > Windows Update > Windows Insider Program, as you can see here

But it also shows up as 25H2 in Winver, and up-to-date in WU, as you can see here:It’s all a matter of how close the bits come to matching the currrent production version of Windows 11. Because Canary and Dev Channels are further out, they’re not able to show a 25H2 base. That’s by design.

Interesting that Beta and Insider Preview Channels can move on up to 25H2 though, while Canary and Dev remain in the 24H2 zone. This will be interesting to watch in the months to come. I wonder if Canary will get its own version, or stay lumped in with Dev? We’ll see!

Facebooklinkedin
Facebooklinkedin

Database Mixup Prompts Bogus Update

There’s always something interesting going on with WinGet, the MS package manager for installing and updating Windows stuff. Yesterday, a database mixup prompts bogus update orders for Visual Studio 2022. Let’s look at what happened, so I can explain the nit-picky little details involved.

But first: there really is no update involved. In fact, the Visual Studio version numbers are identical: 17.14.6, as you can see in the lead-in graphic. Note that the same version number appears in the columns for both “Version” and “Available.”

Fixing Database Mixup Prompts Bogus Update

The devil for these particular details lies in the difference between the two strings. The info from the “Version” column comes from the local copy of the WinGet source. It includes the parenthetical phrase after the version number — “(June 2025).” The “Available” version info does not include that string. Thus, there’s a mismatch, even though they’re the same base version number.

Simply put, because the version numbers don’t match, WinGet blithely assumes they’re different. Technically, they are. But they differ because somebody erred in creating one version string or the other.

Who’s on the Hook for a Fix?

Why Microsoft, of course, because Visual Studio is their product. Thus, they’re responsible for the package data in the WinGet database. As you can see in the following screenshot, in fact, that fix is already in. It depicts this morning’s WinGet show  and WinGet list data for Microsoft.VisualStudio.2022.Enterprise. Note that the version number info now agrees completely. Fixed!

The previous discrepancy is gone. [Click image to view full-sized.]

For further proof, I ran WinGet upgrade –all –include-unknown. It shows that CrystalDiskMark and Edge need updates, but Visual Studio no longer appears. The mismatch is corrected, so it’s no longer incorrectly flagged for update.

I’m a huge fan of WinGet, not least because the team at MS that works on its software and data is on top of things. Good stuff!

Facebooklinkedin
Facebooklinkedin

Interesting UniGetUI Update Shenanigans

I have to laugh. I read yesterday on NeoWin that UniGetUI — Marti Climent’s excellent UI skin for WinGet, Scoop, Chocolatey and other package managers — had gotten a big update. So naturally, I wanted to try it out. Instead, I got tangled up in some  interesting UniGetUI update shenanigans. They were almost entirely of my own making, but worth explaining. Here goes…

Revealing Interesting UniGetUI Update Shenanigans

I’ve actually had UniGetUI installed on my PC since the days when it was named WinGetUI. And indeed, I’d gone through several beta versions of UniGetUI. Amusingly, some launched from the old name (WinGetUI) but showed up with the new one (UniGetUI).

Somewhere in that skein of releases, the package names or IDs got tangled up. When I ran the new version of UniGetUI, it showed me an older beta version needed updating. Thus, I used the newest UniGetUI to uninstall that same older beta. Imagine my surprise when the PC came back with no version(s) of either WinGetUI or UniGetUI installed. Somehow, the beta uninstaller ended up doing away with everything WinGet or UniGet UI related on that PC and I was left with nothing.

Sometimes, Nothing Is Good

Neither Settings > Apps > Installed apps, nor Revo Uninstaller showed me anything related to WinGetUI or UniGetUI on my PC. So at least, I had a clean slate left behind. That made my job easy: I went to the Latest Release (v3.2.0) on the UniGetUI GitHub page, downloaded UniGetUIInstaller.exe and had at it.

Everything is now working, and the newest version — as you can see from the About info in the lead-in graphic — is working. It even managed to update TeamViewer for me, despite the older WinGetUI failing at that task before I started this adventure.

Sure enough, it’s always something, here in Windows-World. I’m just glad when a fix or workaround presents itself to me with little effort. This was one of those rare and happy times … I’m grateful.

 

Facebooklinkedin
Facebooklinkedin

Extirpating WinGetUI Requires Registry Cleanup

Here’s an odd one. A few months back, I tried out a pre-release version of UniGetUI that still fell under the WinGetUI umbrella. The package info involved — as you can see in the lead-in graphic — was ID=MartiCliment.UniGetUI.Pre-Release Version=1.5.2. I thought I’d deleted same, and it showed up in none of Programs and Features, Settings > Apps, or Revo Uninstaller. Yet it kept showing up in WinGet‘s upgrade and list commands anyway. TLDR; extirpating WinGetUI requires registry cleanup to “make it go away.” Sigh.

Why Extirpating WinGetUI Requires Registry Cleanup

Apparently, adding packages to Windows leaves all kinds of traces in the file structure, as well as settings and pointers that get instantiated in the registry. Furthermore, it looks like WinGet relies what it finds in the registry to create its view of what’s installed on a Windows PC. Thus, I had to remove all registry entries that included the string “WinGetUI” and/or “UniGetUI” (except for stuff not related to the application or its package info, such as pointers to Word files I’d written about those tools).

And indeed, that did the trick. Neither WinGet Upgrade nor WinGet List Marti.Climent.UniGetUI,Pre-Release posits pointers to something I know isn’t there. The next screengrab provides visual proof. Good-oh!

After removing all WinGetUI references in the registry, WinGet no longer sees the older package.

It just goes to show that some uninstall facilities work better than others. For all its good features, it appears that WinGetUI/UniGetUI does not clean the registry upon uninstall deeply enough to tell WinGet that it’s gone, gone, gone. You’d think that wouldn’t happen with a WinGet-related and -focused follow-on tool. But here’s a counter-example that says otherwise.

That’s the way things go here in Windows-World, where not all is as it seems, not always works exactly the way it should. Sigh. When that happens, we clean up manually and keep on truckin’…

Facebooklinkedin
Facebooklinkedin

Installing Build 27802 Throws Memory Error

Here’s a new one on me. Last Friday, as I was installing the latest Canary Channel upgrade, the installer threw an error code that I’d not seen before. That code is 0x8007000e; its output from the Microsoft Error Lookup Tool (err_6.4.5.exe) appears as the lead-in graphic above. That error occurred during the GUI portion of the install. And it occurs to me that while installing Build 27802 throws memory error, it might have been because I was running WinGet in parallel, installing other stuff at the same time. I’m guessing was a self-inflicted thing…let me explain.

Self-Inflicted: Installing Build 27802 Throws Memory Error

The recommendation that comes with this error, is to restart the PC and try again. As soon as I did that — without added activity on the side — the upgrade installed successfully with no further errors along the way. As I look back on what got updated during my first botched attempt, I see that some fairly intense items were involved. Most notably, it included Visual Studio, for which a typical install is usually around 50GB in size. I can see where trying to juggle both on a 2021 vintage laptop (Lenovo ThinkPad X12 Detachable Tablet with 16GB RAM) might cause resource issues.

Anyway, the proof’s in the observation that a second attempt worked. That’s probably because I didn’t try to multi-task while the GUI install was underway. The only reason I haven’t done this to myself before is that you can’t do anything to the PC except let the installer run, during the post-GUI phase!

27802 Takes a While to Complete, Too

I couldn’t help but notice — because I perforce went through the process twice on the X12 — that the upgrade process to this latest build takes some time to complete. Normally, a Canary Channel upgrade finishes in under half an hour. This time around, the whole process — including download, GUI install, and post-GUI install — took about 75 minutes to complete from desktop to desktop.

At least I now know I should leave my PCs (mostly) alone while the GUI phase of a Windows upgrade is underway. I wonder what my next creative abuse of the runtime and installer will teach me? There’s always something new and interesting to learn, here in Windows -World!

 

Facebooklinkedin
Facebooklinkedin

PatchMyPC Updates 9 Apps Today

Gosh: I don’t see this very often. On the Lenovo ThinkStation P3 Ultra just now, PatchMyPC Updates 9 apps today. You can see them in the lead-in graphic. The whole thing took less than 4 minutes to complete. My appreciation for this handy update tool knows no bounds!

OK PatchMyPC Updates 9 Apps Today: Next?

The full name of the tool is Patch My PC Home Updater. (I’ll call it PMPC for brevity here). With 516 apps in its library, PMPC is not as comprehensive in coverage as is WinGet or the MS Store (2,600+ packages in the former, and over 60,000 in the latter). But it’s completely automated, incredibly easy (and fun) to use, and — for some odd reason — almost always faster than running the same installers in PowerShell or the Command Prompt.

Indeed, PMPC is also less careful or respectful of running apps than WinGet. It cheerfully stops web browsers (and other apps) to update them, then restores their previous runtime context. In WinGet, you will often either be unable to update a running browser (e.g. Chrome) or you’ll have to relaunch it manually (e.g. Edge or Firefox).

It’s a handy tool, and comes in a variety of commercial forms that work with Autopilot and InTune, among other patch and update management systems. As with WinGet, you can also use it to install and uninstall the items in its library as well. Highly recommended, and a treat to use.

Facebooklinkedin
Facebooklinkedin

Recent Upgrade Traffic Heavy

It’s been a busy past few days here at Chez Tittel. Yesterday’s Patch Tuesday was pretty intense — MS and third-party updates addressed 67 CVEs — for all my Windows 10 and 11 PCs and VMs. And today, I’m noticing anywhere from 6 to 9 updates via WinGet on those same PCs and VMs. IMO, this makes recent upgrade traffic heavy (or at least, heavier than usual). You can see the list of 9 updates from the Lenovo ThinkPad X1 Extreme in the lead-in graphic, for example.

Is Recent Upgrade Traffic Heavy Important?

Hard to say. The number of CVEs addressed on Patch Tuesday may sound high, but Copilot says it’s way below the 350-400 monthly average over the past 12 months. Wait?! Can that be right… Yes, it can. Indeed, the monthly average for CVEs reported for Windows in 2024 was over 3,300. With the number addressed in fixes, you can see how far Windows trails behind in catching up.

Where WinGet is concerned, 7-9 on any given day is higher than usual, but not extraordinary. Here again, Copilot says “it’s safe to say that WinGet handles hundreds of updates daily across various systems.” On any particular systems, or on Chez Tittel systems (they’re similarly configured and run a fairly consistent set of tools and apps), that number varies by what’s there and what’s updated.

The Tools Keep Working, and So Do I

I’ve experienced relatively little difficulty with WU and WinGet updates in past months (see my February 6 post on upgrading Canary to 27788 as  rare exception). Keeping up with Windows and its apps and applications involves regular — but not extreme — effort. I’ll keep on keepin’ on as long as that stays true.

In that same vein, I haven’t seen much action recently through the lens of Patch My PC Home Updater. My typical suite of 20 to under 40 of its apps have been mostly quiescent for the past week and longer. That said, my production desktop just reported two C++ redistributables and CPU-Z all need updates. Go figure!

Facebooklinkedin
Facebooklinkedin

WinGet Boosts Chrome Update Capability

Here’s an interesting item. Previously, WinGet wouldn’t update Chrome on Windows PCs where it was running. Now it will, because WinGet boosts Chrome update capability. It now runs the installer with admin privileges to overcome the maxim “don’t mess with running processes.” You can see it working in the lead-in graphic, where the text reads (in yellow):

The installer will request to run as administrator, expect a prompt.

If WinGet Boosts Chrome Update Capability, Users Benefit

This means users must still Relaunch Chrome to get the update to take, though WinGet applies the update. Previously, WinGet would just skip the whole thing. Now, the next time users open that browser, the new update will take over (or, they can manually use the Relaunch button themselves).

After WinGet does its thing, Relaunch remains required to leave running processes undisturbed.

Will Other Browser Makers Follow Suit?

Here’s a shout out to the dev teams for Edge, Mozilla/Firefox (and variations), Opera, and others. Take heed of this Chrome action and do likewise. Your users — including your truly, most fervently — will thank you.

It’s just another small step for WinGet. But it translates into a big boost for the Windows user base. Keep up the good work, people!

New PowerShell Version Out, Too…

While I’ve got your eye, a new PowerShell version — v7.5.0 — is out. It’s still new enough that WinGet won’t install it yet. If you, like me, are OCD enough to want to run it before it gets into the pipeline, download it from the assets on the Release v7.5.0 page.

Note added 15 minutes later: Nevermind, it’s already showing up in WinGet. I should’ve known @Denelon and the team wouldn’t sit on their hands here. Another attaboy for that group and the PowerShell team. Good-oh.

Here, you can see the old 7.4.6 windows left, and a new 7.5.0 window right. God: I *LOVE* Windows Terminal.

Facebooklinkedin
Facebooklinkedin

Unexpected BIOS UEFI Update Adventures

When Lenovo Vantage popped up a notification yesterday that the ThinkStation P3 Ultra needed a BIOS/UEFI update, I thought nothing of it. But as the process dragged on … and on …. and on some more, I started to get a little concerned. Indeed, I found myself enmeshed in unexpected BIOS UEFI update adventures as what I thought might take 10-15 minutes took about an hour, all told.

But there is a happy ending. Though it took much longer than it ever has before, the update complete successfully. And the machine continues humming along, happily doing what I ask it to. That’s a relief!

Describing Unexpected BIOS UEFI Update Adventures

This may be the third such update I’ve gone through with this machine. Across all my many Lenovos over the years, loaners and review units included, I’ve probably performed over 200 such updates. That’s a big reason why this particular one took me somewhat by suprise.

Here’s a list of symptoms:
1. After the BIOS update completed, the PC rebooted yet one more time. It usually comes back up in no more than 30 seconds. This time, it took between 1 and 2 minutes.
2. Upon restarting the machine showed a black screen — no Lenovo logo for the boot splash screen showed up for at least another 30 seconds. Normally, this pops right up.
3. After the Logo showed up center screen, it took longer than usual for the “Energy Star” and “TCO certified” logos to show up bottom right. Again, this added another 30 seconds or so to the delay.
4. During that first reboot cycle, the PC rebooted itself again (never seen this before). This time the screen stayed black even though the monitor power indicator stayed on. I had to cold start the PC (turn off the power, wait 30 seconds, turn the power back on) to resume start-up.
5. After this second unexpected restart, the P3 took well over a minute to get to the splash screen. Getting to the spinning circle took longer than usual as well, but it booted into Windows 11. It’s now showing 24H2 Build 26100.3894 (current).

Post-update, the P3 takes about 10 seconds from the Lenovo boot splash to show TCO and Energy Star logos. Another 10 seconds to get to the spinning circle. Another 15 seconds before the lock/login screen appears. Thus, total boot time is now around 35 seconds or so. That’s not too bad, actually.

Why the Kerfluffle?

Copilot tells me extended boot delays after UEFI update can arise from compatibility issues, switching all settings to their defaults, “re-learning” of hardware  (I’ve seen this with memory on the P16 but that posts an on-screen message and nothing like that showed up on the P3), and “additional error checking or diagnostics during boot.” I’m guessing this update included a bigger change delta than older ones, and that some of the final category (diagnostics and error checks) also got thrown in.

As for the cold start, Copilot says it happens when the system needs to “properly recognize all components” after a UEFI update. I can see that, particularly if related aspects in the UEFI have changed since the preceding version. That would absolutely force a complete, new device enumeration, which may have been needed in this case.

At any rate, it turned into more of an adventure than I expected. And I learned a few things along the way. Glad the machine is running now, and appears to be working well. Fun, fun, fun here in Windows-World these days!

Facebooklinkedin
Facebooklinkedin