Here’s an interesting observation. Winget will happily upgrade PowerShell from one version to the next, but things can sometimes get a little weird at the end of that process in a PowerShell window. As you can see in the lead-in graphic, a WinGet upgrade PowerShell shows cancelled at the end of that process. I opened a second PowerShell tab, then formatted it to appear beneath the open command session above. Notice the version number in the top reads 7.3.4 and below 7.3.5. That means the upgrade process completed successfully and PowerShell is running the higher-numbered version.

Interestingly, this doesn’t happen on all Windows 10 or 11 PCs. As I upgraded my local fleet from the old version to the new, this situation popped up on about half the machines involved. WinGet team lead Demetrius Nelon (@DenelonMs) explained things to me this way:

Yes, we have the same behavior when we use winget to upgrade winget via `winget install “App Installer” -s msstore –force`. We actually special case that scenario in the latest preview to show completion even though the process is killed which is what is happening in the upgrade PowerShell scenario.

What WinGet Upgrade PowerShell Shows Cancelled Means

Once PowerShell is updated the process where the upgrade happens appears unable or unsure what to do with itself. It’s apparently still running the old version in the top pane. But when a new pane opens below it shows the new version of PowerShell is running. IMO, that makes the “Cancelled” output an artifact of the bootstrapping process rather than a genuine error message. Indeed that’s a function of the “CTRL-C” like behavior of what happens as Mr. Nelon explained further:

Essentially the running process is “killed” [ctrl]+[c] equivalent. When the process is killed an exception is thrown. A child process would continue to run, however, so it actually completes successfully

And indeed, if you close the open Windows Terminal instance and open another one, it comes up with only 7.3.5 visible and available. I don’t know if others find this kind of thing interesting and entertaining. But gosh, I sure do. These little details are what makes working with the Windows OS and its supporting cast of tools — Windows Terminal and PowerShell, in this particular case — so interesting and beguiling.

Learn More About Windows Terminal

I’m about halfway through a series of articles on Windows Terminal for TekkiGurus.com right now. Here’s what’s done so far:

Overview: Understand Winget: MIcrosoft’s Windows Pkg Manager
Part 1: Dealing with Windows Upgrade Issues
Part 2: Working with Winget Settings

Still to come, among other items, is a story on WingetUI, a GUI-based alternative to the native command-line Winget tool. Be sure to check them out!

Here’s a question whose best practices answer may save admins time and effort. While indeed many developers now push regular updates for their software, not all are equally urgent. Why? Because whereas some updates add valuable new functionality or plug serious security gaps, others may not introduce much of note. That’s why, IMO, tracking minor updates poses diminishing returns against the time and effort required to find, download, and install them.

A case in point appears in the lead-in graphic. Antibody’s WizTree is a tree graph oriented disk space layout visualization and management tool. You’ll notice that winget doesn’t track release numbers past the first sub version level (e.g. 4.14 is what its “show” sub-command displays, and what its “list” sub-command finds on the target PC).

Why Say: Tracking Minor Updates Poses Diminishing Returns?

Simply put, if winget doesn’t track it and package labels don’t include it, not even the developer thinks it’s noteworthy. I’ve had other development teams confirm this approach to me. Thus, for example, when I contacted IObit to ask about minor revisions to their Driver Booster tool (example version number 10.4.0.127) they’ve told me that they don’t advise users to update unless something new or security-related is changed in a new version. If so, their policy is to increment version numbers more significantly, and to use the tool’s auto-update function to recommend and flog the update process forward.

Long story short: if the developer doesn’t recommend installing every minor update that comes along, I can’t do otherwise. For one thing: life’s too short to keep up with absolutely everything. For another, working toward scheduled update windows for most corporate software means choosing only “worthwhile updates” for inclusion. This reduces the amount of change — and its attendant risk — during such windows, and keeps the time and effort required to survive them as manageable as possible.

The old saw: “If it ain’t broke, don’t fix it” somehow seems apt. Don’t let OCD tendencies to keep up with all change put you in a bind. Relax, and watch the blinking lights instead…