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.”



