Category Archives: Updates

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

Timing WinGet’s Update Pipeline

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:

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

Firefox Update Fixes Weird Cursor Ripple

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!

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

Pondering UEFI Updates

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?

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

Intel Graphics DSA Update Weirdness

Leave a comment

It’s strange. I just got a notification on the Lenovo ThinkPad X12 Hybrid tablet that Intel DSA had 3 updates pending: Bluetooth, Graphics and Wi-Fi. Of the three, BT and Wi-Fi went swimmingly. The graphics update, however, hung in unexpected ways. That’s how I found myself fixing Intel Graphics DSA update weirdness minutes ago. The trick is fortuitous, as I’ll explain…

Overcoming Intel Graphics DSA Update Weirdness

I have kind of a built-in timer when it comes to waiting for Windows installs to finish up. If an installer shows a progress bar, and I see no progress at all for 5 minutes, I start getting antsy. At 10 minutes, I pull the plug and kill the installer to see what happens.

Killing an installer may take varying degrees of effort. The Intel Graphics installer was well-enough behaved to respond to the “close window” controls at its upper right corner. In other, more stubborn cases, I’ve been known to resort to Task Manager, where I’ll find and kill the installer process itself. Sigh.

Imagine my surprise when the DSA installer reported success in installing the new Graphics driver. Seems that their current installer had finished, but simply neglected to update the UI to report said progress.

As Luck Would Have It…

My impatience spurred me into doing exactly the right thing. I’ve had other Windows installers hang, where killing the installer meant I had to start over and install again. In some more extreme cases, I first had to clean up the leftovers from the hung installer before a new install would work. That’s where a tool like Revo Uninstaller (in “Hunter Mode”) can be helpful: if you can find a UI trace left behind –such as the DSA notification tray icon — you can use it to help you clean up.

All I can say is “Thank goodness no cleanup was needed.” Here in Windows-World, when things get messy, they can really suck up some serious time. I ran into that last Monday, when WinGet in my primary MSA got profoundly bollixed. Go figure!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Troubleshooting, Updates, WED Blog

Manual Store Update Clears Ongoing Errors

Leave a comment

Here’s an interesting one. I just took a look at Reliability Monitor on one of my Canary channel test PCs (the venerable ThinkPad X12 Hybrid Tablet). As you can see in the lead-in graphic, it shows 14 days’ worth of “Warnings.” All of them mention Windows Terminal and YourPhone with a “Failed Windows Update” summary. But a manual Store update clears ongoing errors, and everything is hunky-dory now. Let me explain…

Why Manual Store Update Clears Ongoing Errors

I’m in the habit of leaving Windows Terminal open on many of my PCs. That’s because I run WinGet and other CLI utilities on them on a near-daily basis. But although this strategy is convenient, it sometimes means that Store updates won’t complete successfully because they don’t want to affect a running and related process.

Running a manual store update (Click Upates & downloads in the left column, then click the “Check for updates” button at upper right) forces the Store to interrupt things and start with a clean slate (Copilot calls this a “clean install path”). That means it restarts the Store install service, flushes any stale metadata, closes the running Terminal processes, pulls dependencies in the necessary order and forces a high-priority update job.

Thus, what’s stuck inside the automated daily update tasks that Store handles in the background is stuck no longer. The update goes through and the program shows itself running the latest version — namely, 1.23.13503.0 — without issues. And indeed, the same thing applies to Microsoft.YourPhone (showing the same error over the same period — it runs in the background automatically).

Not All Automatic Updates Always Succeed

This heading is the “moral of the story.” It emphasizes that occasional manual intervention may be needed, especially for processes that run in the background by themselves. But hey — that’s the way things go here in Windows-World sometimes. Happy New Year!

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

Notepad++ Update Stalls WinGet

Leave a comment

Ha! I just learned something new. Because Notepad++ uses a Win32 installer, when WinGet tries to update the app, it will hang if Notepad++ is open. That’s how a Notepad++ update stalls WinGet. Fortunately, I was able to get over that hump pretty easily. Let me explain…

Why Say: Notepad++ Update Stalls WinGet?

WinGet stayed on the first update until I realized the program was open. Then I closed it, and about 30 seconds later, progress resumed. According to Copilot, Notepad++ uses a “classic Win32 installer” that’s downloaded and run silently. That installer tries to replace files in C:\Porgram Files\Notepad++, including notepad++.exe. If the file is running, Windows won’t let the installer overwrite that file.

So it waits a while (30, 60 and 90 seconds, according to Copilot) and retries after each interval expires. When the third try fails, the installer reports failure and closes. I was able to close the app before the second try, and then that attempt succeeded, which is how it took a while to complete the update process.

Moral of the story: when certain apps pop up in response to WinGet ugprade it’s a good idea to make sure they’re closed. Indeed, if such updates fail, they’ll most likely succeed if you close them before a retry. And man, isn’t that just the way things work here in Windows-World? Some of the time, at least…

Another Stall, Another Reason…

I ran WinGet again on another PC and once again it hung. But Notepad++ wasn’t open on that PC. So I went digging into the log file named WinGet-2025-12-29-11-42-19.224.log. There, I found a long sequence of the following two information lines (I skipped the timestamp info for brevity:

[REPO] Attempting to open pinning database: C:\Users\ed\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db
[CLI ] Terminating context: 0x8a15002b at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:be

This started at 11:42:22.609 and ended at 11:42:22.929 (0.320 seconds) and repeated every .002 seconds (160 times). It seems that, for some reason, WinGet couldn’t access its pinning database during that time period. Thus, WinGet stalls until that condition is addressed. Another stall, but another reason, too. Cheers.

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

Settings vs Store App Updates

Leave a comment

Recent Beta and Dev Insider Preview builds have brought a new entry to Settings > Apps (e.g. 26220.7271). As you can see in the lead-in graphic it’s labeled “App Updates.” Quite naturally, this led me to wonder how differs from “Updates & Downloads” in the MS Store app itself. Comparing and contrasting Settings vs Store App Updates turns out to be more nuanced than I’d hoped. Indeed, the lead-in graphic also shows Settings reports all apps up-to-date at the same time as the Store is downloading an update to itself.

Digging into Settings vs. Store App Updates

Last May, MS Product Manager Angie Chen posted a blog on this topic. Entitled Introducing a unified future for app updates on Windows, it lays out new alternatives coming to  purely Store-based updates. But it wasn’t until I could see and try out the Settings alternative to the Store-based baseline that I could see some differences.

Indeed as Sergey Tkachenko puts it at WinAero: “…you can manage updates for certain Store apps that can receive new versions via Windows Update” (bold emphasis mine). As you can see in the intro screencap, the Store will happily update itself, while Apps> Update Apps apparently will not.

The Key: “Other” Update Channels Rule

The intro language in the May 27 blog post linked above states:

If you are already getting apps through the Microsoft Store (our recommended approach), there is no action needed—you will get the benefits described here by continuing to use that method.

Among other things, this means that store-managed apps — including the Store itself — continue to update through the Store Updates & Download faciliity, not through Settings > Apps > Update Apps. That showed itself immediately as soon as I went to check things out. Indeed careful reading of that blog post shows that developers must explicitly build apps to hook into Windows Update (ditto for management tools such as Intune or Autopilot) to make use of this capability.

In fact, nobody really knows how much this will change the way things work right now. As with other possible futures in Windows-World, those who build apps will have to take up this new update path before mere users — like your humble author — can walk down it. Right now, it seems limited to MS tools that don’t fall under the Store umbrella (e.g. PowerShell and Windows Terminal). So far, it looks more like a future possibility than a real, current alternative.

I’ll keep an eye on this, and let you know what happens…Stay tuned!

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

Beta 25H2 Jump Brings Unexpected Side Effect

Leave a comment

When I saw the news, I had to try it. A couple of weeks back, MS announced that 24H2 users for all versions of Windows 11 except the Dev and Canary Channel could move up to 25H2. So I used the Installation Assistant, and did that very thing for my X380 Yoga install. But, as I’m learning, that Beta 25H2 jump brings unexpected side effect. Namely, as MS drops new Beta Builds (e.g. 26120.6982), my jumped-up Yoga doesn’t partake of such updates. It’s on a higher track.

Why Beta 25H2 Jump Brings Unexpected Side Effect

The base build number for 24H2 Beta versions remains 26120. For Beta installs jumped to 25H2, that base build number advances to 26200, as you can see in the lead-in graphic. Thus, for my Beta Channel test PC the unexpected side effect of the jump-up is to exclude it from updates and new versions that target 24H2 instead. I should have known, but found out when I saw last week’s announcement of Build 26120.6982, visited WU, and didn’t get anything in response to clicking the “Check for updates” button.

Only slowly did it dawn on me that my install is on a different track right now. I’m not exactly sure when I’ll see the next update for this track. I’m guessing I may have put myself on the Patch Tuesday schedule with this change, along with occasional OOB updates and 4th Tuesday items as they sometimes appear.

Here in Windows-World, it can be easy to change tracks, or even to get onto the wrong track. I know I’ve done the former, and time will tell me if I’ve also done the latter. In the meantime, I’ll just keep chugging along.

One More Thing [Added 6 hrs later]

I just ran DISM /online /analyzecomponentstore on this updated PC and guess what? the 25H2 eKB restored the spurious reclaimables that I’d hand-deleted from the 24H2 image. (See this March 21 post for details.) It worked this time, too, just as recited in that earlier post (and again, thanks to ElevenForum user @Bree for figuring this out in the first place).

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

Windows Store Auto-Update Policy Change

2 Comments

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

Version Dev Gets No 25H2

Leave a comment

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