Category Archives: PowerShell

PowerShell Install Method Changes

When a new version of PowerShell comes along, it’s always interesting to see whether or not winget can field that update correctly. This time around — with version 7.4.0 — it reports a “different install technology” as you can see in the lead-in graphic. When the PowerShell install method changes, winget won’t handle the update without an uninstall/reinstall maneuver. So I CTRL-clicked the link shown above the WT pane (from the GitHub link that’s helpfully provided) and used the MSI file to update PowerShell instead.

When PowerShell Install Method Changes, Use GitHub

That Microsoft Installer File is under 65MB in size. On my test PC, that takes less than 10 seconds to download. That opens the “SuperHero” PS installer (see next screencap), after which install takes half-a-dozen mouse-clicks to configure as I like it. Another minute or so, and the job is done. MS is doing better at getting new versions of PowerShell to circulate. I like it!

PowerShell Install Method Changes.installer

The only time you actually see the PS superhero avatar is when the installer runs.

Watching Out for Certain Winget Shenanigans

So, I’m learning to be wary of three specific installs when using winget inside Windows Terminal and PowerShell — namely:

  • winget itself: if the tool doing the updating gets updated, interesting things can — and do — sometimes happen. This is another case when I’ve sometimes seen the “Cancelled” error message that really reports a loss of interaction with the updater (the update actually succeeds, but can’t report success).
  • Windows Terminal: same principal as before, write large when the entire Windows Terminal runtime has to change. When this occurs, WT usually writes a message into the active terminal window to say “Restart the window/session to run the changed version.” Good -oh!
  • PowerShell: and again, if PowerShell is updating itself it must be ready to handle those changes. As we see in this particular case, something has changed that requires an uninstall/reinstall. My preference: using the GitHub installer instead. Easy-peasey.

And that, dear Readers, is how I often keep myself entertained, here in Windows-World. Great fun…


PowerShell Update Twofer Strikes

Whoa! No sooner had I updated PowerShell from version 7.3.9 to 7.3.10 than came the 7.4.0 in-window notification. You can see all this in the lead-in graphic, as a rare but not unheard-of PowerShell Update twofer strikes my local Windows 10 and 11 desktops.

When PowerShell Update Twofer Strikes, Keep Going

I had to chuckle after I patted myself on the back for updating PowerShell inside Command Prompt (the best way to avoid odd update behavior that can occur when PowerShell attempts to update itself). The very next thing I saw in a new PS window was the “black text against white background” notification shown in the lead-in graphic.

That notification reads:

A new PowerShell stable version is available: v7.4.0
Upgrade now, or check out the release page at

That URL links to the named release page at GitHub, where one can download an installer that matches OS, architecture and so forth. I ran the file named PowerShell-7.4.0-win-x64.msi. It worked like a charm!

And unlike other, earlier attempts at running the MSI installer to move up a PowerShell version, this one successfully cleaned out the just-updated 7.3.10 version without difficulties. Looks like the PowerShell team is getting its act together…

This does raise the question: when will winget update start targeting v7.4.0 instead of v7.3.10? Looks like that’s already taken care of. Look at this output from winget upgrade from a Windows 11 test machine: it literally got fixed while I was writing this blog post. LOL!

PowerShell Update Twofer Strikes.winget-check

Winget now knows it needs to target v7.4.0 as the current PS version. [Click image for full-sized view.]

As you can see, winget upgrade is not recommending 7.3.10 anymore. Now it’s aware of, and ready to upgrade to, 7.4.0. Good-oh!



Happy 17th Birthday PowerShell

In reading about the run-up to the MS Ignite conference — getting underway in Seattle — I learned this morning that November 14 is the anniversary date for PowerShell. That’s why I expressed the sentiment in the title — namely “Happy 17th Birthday PowerShell!”

Why Say: Happy 17th Birthday PowerShell?

Since its inception in 2006, PowerShell (PS) has slowly and steadily taken over the lead role at the command line for Windows admins and enthusiasts. Probably more importantly, PS became open-source and cross-platform in August 2016 with the debut of PowerShell Core. According to Wikipedia, as of Windows 10 Build 14971 (November 2016) PS took over the default role as primary command line shell for Windows.

What makes PS worth getting to know? Unlike the Command Prompt (which traces all the way back to DOS days) it’s a fully featured runtime environment. Thus it handles task automation and configuration management. And it does so in an environment that’s got most of the capabilities of a full-blown programming environment. Shoot: you can create interactive scripts using PS, and you can embed PS within other applications. Then, too, PS supports an extensive library of built-in cmdlets (“commandlets”) to support all kinds of specialized, focused operations. It also works both locally and remotely. IMO, it’s more fun than a barrel of monkeys!

The Journey to PS Nerdvana

I’ve been working with PS increasingly since it initially became available around the same time that Windows Vista appeared. But it’s only in the last 3-4 years I’ve really started working with it more extensively. It is very much the case that the more I’ve used it, the more I’ve come to like PowerShell.

Indeed, I’ve got a TekkiGurus story coming sometime soon that provides a PS script to show how I customize Windows Terminal and PS on my PCs. (I’ll link to it when it goes live.) It includes:

  • Download, installing and configuring OhMyPosh, along with a Nerd Font is uses for prompt customization in PowerShell
  • Download, install, and add a ColorTool to the PS environment
  • Install and use Winfetch to show off current WT/PS look and feel

So again: happy birthday, PowerShell. You’ve made my job in setting up and taking care of Windows images and installations much, much easier. Thanks a bunch!


Sussing Out Doubled-Up PowerShell

Here’s an interesting one. After running winget upgrade on Friday afternoon, I noticed something interesting. Even though I’d already upgraded that particular PC to PowerShell version 7.3.9, it still showed a version of 7.3.8 in need of an upgrade. Immediately, I started sussing out doubled-up PowerShell. As you can see in the lead-in graphic it was a case of “parallel versions.” Even though is clearly installed (PowerShell 7-x64), so is 7.3.8 (PowerShell

After Sussing Out Doubled-Up PowerShell,
Bye-Bye 7.3.8!

Turns out that 7.3.9 has some install changes. That means winget won’t simply upgrade the software. One must run winget uninstall, then winget install to do this particular round of the PowerShell upgrade dance. You can see this at work in the next screencap, which shows:

(a) notification from PowerShell that a new stable release is ready for download (white background against black text up top)
(b) notification from winget that “install technology is different” for new PowerShell release, so uninstall/install maneuver is needed

Sussing Out Doubled-Up PowerShell.winget-info

PowerShell is pretty clear that winget upgrade can’t handle this without extra maneuvers.

Thus, one approach here would be to run this sequence of wingets:

winget uninstall Microsoft.Powershell
winget install Microsoft.Powershell

The first removes the old version and the second installs the current (new) one. Easy-peasey, right?

Take the Long Way Home

The way I see things, there’s another choice when this kind of thing happens. The PowerShell installer file at GitHub (or the equivalent link shown at the top of the screencap: not only installs the new PowerShell version, it also removes the old one. So I went ahead and ran PowerShell-7.3.9-win-x64.msi on the same machine where I captured the preceding screencap. I closed PS manually, instead of having the installer do it. Then I ran winget upgrade again. And sure enough, the doubled-up version once again appears!

It gets more interesting. I ran winget uninstall MIcrosoft.PowerShell –version to remove the older version. This time, I let the (un)installer attempt to close PowerShell. It failed, and showed an “uninstallation abandoned error” (see next screencap).

Winget drops the ball trying to uninstall the newer version from inside that version! [Click image for full-sized view.]

Go with What Works

OK, I want to run the new version. But I also want to remove the older one. That cycles me back to the original screecap at the head of this blog post. If you go to Settings → Apps → Installed apps, you can easily excise older PowerShell versions from there. So that’s what I did. And presto: no more winget notifications that needs an upgrade to

One more thing: on another test machine (one running a preview version of PowerShell) I successfully used winget to uninstall and then follow up with a successful install. I think this worked because PowerShell didn’t attempt to uninstall or install itself. That said, I did also have to manually install a new profile so I could make my default PS selection afterwards. It’s always something, right?

Note added November 1: Do It From Command Prompt

On another test PC just now, I opened Windows Terminal. Then after opening a Command Prompt tab, I closed the open (default) PowerShell tab. After that I was able to use winget to uninstall the older PS version and install the new one. This required no  new profile shenanigans. It’s my recommended approach until the PS team gets this fixed (I got confirmation from an MS contact yesterday that yes, this is a known thing and they’re working on it).


Syntax Errors Derail PowerShell JSON Edits

I’ve just completed a fascinating project for TekkiGurus: a five-part series on customizing and extending Windows Terminal. For the 5th and final part, I decided to build PowerShell scripting that would handle such customizations I use as don’t fall under the settings.json umbrella. Ironically, one of those tasks involved editing that very file to change the default font. That’s when I saw syntax erors derail PowerShell JSON edits, as shown in the lead-in graphic. Let me explain…

How Did Syntax Errors Derail PowerShell JSON Edits?

I started off my project by asking Copilot to present me with some initial PowerShell commands to handle the following tasks:

1. Download, install and set up Jan DeDobbeleer’s outstanding OhMyPosh prompt customization tool. This turns out to be a more complex task than it might seem, because it requires downloading, unzipping and copying Nerd Fonts into C:\Windows\Fonts, adding an invocation to the PowerShell Profile script, dealing with OhMyPosh, and then selecting a Nerd Font as the WT default.

2. Download, install and add the colortool executable to a default Windows path. Colortool is a GitHub project that provides information about Windows Terminal color assignments for text and text backgrounds. This one was pretty straightforward.

3. Install the winfetch utility that shows WT color schemes, system info, text colors, and a few other odds’n’ends. This required only one line of code, so easy-peasey.

The error showed up at the end of my PS sequence for the OhMyPosh tasks (I’ll refer to this as OMP from now on). Seems that Copilot’s code included two errors that it took me some time to find. First, the object sequence for the default font that OMP required turned out to be the string “.profiles.defaults.font.face” rather than the truncated version that Copilot provided (“.profiles.defaults.font”). Also, it used an alias for the default Nerd Font I chose rather than its full name — that is “CaskaydiaCove NF” instead of “CaskaydiaCove Nerd Font”. Interestingly, this alias worked in Windows 10, but not in Windows 11 (there, only the full name would do).

Errors Found Are Easily Fixed

It took me a while to figure this out because I couldn’t find exact documentation to match my problems precisely. I figured out the object sequence by examining the json.settings file from another Windows PC that had the default already set and following the sequence of the object name hierarchy in use in that file. In other words, I noticed a face property in that file that was missing from my rewritten json.settings file. No wonder it wouldn’t save.

Once I made that change, I got another error message (from Windows 11) that reported it couldn’t find a font named “CaskaydiaCove NF.” I so looked in C:\Windows\Fonts, and sure enough the font name in Explorer is actually “CaskaydiaCove Nerd Font.” And again, once I made that change things worked properly.

As the old saying goes: “It’s always easy when you know how.” It took me a while to get to the last detail in the “how” part, but indeed, it was dead easy after that. Things go that way a lot in Windows-World, especially when writing code or command line instructions. I’m just glad it’s working now!

One More Thing: Replacing Munged JSON File

On the machine where I made the object reference error, settings.json remained munged. It kept throwing errors each time I started up WT or PowerShell. So I  researched the topic and learned that if you open settings.json in a text editor, then delete the whole thing, WT will rebuild that file from programmed defaults when an empty file gets saved. That put my WT and PowerShell environments back to rights, and I was then able to get the corrected script to run to completion on that PC.

I’ll observe that if you’re going to edit settings.json in PowerShell on a Windows PC, it’s a good idea to have a backup at hand to replace that file. I’m learning that it’s kind of like working on the registry, where changes can have even more serious and dire side effects. Cheers!


Reboot Fixes Winget Hiccup

I have to laugh. If you take a look at the lead-in graphic you might be tempted to believe something amiss with winget. I was yesterday when this happened on one of my test PCs. So naturally, I tweeted (X’ed?) an MS colleague who runs the winget team. About 5 minutes later he responded with “Try a reboot!” Seems that others had been reporting similar woes amenable to this approach. To my chagrin, indeed a reboot fixes winget hiccup — this time, at least. Sigh.

If Reboot Fixes Winget Hiccup, Then What?

That adds another thing I need to try before bothering the developers another time. And, if that works for me (and some few others), it might also work for you, too. Thus, it should become a part of the normal troubleshooting routine.

Indeed, I had closed and re-opened Windows Terminal prior to contacting the team. And it hadn’t done the trick this time. In fact, I even uninstalled and reinstalled winget and that hadn’t worked, either — as you can see in the lead-in graphic.

Had I known then what I now know, I would’ve tried the reboot before those other more severe fixes. And it would have worked. Thus, the next time winget goes wonky on me (especially after an update) I’ll be sure to reboot my PC and trying again before sounding the alarm.

Interesting, eh? Things may not always look simple or obvious in Windows-World. Thank goodness they may sometimes be both, and amenable to a simple solution. All hail the “three-fingered salute” (remember when CTRL-ALT-DEL would force reboot a PC?) There’s no school like the old school!

Note Added October 10 (early PM hours)

As fate would have it, MS pushed an update to PowerShell today for version 7.3.8 through WU. After it updated my problem test PC, the same issue recurred: winget source was essentially not working. None of my previous fixes (reboot, uninstall & reset sources) worked. I had to force install the current production version (1.6.2771) over the current preview version (1.7.2782) to get things working properly again. Funny that this problem should happen on the very day I attempt to document a different issue. Amazing!


Using Copilot Based PowerShell

As an experiment, I’m using Copilot to generate PowerShell commands to complete specific tasks. It’s all centered around scripting to customize Windows Terminal to add fonts, applications, and settings for a specific configuration. Using Copilot based PowerShell isn’t just a “load and go” operation. I’m having to understand and alter code to make sure it runs on both Windows 10 and 11 PCs. So far, I can’t say it’s faster than hacking it out from scratch. But I can say “very educational.”

Using CoPilot Based PowerShell, Step by Step

I’m stepping through the PowerShell code that Copilot presents for handling my specified tasks line by line. In some cases, I’m simplifying by making more direct assignments to variables and manipulating them in the scripts. In other cases, I’m cleaning up minor syntax violations (quotes around string values where they’re not needed, and so forth). In still other instances, I’m figuring out how to complete commands “silently” (supressing user interaction).

But most of what I’m getting is pretty usable. As somebody who’s written plenty of “real code” (Java, JavaScript, Perl, Python and more) this is an interesting way to expand my PowerShell chops. If you’ve got some minor automation to handle — that’s how I’d characterize my current quest — you might find this helpful, too.

Fruits of This Labor…

I’m working on a story for TekkiGurus. I will probably finish up this week, but it takes two-three weeks to get through the editorial pipeline. Thus, you should see a story there from yours truly near month’s end (October 2023, that is). My working title is Creating and Sharing Windows Terminal Profiles Across PCs. Stay tuned, and I’ll plug a link in (and correct the wording, if need be) when it’s up.


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!