Why Restart Guarantees WinGet Upgrade

OK, then. Yesterday I blogged about seeing no upgrade to WinGet until after a PC restart. It turns out that is indeed one way — but not the only way — to ensure that WinGet will upgrade itself from one version to the next. In this case it was moving from Version 1.25.340.0 to 1.25.390.0.  Why did I restart? Because I closed, then re-opened Windows Terminal several (3) times with no intervening change in WinGet versions. Thanks to feedback from WinGet team lead Demitrius Nelon and Senior Software Engineer John McPherson, I now know why restart guarantees WinGet upgrade. I also know why a restart may not be needed, and about possibilities for upgrade hangups. Let me explain…

Here’s Why Restart Guarantees WinGet Upgrade

Thanks to an invitation from the development team, I’m a member of an MS Teams chat called “WinGet Community.” I posted info about my observations and a link to yesterday’s blog there, and got some useful and interesting information from the aforementioned folks that provide a pretty detailed explanation of what I experienced, and why it happened.

First, here’s how Demitrius responded to my report and inquiry:

Hey Ed (Guest), when WinGet is updating “packaged” applications (MSIX Installer), it’s using deferred registration. It may take a few moments for the registration to complete before WinGet is updated (App Installer package) when WinGet is the thing currently running updates . That means WinGet essentially needs to completely finish what it’s doing before the delayed registration happens. A reboot which requires a user to log in (and that triggers the “registration” part of the MSIX lifecycle) will ensure all MSIX packages are up to date. In some cases there may be a few second delay when winget upgrade –all was used to update WinGet itself.

I’ll talk with the team to see if there is a reasonable way to diagnose this a bit better, and if the performance is suffering, we might need to look into some other “special” handling for this specific scenario.

We were hoping to avoid any logic in WinGet like “if package == foo” then do something special.

In some cases, a user may be actively running an MSIX package GUI based application. WinGet could upgrade the package to a newer version, but it wouldn’t be applied until the currently running instance was restarted.

That’s why the message is “Restart the application to complete the upgrade.”. We just don’t know if the application is running or not. In the case of App Installer / WinGet, a user could be in the middle of installing a sideloaded application which also could have it “tied up” from having the latest version registered for the user.

Restart application should not mean “reboot”. Some applications specify a reboot is required, and that’s when WinGet would display “reboot required”.

So essentially, what Demitrius is saying is that WinGet waits until all other pending package updates finish before allowing its own registration to change and its own update to complete. I was probably not waiting long enough for all the pending items to complete. That said, he also explains cases where such completions might not happen until (or rather, after) a restart occurred.

And Then, There’s a COMplication possible…

John McPherson observes further that:

Note that all packaged processes must terminate for the next process launch to then register the new version.  So any outstanding COM objects keeping the server alive will block that.  This could be due to PowerShell cmdlets and the GC not running due to no memory pressure.  Or it could be other services on the machine using COM.

So it appears there could be stuff running in the background that might stymie WinGet’s own auto-upgrade. Thus, it sounds like a restart is a reasonable workaround if and when WinGet attempts to upgrade itself, reports success, but the version number doesn’t increase. Waiting isn’t an unreasonable thing to do, but if the wait gets too long, a restart will force the WinGet upgrade to go through.

Thanks, guys, for the great information and explanations. It’s good to know what’s going on behind the scenes when WinGet handles multiple updates in a single go. In yesterday’s case, 5 items were upgraded, including WinGet itself, but also OhMyPosh, Teams, WinScript, and more. Of that batch, I’m pretty sure WinScript has interesting COM connections. Thus, I can speculate that the old three-fingered-salute (a restart, in this usage) resolved a stuck situation. As the old saw goes: “There’s no school like the old school.”

Facebooklinkedin
Facebooklinkedin

Snipping Tool Text Extractor Rollout

Windows certainly has its weird and wonderful ways. I was forcibly reminded just now, when looking on a Canary test PC to see if the next Text Extractor tool was on my Snipping Tool toolbar. While you can see it in the lead-in graphic for this story, I couldn’t see it on my PC right away. At first, understanding that MS is conducting a new Snipping Tool Text Extractor rollout, I thought I might be on the outside, looking in. Not so: let me explain…

Working Thru Snipping Tool Text Extractor Rollout

When I first checked the app and saw the toolbar unchanged, I jumped to the assumption that my PC wasn’t in the first rollout cohort. Then I remembered: Snipping Tool is a Windows Store app. So I went to the store and clicked on the Downloads button. Nothing had been updated since 4/14 (two days ago), so I clicked the “Check for updates” button.

Guess what? There was indeed a new version of Snipping Tool ready for download. Once that step was complete, and a quick install later I saw what MS announced in its April 15 blurb. Yes, Virginia: there is now a text item in the Snipping Tool toolbar. Again you can see it in the second from right position in the intro image. MS even provides an intro blurb to tell you what this toolbar element does.

I checked it, and it works as advertised. Makes the steps involved in grabbing text from an image and dropping it into a file ever so much easier and faster. Thanks, MS for giving us something many of us can use and enjoy (your humble author included). Visit the MS Store on Canary and Dev Windows 11 PCs and you, too, can partake of this neat new feature. Cheers!

Facebooklinkedin
Facebooklinkedin

Why Run NVIDIA Studio Driver?

The question in the blog post title — namely: “Why run NVIDIA Studio driver?” — means considering the alternative. That’s the Game Ready Driver, which gets updates 2 or more times every month. Look at what new Game Ready Drivers bring to the party. New games (and game versions) keep coming out, and GPU drivers need matching tweaks. Thus, the answer is “To play (new or updated) games.”

I just saw news that NVIDIA had released new cards (and drivers, presumably). Checking the NVIDIA app, I quickly saw no new Studio version available. But a new version of the NVIDIA app installed itself when I went to check. Indeed, its “About “banner headlines this blog post.

Why Run NVIDIA Studio Driver — Not?

If you don’t game, you don’t need to track the game-focused updates. Game Ready Driver users get new bells and whistles (NVIDIA calls them “optimizations and performance enhancements”) and a faster update cadence. Studio driver users get more stability and reliability, including more “extensive testing with professional software to ensure consistent performance.”

Interestingly enough, PCs can switch between the two drivers at will to exploit those trade-offs as they see fit. Because I don’t game (at least, not the kinds of games a GPU can impede or assist), I choose stability and reliability over optimizations and performance enhancements.

Indeed, I’ve been bitten when I’ve succumbed to the temptation to switch from Studio to Game Ready drivers upon various occasions. If you run this Google Search, you’ll see that I’ve blogged about NVIDIA stuff (drivers mostly, though occasionally about the app and its GeForce Experience predecessor) 9 times in the past year. That makes it a pretty regular thing for me to watch and report about.

Facebooklinkedin
Facebooklinkedin

Reinstall Now Builds Current Images

Last Wednesday, I blogged that a repair install for Windows 11 unsticks WU. As I think about what that really means, I want to emphasize that using Settings > System > Recovery > Reinstall now does something remarkable. That is, Reinstall Now builds current images for whatever version Windows Update is serving at the time. It used to be only UUPDump.net could do that, by slipstreaming all the latest updates into the base Windows image (24H2 in this case).

How To See That Reinstall Now Builds Current Images

If you look at the Settings > System > About info that appears in the lead-in graphic, it tells pretty much the whole story needed for evidence. You can see it shows version 24H2, Build 26100.3775 with an install data of 4/9/2025. That’s the very day I ran the repair install, and the build number matches what follows in the wake of the latest CU (KB 5055523 — see the parenthetical phrase at the end of that title).

What makes this facility remarkable is that UUPDump.net has to build a Windows image for the baseline release, then apply as many updates — the latest security, cumulative and servicing stack items — as it needs to bring the image current. This requires some time-consuming DISM manipulations that can take an hour to complete. Interestingly, the WU facility handled the entire repair in about 35 minutes.

I still recommend UUPDump.net as a way to create an ISO for some specific (and non-current) Windows Build. But if you need to repair a current version, it looks like built-in Windows 11 recovery really is your best choice. Good to know! That’s why I’m telling you…

Facebooklinkedin
Facebooklinkedin

Leave Post KB5055523 Inetpub Folder Alone

I’d seen reporting on this yesterday, along with blithe assumptions about related cleanup (deletion). Today, MS has published a CVE-2025-21204 security note that explains what’s going on, and specifically advises users to leave post KB5055523 Inetpub folder alone — and intact.

Here’s a direct quote from the afore-linked source:

After installing the updates listed in the Security Updates table for your operating system, a new %systemdrive%\inetpub folder will be created on your device. This folder should not be deleted regardless of whether Internet Information Services (IIS) is active on the target device. This behavior is part of changes that increase protection and does not require any action from IT admins and end users.

Note: KB5055523 is a security update for Build 26100.3775 (production level Windows 11 24H2) released as part of the Patch Tuesday collection on April 8, 2025.

Why Leave Post KB5055523 Inetpub Folder Alone?

It’s part of the infrastructure upon which MS relies to fend off the named vulnerability. In other words, if the folder is present, MS can use it to protect against potential attacks. MS is sometimes fond of leaving folders behind in the wake of various installs (especially feature upgrades). Anything not needed is usually fair game for Disk Cleanup or the Windows Store PC Manager app.

That said, some OCD-friendly Windows users (you know who you are) relentlessly clean up things just because they must. This is apparently a case that flies against that impetus. MS, in this particular case, says “Leave it alone.” I guess I shall, and you probably should, too.

Though the Inetpub folder is empty after the update runs (see next screencap) it is meant to be and stay there. You’ve been warned! Indeed, as you can see, it’s properties are also set to “Read-only.”

The ‘Read-only’ status signals weakly that this item should stay put.

Final Warning: Don’t!

I’ve seen various online sources assert that it’s OK to delete this folder because it caused no observable ill effects on their test PCs. If what MS says about Inetpub’s presence or absence on a PC is true, you don’t want to sight what could happen if it were to be deleted. Let this particular sleeping critter keep snoozing, please.

Facebooklinkedin
Facebooklinkedin

PowerToys ComPal Error Comes & Goes

I have to laugh, and with genuine joy. Last week, Clint Rutkas and the PowerToys team dropped a new Command Palette with v0.90.0 of that app. Shortly thereafter, I noticed an error window on the desktop of my only remaining Windows 10 PC after startup (see lead-in graphic). Upon visiting GitHub PowerToys bug reports, I saw multiple reports that others were seeing the same window. Just now, v0.90.1 hit the Internet, and the error appears no more. That’s why I’m saying: “PowerToys ComPal error comes & goes.” That’s good!

Why PowerToys ComPal Error Comes & Goes

I see this quick fix as abundant evidence that things are working as they should. Here’s a typical if somewhat idealized sequence of events:

1. A new release appears (v0.90.0 PowerToys in this case)
2. Users install and run same, and report issues and errors
3. A next release appears (v0.90.1 this time ’round) with at least some issues and errors fixed (“Class not registered” goes away)

I have to hand it to Mr.  Rutkas and the rest of the PowerToys team. They’re unusually responsive to input, feedback and issue reports. When I saw the new release was already in the pipeline, my first thought was “I bet the error message goes away.” And indeed it did.

GitHub showed me as many as a dozen different error reports around the error message shown at the head of this story. Apparently, lots of people run PowerToys on Windows 10, and lots of people noticed the error.

GitHub Tells the Story

If you check the v0.90.1 changelog, you’ll see this somewhat opaque entry: “#38531 – Fixed an issue where Command Palette was attempting to install dependencies that already existed.” That would be my best guess for what caused the error message to appear. Fixing that would obviously also do away with the error message.

Gosh, it’s nice when things work the way they’re supposed to. PowerToys is always a pleasure to use. It’s even better that the dev team is obviously listening (and sensitive) to user input and reactions. Again: keep up the good work, folks!

Facebooklinkedin
Facebooklinkedin

Repair Install Unsticks WU

For the past 5 weeks or so, I’ve been working with the Lenovo ThinkPad T14s Gen5 laptop. For the last two weeks, updates have been stuck, with an error code that indicates file download issues. The usual repair techniques haven’t helped, either — namely run the troubleshooter or the reset & re-register Windows Update components. So this morning, with a new cumulative update out, I installed the latest Windows 11 24H2 repair version. That built-in repair install unsticks WU and catches me up with pending stuff, as you can see in the lead-in graphic.

Repair Install Unsticks WU Trades Time vs. Convenience

The problems with the afore-mentioned techiques (troubleshooter, reset&re-register) is that they take multiple steps and a bit of effort. Double that when, as often happens, remediation is also needed. It took a while to click Start > System > Recovery > Reinstall now and then work through that process. But the details took care of themselves and I didn’t have to do anything except fire it off to make it work.

In the end, this turned out to be easier and less vexing than the other techniques. Its results were also immediately apparent, and entirely positive, once completed — as you can see in the lead-in graphic. That said, Update History does become a little opaque when you conduct this repair. Here’s what it says now:

It doesn’t show the problem CU installed and running. It simply shows that “Windows 11, 24H2 (repair version)” got installed today. Of course, that means the installer used the latest version of the Windows image — including those problem CUs — as the install base. So really, it’s all fixed now. You just have to know what this reference means.

And ain’t that just the way things go here in Windows-World? The problem may be solved, but a hint of mystery — or is it confusion? — remains. Cheers!

Note Added 4 Hrs Later: Get-Hotfix Tells the Story

Reading through ElevenForum.com threads just now, I learned that running Get-Hotfix in PowerShell will shows installed KBs from a repair install image, to wit: This shows that various updates and security updates are indeed present in the newly repaired image. The current build number for that PC — 26100.3775 — also shows that KB5055523 has been applied. Good stuff…

Facebooklinkedin
Facebooklinkedin

Download MS 50th Anniversary Wallpapers

Last week — April 4, to be precise — Microsoft celebrated its 50th anniversary. Amidst the hoopla and the celebration, the folks over at the Windows Experience Blog  released an item entitled Windows wallpapers worth celebrating. There, you’ll find a link for a ~24MB download named 50th-windows-wallpapers.zip. That’s right: you can download MS 50th anniversary wallpapers, if you like, and add them to your collection. You can see the contents of the ZIP folder as the lead-in graphic courtesy of File Explorer.

Download MS 50th Anniversary Wallpapers ZIP Archive

What you get is a collection of 8 different wallpapers, each in 4K and wide-screen formats depending on your display preferences. Some of these items are game-themed: Mahjong and Solitaire (e.g. Klondike) inspired ones. Some of them feature tulips (light and dark themed). Others give the same light/dark treatment to Windows icons and logos. It’s a fun set of items. If you want to put them into rotation with other such images, put them into your Slideshow folder and they’ll enter that lineup.

I have to laugh. When I went to show off these wallpapers, I got icons instead of images in File Explorer. Turns out one of my View settings in Folder Options had ticked “Always show icons, never thumbnails.” Unchecking that box let me capture the screenshot you see at the head of this blog post.

Here in Windows-World, it’s always something, right? Cheers! And congrats, I guess, to MS for surviving half a century in this rough and tumble world. Indeed, things have been a bit more rough lately than many of us would like, speaking both as an industry observer and a Microsoft stockholder. Sigh.

Facebooklinkedin
Facebooklinkedin

Dell Updates Replaces Power Plan

Yesterday afternoon, upon returning from a lovely drive into the Texas Hill country “the Boss” remarked that she now had to power on her Dell Optiplex D7080 to wake it from sleep. “Hmmm” I thought to myself “I bet something changed with sleep/wake/hibernate.” It sure did: a recent item via Dell Command Update installed and selected a “Dell” power plan. Alas, when Dell updates replaces power plan, their chosen alternative forced use of the power button to initiate wake. Easily, easily fixed: read on for those details, please…

When Dell Updates Replaces Power Plan, Switch Back

As you can see in the lead-in graphic, there’s a new power plan in the mix. It’s named Dell and it had been selected by default after some recent item ingested through the Dell Command Update utililty. To inspect the contents of a power plan in PowerShell, two commands are needed: the first provides a list of all plans, the second inquires about the contents of a specific plan through its GUID. Those commands are:

powercfg -list
powercfg -query <GUID>

Fortunately, the list output includes both human readable names and GUIDs so I was quickly able to get the deets for the Dell power plan. And sure enough, as I suspected, it had a setting for hibernate after 1 hour of idle time. That was the key!

Wake from Hibernate Requires a Poke

A poke of the power button, in fact, which was just what the boss didn’t like. So, as you can see from the lead-in graphic, I switched her back over the the High Performance plan she’d been using before Dell Command Update made that switch. It doesn’t include hibernate, and it wakes on keypress or mouse click from sleep. That’s what she wanted. And now, that’s what she’s got.

Facebooklinkedin
Facebooklinkedin

X380 Yoga Can’t See QMR Hotfix

I shoulda known. When MS unleashed it Quick Machine Recovery (QMR) capability earlier this week, it said it would  provide a test fix so IT admins could try out its automatic repair facility. I blogged about enablement instructions on Monday, and have been waiting for that fix since then. I just learned that MS is gradually rolling it out to Beta Channel Insiders running Build 26120.3671. But alas, my test PC is on the outside, looking in. Certain units should find the test fix under a new “Hotfix” category in Settings > Windows Update > Update History. To my chagrin, my test X380 Yoga can’t see QMR Hotfix (neither category nor test item), as (not) shown in the lead-in graphic.

X380 Yoga Can’t See QMR Hotfix: Wait for It!

Gradual rollouts are unpredictable as to when a feature might appear. But they are pretty reliable, in that it should appear sometime. One just has no idea when that might be. If you look at the lead-in graphic you’ll see that it lists out:

  • Feature Updates
  • Quality Updates
  • Driver Updates
  • Definition Updates
  • Other Updates

When the QMR-aimed Hotfix finally makes it to the X380, a new category named Hotfix will appear. Then, should I use the reagentc.exe /BootToRe instruction to reboot the PC and tell it to look for and apply same, that should show me by example what it looks like and how it works.

So far, nada!

Standing By for My Turn

As seems to happen to me more often than not, I’m going to have to exercise patience and make sure that I keep checking for the Hotfix category and its test item in the Update History on the X380. Don’t know when that might be, but I’ll report in when that happens. Stay tuned!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness