Think about it. When a program needs an update, sometimes what’s doing the update and what’s getting the update may be related. This gets interesting. Windows itself is a pretty good example. This explains why reboots are required to install  an OS, and often when updating same. Simply put, the pieces being working on cannot also do the work on themselves in many cases. Applications, apps, and so forth can also fall prey to the same things (think about installing an installer). Thus, avoiding Windows self-update traps is something of a balancing act.

Example: Avoiding Windows Self-Update Traps

I saw a great example of an artful dodge around this problem yesterday, as I was using Winget to update Windows Terminal (WT). Take a look at the lead-in graphic. It shows the WT update progress. Note that the last instruction at the end of that process reads:

Restart the application to complete the upgrade.

That’s exactly the kind of maneuver that’s necessary. It allows the currently running code for a program (or OS) stop running. Then, the newly-updated or installed code for the same program (or OS) can take over and start doing its thing.

Counter-Example: PowerShell

Back in June, I wrote a blog post here entitled WinGet Upgrade PowerShell Shows Cancelled. It shows what can — and sometimes still does — happen when the tail end of the installation process fails to complete and exit cleanly. I know the PS team is working on this, but this shows that self-updates do pose occasionally tricky problems.

I’m glad to see the WT take the high road and suspend the final steps of install or upgrade until it’s safe to do so. I’ll be gladder still when the PS team eventually follows suit (as I’m sure they will). In the meantime, I did find a workaround: if you open a Command Prompt session and run the winget PS upgrade there, no “cancelled” (or other error messages) result. Good enough for me, for now!

I’m a big fan of PowerShell. That’s why I was excited to learn about a collection of cmdlets from the PowerShell Gallery named PSWindowsUpdate. Chief among its constituents is a cmdlet named Get-WUHistory that I’ve been finding both helpful and vexing. I say that using Get-WUHistory requires finesse because it works well on Windows 10, but hangs on PCs with longer “history trails” in Windows 11. Let me explain and illustrate what that means…

Why Using Get-WUHistory Requires Finesse

I’m only running Windows 10 on one actual PC (not counting VMs). By chance, that’s where I started working with the PSWindowsUpdate cmdlets. To begin with, you’ll need to install this collection, using this command:

Install-Module -Name PSWindowsUpdate -Force

If you haven’t visited the PowerShell Gallery before, you’ll be asked to grant various permissions so your PC (or VM) can access and use its contents. If necessary, please do so. Then, your installation will complete. After it’s done, you can use the Get-WUHistory command (among others — see a complete list of all 25 cmdlets from this package).

There’s something going on in Windows 11 that will sometimes cause Get-WUHistory to “hang.” How can you tell? The output won’t complete, you won’t get a prompt back, and the cursor keeps blinking. Indeed, it doesn’t even respond to CTRL-C to terminate the command. You must close the open PowerShell window (or tab) to regain control over Windows Terminal.

What’s the Trick to Make Things Work?

For some odd reason limiting the scope of output keeps the Get-WUHistory cmdlet working. Thus, in Windows 11 instead of simply entering Get-WUHistory at the command line, try this version instead:

Get-WUHistory -last 1000

This tells the cmdlet to limit its output to only the first 1000 entries it finds in the update history. Notice that on one of my test PCs, the actual number of entries in the update history is only 157 items, yet the command hangs anyway — except when it’s scoped. Go figure!

Unless scoped [-last 1000] Get-WUHistory hangs on Windows 11.

The lead-in graphic shows the first screen of output from a scoped version of the Get-WUHistory cmdlet. Notice that most of the updates relate to Windows Security (Windows Defender intelligence updates, antimalware platform updates, and so forth). Too much chaff, not enough wheat, IMO. Here’s a way to turn down the volume…

Reducing Get-WUHistory Output Volume

One can, of course, filter Get-WUHistory Output — in addition to limiting its scope — to reduce the output volume. Here’s a command string I found to be incredibly helpful in seeing what’s there, sans security-related stuff:

Get-WUHistory -last 1000 |
Where-Object {$_.Title -notlike "*Security*"}

What you see broken across two lines (or more) in the preceding is actually a single (if complex) PowerShell command string. Be sure to remove or ignore any internal line breaks when running this inside Windows Terminal. You’ll get back a mercifully much shorter list of items, mostly cumulative updates (CUs), MSRTs, Update Stack Packages, and the odd antimalware platform update. As you can see, this cuts 157 items down to a more manageable 12. Good stuff!

Eliminating the word security in the “Title” field filters out most of the dross. [Click image for full-sized view.]

At the end of last month, I blogged about an interesting issue: when you used WinGet to upgrade PowerShell (in PowerShell) that operation would complete, but the screen wouldn’t update properly. As I reported, it showed cancelled and required opening a new PS session to see the current, upgraded version number. No more: now, MS has WinGet upgrade PowerShell working as it should be. See the lead-in graphic for visual proof.

If WinGet Upgrade PowerShell Working, Then What?

No more weirdness in the self-upgrade process, I guess. The lead-in graphic shows that PowerShell updated the initial session window to match the current version (7.3.6) with the version number at the top of the that window. Indeed, I’m forced to *SWEAR* it said 7.3.5 when I started, and appeal to the 2nd line of the WinGet upgrade output because I didn’t think to capture “before” and “after” screencaps. LOL, it didn’t occur to me that the developers would rewrite the terminal window to update the version number. But they did!

I contacted Demitrius Nelon, Team Lead for WinGet at MS to report this weirdness, which he confirmed for me. What he didn’t tell me was that they fixed this in the 7.3.6 release. But its behavior, as shown in the lead-in graphic, speaks for itself. Good stuff and thanks, people: good job.

Got It on Another PC!

I went to upgrade another PC and *DID* capture the initial screen showing 7.3.5 at the top. No more swearing: here’s the screen before the 7.3.6 upgrade completes so you can see the old version number in its top line.

See!? There’s the old version number before the 7.3.6 update completes. It’s like magic!

Note added 7/19: looks like this capability (no cancelled and updating version number) may only be in Windows 11. When I updated my sole remaining Windows 10 physical PC this morning, the cancelled message recurred as in my earlier blog post on this subject. Go figure!