Category Archives: PowerShell

Avoiding Windows Self-Update Traps

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!


Update Trick Delivers Clean PS 7.3.7 Install

OK, then, Here’s an interesting way to handle the September 19 update for PowerShell, from 7.3.6 to 7.3.7. Indeed this specific update trick delivers clean PS 7.3.7 install. I’ve run into minor glitches on previous up-versions, because I was using PowerShell to update itself. It would show cancelled as its final update status, as the old runtime had to fall over to get itself out of the way for the new one.

You can see this at work in the lead-in graphic. It shows the Installer running to update PowerShell as a pop-up within the PS windows itself. In fact, it runs to completion without issues. Why? Because I closed the open default PS session and ran the PS update inside an Administrative Command Prompt session instead.

Which Update Trick Delivers Clean PS 7.3.7 Install?

Because PS essentially interferes with itself if it runs the upgrade from one version to the next, the trick is NOT to use PowerShell. That’s why I switched to Command Prompt instead, and ran the upgrade there. No strange behavior, no “Cancelled” status at the end, nothing weird at all, in fact. You can see a new PS session window at right here with the new 7.3.7 version clearly identified (the left-hand side shows the complete PS upgrade in Command Prompt):

Update Trick Delivers Clean PS 7.3.7 Install.split-window

Once the update is finished I used the Command Palette to open a PS session split-right, which shows the new version running.

I’ll have to remember this for future PS updates. I’ve just used this technique on a half-dozen test PCs and it works like a charm!



Interesting PatchMyPC Download Affects Winget

Here’s an interesting gotcha. On September 5, I wrote about uptake and intake of a new Lenovo loaner/review PC. It’s a nifty new Intel Gen13 P1 Mobile Workstation. I described using PatchMyPC to install a bunch of follow-on applications, including CrystalDiskMark. Yesterday, I figured out that an “interesting” PatchMyPC download affects winget updates thereafter. The lead-in graphic provides an important clue. Can you see it?

How an “Interesting” PatchMyPC Download Affects Winget

The output line from winget tells the story. It finds a CrystalDiskMark version (I’ll abbreviate this as CDM going forward for convenience) that differs from the one in its database. Note the line that shows version 8.0.4c installed, but 8.0.4 available. This is what causes the “unexpected error” report later in the lead-in screenshot.

As best I can interpret what’s going on is this: 8.0.4c is treated as a different version from 8.0.4. Winget doesn’t know what to do with this odd duck named 8.0.4c when it wants to install (and see) 8.0.4. Its MO is to avoid changing stuff that doesn’t match its search criteria, so the download request fails along with the update. Sigh.

Where Does PatchMyPC Come Into Play?

You’ll recall I mentioned using PatchMyPC to install a bunch of applications on the P1 Workstation in the opening paragraphs. So I fired up that program and sure enough it shows the installed (and current) version of CDM on the target PC as — you guessed it — 8.0.4c. Here’s a screencap:

Interesting PatchMyPC Download Affects Winget.pmp-versions

Note the version number for CDM (line 6 in sage green text in right column): 8.0.4c. Eureka!

So here’s how I “fixed” this non-issue. As you might expect, winget won’t uninstall this odd duck CDM version any more than it will upgrade it. So first, I used Revo Uninstall to remove the existing CDM installation.Then I ran the winget command to install CDM — namely winget install CrystalDewWorld.CystalDiskMark as shown in the following screencap. A subsequent winget upgrade command shows it no longer balks at the odd duck (and now absent) 8.0.4c version number (I had to clear an Edge update in the meantime, so the bottom line that starts “No installed package” is the one that proves CDM is no longer throwing an update notification).

Ultimately, I’m guessing this issue originates with the developer failing to provide a new winget manifest for version 8.0.4c to the winget database. That’s the explanation that best fits these observations, IMHO. And FWIW, the download also took forever to complete (more than 3 minutes for a mere 3.87 MB package). Go figure!

When winget upgrade reports “No installed package…” it means no updates are needed, including CDM. Fixed!

Of course, I had to back off the real most current version to clear this error. But that means it wasn’t really an error, doesn’t it? That’s one of the many ways I keep myself entertained, here in Windows-World!


Extra C++ Redistributable Must Go

Here’s an interesting winget puzzle. Over the past couple of days, I noticed winget was reporting success in upgrading a Visual C++ Redistributable from version 14.36.32532 to 14.38.31919.0. Yet, each time I ran winget after that the same thing would reappear. Good thing I know what’s up with that: it means the new install doesn’t remove the old, now obsolete version. Thus, that extra C++ Redistributable must go.

Accomplishing Extra C++ Redistributable Must Go

In the lead-in graphic I show the two versions side by side inside Revo (bottom of image). I used that same tool to uninstall the other one manually. If you look at the sequence of commands therein, you’ll see I check upgrades. It shows me a new Visual C++ version to install. I install it, and check again: oops! Same old version of the redistributable still needs an update.

Or does it? Actually, it needs to be uninstalled. I could’ve done it with the winget syntax:

winget uninstall Microsoft.VCRedist.2015+.x86 -v 14.36.32532.0

But instead because I had Revo already open I simply right clicked the old version, chose uninstall, and let it do its thing. Gone!

What Happened Next?

As expected, the next time I ran winget upgrade to see if any updates remained pending I got back this mysterious but welcome message. “No installed package found matching input criteria.” In winget-speak, that means it didn’t find anything that needed an update. In other words: removing the obsolete Visual C++ Redistributable took care of my previously persistent version 14.36.32532.0.

Good-oh! Glad I’ve seen this kind of thing before. It told me that I probably had to kill the old version manually, to keep it from provoking a reminder to upgrade to the new. Even though it was present already…


Using Get-WUHistory Requires Finesse

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


PowerToys Sources: WinGet & MSStore

I saw yesterday on Twitter (X?) that PowerToys version  v.0.72.0 dropped. So I started banging on WinGet to upgrade me. It’s been at least 20 hours since that announcement, but WinGet still has no manifest for the new version. Indeed, the lead-in graphic shows v.0.71.0 as current. But there are two PowerToys Sources: WinGet & MSStore. And sure enough, installing the Store version brought one of my Lenovo X380 ThinkPads up to the latest iteration. This features in the lead-in graphic as well. The second WinGet list PowerToys command shows the current version installed — with a WinGet source, no less — after I downloaded and installed the latest version from the MS Store. Go figure!

Why Two PowerToys Sources: WinGet & MSStore?

The answer to the preceding query depends on how organizations do updates internally. Those who let WU and the MS Store handle things should choose the Microsoft Store version of MS apps when they can. This will automatically handle things on its own. But those who control updates will find WinGet invaluable. It makes a great focus for automation via PowerShell scripts as and when their update windows open.

Does that mean one or the other source for updates is better? Not at all. But today, it looks like the updates through the MS Store track new releases faster than WinGet does — for PowerToys, at least. I’m also interested that even though my update comes from the store, it shows WinGet as its source. But as long as it’s updated quickly and correctly, that’s OK.


Dissecting Winget Logs Shows Root Causes

Hmmmm. I just did something risky, or perhaps dumb on my production PC. You can see the evidence in the lead-in graphic, a PowerShell session that shows an issue (in red, at bottom) with the installer hash for a Google Chrome update. What you can’t see is that I was already updating Chrome inside Chrome itself while this was happening. The installer changes when a new version is installed. Fortunately, dissecting Winget logs shows root causes, so that’s what I did next. It was more illuminating than the error message, for sure…

How Dissecting Winget Logs Shows Root Causes

First, some background on Winget logs. You can find out more about them (and related troubleshooting stuff) in the MS Learn article “Debugging and troubleshooting issues with the winget tool.” It also gives you a huge honkin path where the log files reside — namely:


But, rather than grab and use this, I simply told Voidtools Everything to show me all instances of the final directory name DiagOutputDir. That got me there a whole lot faster!

Once into the logfile named WinGet-2023-07-21-10-59-05.148.log I jumped to the bottom to see how it mentioned Chrome. Here’s the tail end of that log from 11:00:09 to 11:00:14.

2023-07-21 11:00:09.043 [CLI ] Generated temp download path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.043 [CORE] Downloading to path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.044 [CORE] DeliveryOptimization downloading from url:
2023-07-21 11:00:13.663 [CORE] Download completed.
2023-07-21 11:00:14.593 [CORE] Started applying motw to C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26 with zone: 3
2023-07-21 11:00:14.602 [CORE] Finished applying motw
2023-07-21 11:00:14.603 [CLI ] Package hash verification failed. SHA256 in manifest [2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26] does not match download [aae26a4cf7d92a4c9198d8fac9534670e9fb5f8d1e38897d99b0b51e68107d2a]
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a150011 at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\DownloadFlow.cpp:15e
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a15002c at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:28a

I bolded the line where things went south. Basically, the hash verification failed because I had already overwritten the old version of the installer with the new version (and the new Chrome version itself, as well). Good thing winget is smart enough to recognize the ground has shifted under its feet. If it finds things it doesn’t expect, it wisely decides to quit what it’s doing. Now I know what I had always suspected. And now, of course, you know too. Cheers!


WinGet Upgrade PowerShell Working

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.

WinGet Upgrade PowerShell Working.X390

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!


PowerToys Team Closes WinGet Gap

Now THAT’s what I like to see. Yesterday morning, I noticed a new version of PowerToys (v0.71.0) was out. So quite naturally, I ran WinGet to upgrade same. No dice. At 11:45 AM (Central) I tweeted  about this. I observed it was “kind of surprising to see a new PowerToys release…without a matching WinGet upgrade manifest.”  8 minutes later, the team leader responded “we’re working on it.” And by that afternoon, the PowerToys team closes WinGet gap. There’s a working manifest for version 71 in place. Neat-o, and thanks, people!

PowerToys Team Closes WinGet Gap Quickly

It’s a real testment to the energy and drive of the teams involved that things were already in progress as I reported in. (In fact, I heard from the WinGet team lead, too.) This morning I installed PowerToys on the Lenovo ThinkPad X1 Extreme (8th-gen i9, 32 GB RAM, 1.5 TB SSD) and got the latest version. That sequence appears as the lead-in graphic above.

If you look at that graphic, you’ll see that WinGet found only a Zoom upgrade. Oops! That’s because PowerToys wasn’t installed on this PC — yet. But when I did install the .exe version (Microsoft. Powertoys) 0.71.0 (shown as v0.71.0 in the thumbnail at lower right) appears. That’s exactly what should have happened,. It also shows the WinGet manifest for that version of PowerToys is present and working properly.

Always Nice When Things Work Out…

I must say that both the WinGet and PowerToys teams have always been great to work with. They respond to input, questions, and feedback quickly. And when they have to act, they tend to do so sooner than later. Thus, my thanks to Demetrius Nelon (WinGet team lead) and his merry munchkins, as well as Clint Rutkas (PowerToys team lead) and his peppy people, too.  Please: keep up the good work.



Sussing Out WinTerm Color Schemes

In my writing and research work for TekkiGurus, I’m pursuing a GitHub project that works within the Windows Terminal environment. It’s called ColorTool. Simply put, ColorTool shows the colors used in the console window; it also lets you tweak them. Its color charts are kind of interesting and I’ve trying to figure them out. MS has a tendency to show them inside an Ubuntu command session inside Windows Terminal. I show them as they pop up in PowerShell in the lead-in graphic. As I’m learning how this all works, I’m sussing out WinTerm color schemes, too.

Bing Chatbot Helps When Sussing Out WinTerm Color Schemes

I’ve been reading a lot, and asking around to try to learn how to decode the values that show up in the display form of a Windows Terminal color scheme. So far, it’s proved rather more challenging than I had expected. So far, I’ve been attacking output strings to tease out their meanings. This is what I’ve learned so far, mostly thanks to the Bing Chatbot in Windows 11 Canary (Build 25393):

  • The string “gYw” that appears in the columns of rows 2-10) stands for gray, yellow and white. It uses prevailing foreground color, whatever that may be.
  • The values 30m through 37m that appear as row heads (first column left) are ANSI escape codes for foreground colors
  • The values 40m through 47m that appear as column heads (second column through 9th column left) are ANSI escape codes for background colors.
  • Looking at the color chart, the text strings “gYw” show the foreground color, while the solid bar for each column shows the background color.

In profound contrast, Ubuntu puts foreground colors as columns, and background colors as rows. I also shows escape sequences instead of color names. Initially, this bamboozled me. But now I see what’s going on…

Sussing Out WinTerm Color Schemes.ubuntu

Notice that background appears as double rows with escape codes at left in column 1, and foreground colors appear as the text for escape codes in rows 2-9).

Wow, it’s all starting to make a certain amount of sense. And I mostly have the Bing Chatbot to thank for explaining such extremely low-level details. Apparently, those who work with terminal/console color charts know all this stuff already.

Now, I finally understand that a color scheme assigns a range of color values to the 8 ANSI escape codes for the foreground colors 30m through 37m (which may also be expressed as ESC[30m …). It does the same for the 8 ANSI escape codes for the background colors, too (40m through 47m, likewise ESC[30m).

OK, Now I Know What’s What

Suddenly, I feel armed with the information I need to make sense of the Windows Terminal color schemes and their related color charts. This should make my jobs of explaining them, and their customization, a WHOLE LOT easier. I’m jazzed…