Here’s one to ponder. Just this morning, in going through a gaggle of WinGet updates, I noticed something interesting. WinGet will happily install browser updates on Windows PCs, whether or not the target browser is running. But if that target is not running, it will invariably succeed and leave the program ready to run it’s newest, best self the next time it’s called. When run against running browsers, though, WinGet will often be unable to finish the job completely, despite reporting installation success. Hence, this epigram: WinGet Updates Quiescent Browsers Best.

What WinGet Updates Quiescent Browsers Best Means

Over the past 3 years or so, I’ve gotten pretty darn familiar with WinGet, Windows’ built-in package manager. It’s bundled into Windows 11 and easily available through GitHub (microsoft/winget-cli). I use this tool pretty much every day to check for updates on my fleet of 10-12 Windows PCs here at Chez Tittel. And as I use it, I get the chance to observe and report all kinds of issues and oddities, both large and small.

This is a pretty small one, as it turn out, but worth noting even so. What happens if you don’t exit a browser before using WinGet to upgrade same? It varies. Chrome will sometimes stick stubbornly to its pre-upgrade state, and require an in-app update to catch up. Firefox may require you to “Relaunch” the browser to finish things up completely. Edge does a good job of self-updating but also works well with WinGet (as you’d expect, as they’re both MS software).

Is This Just “Same-old, Same-old”?

Yesterday, I wrote a post entitled When WinGet Balks, Try In-App Updates. In a small way, this post is a further musing on some of the same themes. But because I leave browsers open on the desktop all the time — as do many other users — this one is a more focused and directed play on the same general topic.

And isn’t that just the way things sometimes (or even often) go, here in Windows-World? At least for me, anyway…