Here’s an interesting observation about winget upgrade. I’ve slowly but surely gleaned it from repeat experience over the past 19 or 20 months. As I’ve been using the tool daily, I’ve noticed that for some apps or applications, winget upgrade sometimes works, and sometimes fails. It has finally dawned on me this on-again, off-again behavior depends on if the app or application is running at the time. Thus, if winget upgrade hits or misses ties to whether or not it can run the upgrade without stepping on something that’s running.

When Winget Upgrade Hits or MIsses, It’s for a Reason

This hit me forcibly on Monday when I noticed that an upgrade attempt for Microsoft.Office failed on on PC, but not another. The only difference between the two situations was that Word and Outlook were running on one machine (failed). On the other machine no Office components whatsoever were running (succeeded).

As I think back on other situations where this has happened, it’s often been web browsers involved. At one time or another, Chrome, Edge and Firefox (the three browsers I typically use) have all either failed or simply refused a winget upgrade command. And indeed, all were either actively running or had running processes showing in Task Manager when this occurred.

Another Kind of Update Trap?

I wrote recently (September 28) about Windows Self-Update Traps. These can pop up when winget, PowerShell or Windows Terminal get updates. Winget is conservative and won’t change things that could cause problems or lead to uncertain outcomes. Thus, I’m coming around a specific idea: if you use winget and you notice an update for a running application, save work and close it for best results. Gosh, where have I seen that advice before? It’s received wisdom when applying updates anyway. Perhaps that’s why?