Category Archives: PowerShell

Insider stuff, PowerShell, Recent Activity, WED Blog

Another WinGet Version Mismatch

Leave a comment

I think I’m starting to be able to see them as they happen. I run the built-in Windows Package Manager (WinGet, aka Microsoft.AppInstaller) daily, so I get to see it act up pretty often. Yesterday, I found myself updating Python.Launcher repeatedly and endlessly. I had to wonder: could this be another WinGet version mismatch. Sure enough, that’s exactly what it was. Let me explain…

How I Identified Another WinGet Version Mismatch

As I was noodling about with the unending sequence of Python Launder updates, I thought to myself “Why not try the old uninstall/reinstall manuever?” This is actually a valid nostrum for many WinGet gotchas and hiccups, so it wasn’t a bad thought. If you look at the lead-in graphic, you can see what happened when I tried that very thing, which produced a major clue. It reads (in red text):

Multiple versions of this package are installed. Either refine the search, pass the ‘–version’ argument to select one, or pass the ‘–all-versions’ flag to uninstall all of them.

OK, then: there’s proof there is a version mismatch. And indeed the output from WinGet list Python.Launcher reads:

Name   Id                       Version  Source
-----------------------------------------------
Python Launcher Python.Launcher 3.13.5   winget
Python Launcher Python.Launcher < 3.13.5 winget

Notice the mismatch in the two version strings. The lower one has a leading “< ” at the head, which I have to bet is an outright mistake.

Targeted Uninstall Does the Trick!

Looking at the two versions, I have to believe they’re the same, and that one of them has an error in the Version string data. Thus, I targeted that one in a WinGet uninstall directive, to wit:

WinGet uninstall Python.Launcher –version “< 3.13.5”

And, sure enough, that appears to fix the issue. When I run WinGet upgrade … again after that, it comes up with nothing to upgrade, and stays mum on the subject of Python.Launcher. Problem solved. Next!

One More Thing…

Please note that the responsibility for a version mismatch falls on the package developer. They’re the ones who enter the information that goes into the package repository, and define the version strings for what’s known and what’s current. So it’s on them to fix things when this sort of hiccup happens.

That said, I’m going to urge the WinGet developers to write some string checking code for version strings before they’re allowed to be checked into the repository. Two weeks ago a parenthetical phrase in a Visual Studio update also caused the same behaviors. Seems to me that a little “string policing” effort might help head such things off at the pass. Just sayin…

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11, Windows Update

Unsticking Lenovo System Update

Leave a comment

From May 6 through 12, I had a Lenovo System update stick in WU. That is, it would attempt to install, fail, and then push a retry button at me. Alas, that meant WU wouldn’t show me any newer updates, either. At the end of this cycle KB5058496 came along. It didn’t show up in WU, either. That’s when I found myself unsticking Lenovo system update on the Lenovo ThinkPad Yoga X380 where it happened. How did I do that? I ran the:

Reset_Reregister_Windows_Update_Components_for_Windows11.bat

batch file from the Eleven Forums tutorial Reset Windows Update in Windows 11. As it so often does, the Lenovo System update worked the next time I tried after said reset operation had completed and I’d rebooted that PC (as per the batch file’s own instructions). The new CU installed, and went to Build 26120.3964.

More on Unsticking Lenovo System Update

I’m not sure why the WU version got stuck, nor why it stayed that way for some time. When I looked in the Windows-Update.log file I produced via the PowerShell Get-WindowsUpdateLog cmdlet, no supporting detail told me why it happened, either.

All that Copilot could tell me was that it must be a Lenovo servicing driver update of some kind. Google was willing to speculate it might be the driver for the Lenovo Intelligent Thermal Solution. Lenovo Vantage kind of confirms this in a back-handed way, in that its history shows the latest version dated March 2024 with version number 2.1.14.0, which certainly seems to follow in the general numbering track for the item that got stuck.

So I checked Device Manager > System devices > Lenovo Intelligent Thermal Solution properties. Sure enough, the currently installed version is 2.1.52.0. Interestingly the install date shows as 4/11/2025 (same as in WU update history). That leaves me glad this already-installed driver somehow got itself unstuck. I’m still wondering why WU offered it repeatedly from 5/6-12.

These meaningless mysteries never stop in Windows-World. I’m just glad this apparently unnecessary driver offer stopped when I reset WU. Now the machine is running Build 26120.3964 and the right Intelligent Thermal Solutions driver without further issues. I’m good for now, but sure something similar will pop up soon, on one or more of my mini-fleet of 12 PCs. Stay tuned!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Rebuilding P16 Windows 11 24H2

Leave a comment

Allrighty then: I got tired of seeing odd, unfathomable and stuck packages in the component store. That image resides on the Lenovo ThinkPad P16 Mobile Workstation. So yesterday, I set about rebuilding P16 Windows 11 24H2 to come up clean. Let me explain what I did, and why I did it. The whole story shows in the lead-in graphic. It depicts the image going from 10 reclaimable packages to 2 and then to zero (0): clean! But you’ll  need keen eyes (or be unafraid to grab this screencap and make it readable.)

3 Steps To Rebuilding P16 Windows 11 24H2

STEP 1: My first step was to visit Settings > System > Recovery and then click the “Reinstall now” button to kick off an in-place upgrade repair on the P16’s suspect Windows image. For the record, it failed my “sniff test” because it kept showing 4 reclaimable packages that wouldn’t surrender to DISM /online /cleanup-image
/startcomponentcleanup. The reinstall took about 45 minutes to complete, but required little or no effort from yours truly.

STEP 2: My second step was to run the aforementioned DISM …         /startcomponentcleanup command and see what remained. As I expected, that brought the number of reclaimable packages down from 10 to 2.

STEP 3: My March 21 blog post “Remove Package Kills Spurious Reclaimables” explains this use of a specific DISM /Remove-Package target that’s responsible for 2 spurious packages showing up in a canonical Windows 11 24H2 production image. TLDR version is: a deeply superseded package is stuck in WinSxS, but a single command removes both spurious reclaimables in one go.

The results appear in the fine print at the bottom of the lead-in screencap: a clean version of Windows 24H2 Build 26100.4061, with zero (0) reclaimables in the component store. Good-oh!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog

OhMyPosh Upgrade Needs WinGet DB Reset

Leave a comment

Something interesting just popped up in Windows Terminal. Literally. Upon starting Windows Terminal, I got a notification from OhMyPosh that it was updating to the latest version: 25.21.0. So I closed WinTerm and re-opened it to run WinGet upgrade –all — include-unknown. As you can see in the intro screenshot, WinGet went ahead and updated OMP again anyway. When I asked Copilot why this happened, it explained that an OhMyPosh upgrade needs WinGet DB reset so it is forced to rescan all currently installed packages. A restart makes that happen automatically, BTW.

Why OhMyPosh Upgrade Needs WinGet DB Reset

When Windows Terminal has been up and running already, WinGet doesn’t refresh its current package data through a simple open/close operation. Instead, users must run the following WinGet command to force that to occur (again, a restart has the same effect):

winget source reset --name winget --force

This tells WinGet to rebuild its list of local (that is, currently installed) packages. After that running an update check won’t show OhMyPosh in need of updating anymore. I checked this out on another test PC and indeed this approach works. Good to know!

ICMYI: A Quick Intro to OhMyPosh

Many readers will recognize OhMyPosh (OMP) as “the way” to snazz up the command line in Windows Terminal/PowerShell. For an inkling of what this looks like using developer Jan De Dobbeleer’s own unique theme, look at the top and bottom of the intro graphic. It shows glyphs for (from left to right):

  • the current login account (ed) and folder icon
  • execution time for most recent command (0 ms)
  • battery status (power connector against green means “good”)
  • current environment = PowerShell (pwsh)
  • current time = 10:33:08 (time of screen capture)

The last two items in the preceding list show up at right, the first three at left, on the command line. For all items shown, and a whole bunch more OMP offers users a plethora of themes. It also provides good documentation and “source code” (JSON markup, actually) for all of them. Users can even create their own custom themes. I’ve written an intro and how-to story about OMP for TekkiGurus, but that site is now defunct. Find it via this WayBack Machine link. Enjoy!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows Update

Correlating KB Items and DISM Package IDs

Leave a comment

Here’s an interesting situation. I was reading on Neowin this morning that MS has fixed a Windows 10 issue that caused BSODs on some systems (not mine, thankfully). To find or uninstall such an item, one must use DISM. But DISM deals in “Package Identity” strings, not in KB article numbers (e.g. KB5057589, as in this case). Surprisingly, correlating KB items and DISM package IDs turns out to be vexing and tricky. Indeed, this SuperUser thread more or less confirms what I quickly figured out. That is: the only datum both items have in common (using Update History for KB items and DISM Get-Packages for PkgIDs) is their install date/time.

Fortunately, what I was seeking showed up dead last in the Get-Packages output in PowerShell/Windows Terminal. As you can see in the lead-in graphic, it’s the only item whose install date matches that for KB5057589. But there’s no inherent correspondence with its PkgID: Package_for_WinREServicing~31bf3856ad364e35
~amd64~~19041.5728.1.1. What to do?

More On Correlating KB Items and DISM Package IDs

I figured there might be a PowerShell script (or something similar) already available to establish this correlation. AFAIK, nope! I thought that Copilot might be able to write me such a script. Nope again: it wants to look for the KB item ID inside the PkgID. You can see from the foregoing item (or by looking at installed updates using DISM Get-Packages) that this just ain’t so.

It looks like the only way to put all this together is to install the PSWindowsUpdate module, then use its built-in Get-WuHistory cmdlet. By writing that to a file, and then doing likewise with output for DISM Get-Packages, it should be possible to use matching date strings for KBs from the former with the “Install Time” attribute value from the latter to find and document matches.

Another Project for My List

Now that I know what I must do, I need to figure out how to do it. That will make excellent fodder for another blog post. As soon as I find the proverbial “round tuit” I’ll put that together and post it here. In the meantime, it’s nice to see that the obvious path to success (looking for the KB item ID inside the DISM PkgID) isn’t the actual path to success. Here in Windows-World, that’s all too often the case. I’m glad it keeps me entertained. I hope you feel likewise.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

Command Palette Brings WinGet Wrinkles

Leave a comment

OK, then. I’m having an absolute ball running the new v0.90 PowerToys Command Palette for all my everyday Windows tasks and upkeep. This morning, it’s a quick hop into CmdPal (as it’s commonly abbreviated in Windows Terminal or PowerShell discussions or documentation) to see how WinGet behaves. It works just fine, but Command Palette brings WinGet wrinkles that I had to experience to understand. Let me explain…

What Command Palette Brings WinGet Wrinkles Means

I’m used to running WinGet inside PowerShell. That means I get a lot of support from its inbuilt facilities, as well as those from the surrounding Windows Terminal environment. As far as I can tell right now, running WinGet from CmdPal lacks that support.

Thus, for example, when I type winget up, the command shell is smart enough to know that I’m probably going to want to run my all-time favorite winget upgrade command — namely:

winget upgrade –all –include-unknown

Indeed you can see that from the auto-complete function in PowerShell in lighter text if you examine the following screencap carefully. Note the cursor sits just to the right of “up” in that string. If I strike the right-arrow key it will enter the rest of the line for me.

When I enter strings into CmdPal, I don’t get the auto-complete function automatically. It may remember over time, but I’m just starting to use it so it has nothing to remember right now.

Also, when I hit the Enter key after typing out the full string shown above manually, it runs inside of the Command Prompt shell, not PowerShell. That means I have to approve installers via UAC (User Account Control) so they can run with a mouse click. Inside PowerShell, those installers run without requiring UAC approvals.

Right Now, I Prefer WinTerm/PS to CmdPal

I’m not yet aware if I can customize CmdPal to run commands in PowerShell rather than Command Prompt by default. Part of my confusion stems from CmdPal as a Windows Terminal facility that precedes the introduction of the utility of the same name via PowerToys. But hey, anything new comes with little wrinkles and niggling details in need of working out and understanding more fully.

But again, it’s a gas to use CmdPal. And I am having great fun working my way into what promises to be a terrific and capable tool. I just need to learn how to use it properly, and well.

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Unintended OneDrive Consequences

Leave a comment

I have  to chuckle. Working on a Windows 11 revision to a data recovery  story yesterday, I ran into “the law of unintended consequences.” In this case, I switched OneDrive backup on to test the Windows Backup app. In so doing, I picked up some unintended OneDrive consequences. You can see them in the lead-in screenshot.

Overcoming Unintended OneDrive Consequences

Blithely, I started using files for my primary MSA from OneDrive on that test PC. (I chose the snappy and powerful ThinkStation P360 Ultra.) Immediately, it picked up Windows Terminal environment settings from the cloud, not the local PC.

Check the lead-in graphic. The error results from running the cloud-based PowerShell profile. It references supporting infrastructure for the WinGet.CommandNotFound capability. This allows WinGet to suggest a source to install a command that

(a) PowerShell sees as undefined
(b) WinGet recognizes
(c) knows where to find
(d) can install on the user’s behalf

Read the error message beneath the failed import command at Line 8 in that output stream. You’ll see the module named Microsoft.WinGet.Client is not loaded. Translation: that module IS squared away on PC from which  OneDrive supplies shared files.If it gets loaded on this machine, the error won’t recur.

Putting the (Right) Pieces in Place

The next screencap shows what I did to fix this. I looked up the instructions to get Microsoft.Winget.Client loaded. It requires two back-to-back PowerShell commands. The first handles install, the the second import:

Install-Module -Name Microsoft.WinGet.Client
Import-Module -Name Microsoft.WinGet.Client

I ran those commands  on the P350 Ultra. Where requested, I provided permission to access the module gallery for the client module. Next, PowerShell said”Restart Windows Terminal.” After I did that everything worked OK. Here’s visual proof:

What you see is that PowerShell opens normally, with no error messages. Next, you see NeoFetch which shows system and OS info for some nice eye candy. But that last part is proof that unknown command handling is working as it should. I typed ‘vim‘ in at the command line (it’s a well-known text editor popular in UNIX and Linux circles, not installed by default in PowerShell). And you see the results of the Microsoft.CommandNotFound module suggesting WinGet syntax for how to install this tool if wanted.

Problem solved!

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Remove Package Kills Spurious Reclaimables

Leave a comment

Over the past year or so, I’ve blogged 7 times about “spurious reclaimables” in Windows 11. They persist in the component store even after DISM /StartComponentCleanup. You can see this in the lead-in graphic. Right now, in fact, the current Beta and GA releases show this behavior. Indeed, it comes from older packages that the preceding DISM command can’t (or won’t) clean out. Reading the CBS.log carefully, someone at ElevenForum  figured out that a single remove package kills spurious reclaimables dead.

Running Remove Package Kills Spurious Reclaimables

A line in the CBS log file that caught long-time member and guru @Bree‘s eye. It showed up in the CBS.log via DISM … /AnalyzeComponentStore. It reads (in part):

Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10] is a top-level package and is deeply superseded

In the component store, a top-level package is a primary package. It contains all the bit and pieces — namely files, resources, and instructions — to install or enable some specific Windows update or feature. It’s called top-level because it may contain (or be a parent to, in hierarchical terms) other, related packages and features.

What caught Bree’s attention was the “deeply superseded” phrase in the descriptive text. Normally, DISM /StartComponentCleanup doesn’t remove top-level packages from WinSxS. “What if,” he reasoned, “this were removed because of its obsolete status?” And indeed, it turns out that removing this package also removes a child package as well. And these two nogoodniks turn out to be the very same two packages that show up as spurious reclaimables when running DISM /AnalyzeComponentStore.

Doing Away With Deeply Superseded Package

If your Windows 11 still shows 2 reclaimable packages after a successful  DISM /StartComponentCleanup operation, try this DISM command to remove the deeply superseded package (if it’s not the cause, this command will simply fail but won’t harm the component store):

dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10

It worked on all the Windows 11 systems I tried it on, including current Beta and GA releases (5 in all). You can also regain about 1.2-1.3GB of space in the component store by following up with a DISM /StartComponentCleanup command. Cheers!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Updates, WED Blog

Extirpating WinGetUI Requires Registry Cleanup

Leave a comment

Here’s an odd one. A few months back, I tried out a pre-release version of UniGetUI that still fell under the WinGetUI umbrella. The package info involved — as you can see in the lead-in graphic — was ID=MartiCliment.UniGetUI.Pre-Release Version=1.5.2. I thought I’d deleted same, and it showed up in none of Programs and Features, Settings > Apps, or Revo Uninstaller. Yet it kept showing up in WinGet‘s upgrade and list commands anyway. TLDR; extirpating WinGetUI requires registry cleanup to “make it go away.” Sigh.

Why Extirpating WinGetUI Requires Registry Cleanup

Apparently, adding packages to Windows leaves all kinds of traces in the file structure, as well as settings and pointers that get instantiated in the registry. Furthermore, it looks like WinGet relies what it finds in the registry to create its view of what’s installed on a Windows PC. Thus, I had to remove all registry entries that included the string “WinGetUI” and/or “UniGetUI” (except for stuff not related to the application or its package info, such as pointers to Word files I’d written about those tools).

And indeed, that did the trick. Neither WinGet Upgrade nor WinGet List Marti.Climent.UniGetUI,Pre-Release posits pointers to something I know isn’t there. The next screengrab provides visual proof. Good-oh!

After removing all WinGetUI references in the registry, WinGet no longer sees the older package.

It just goes to show that some uninstall facilities work better than others. For all its good features, it appears that WinGetUI/UniGetUI does not clean the registry upon uninstall deeply enough to tell WinGet that it’s gone, gone, gone. You’d think that wouldn’t happen with a WinGet-related and -focused follow-on tool. But here’s a counter-example that says otherwise.

That’s the way things go here in Windows-World, where not all is as it seems, not always works exactly the way it should. Sigh. When that happens, we clean up manually and keep on truckin’…

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Security, WED Blog

PowerShell-Based Defender Commands

2 Comments

The other day, my Canary Channel X380 Yoga hung up on Windows Update. In other words, after  some kind of WU download difficulty, it wouldn’t download from those servers. There are lots of ways to unstick WU, but one of the easiest is to get Windows Defender to update. Personally, I prefer to use a single PowerShell command with no arguments or parameters, rather than navigating into Windows Security to see if that might help. Indeed, there is a plethora of Defender controls in PowerShell. The one I used is just a single instance in a collection of over a dozen items.

Finding PowerShell-Based Defender Commands

You can see the command I used to ask PowerShell to update Defender in the lead-in graphic. It’s named Update-MpSignature, and it takes no mandatory arguments or parameters. What you’re looking at there, in fact, is the general PowerShell Module Browser at MS Learn. It’s dialed into Defender commands, shown in the breadcrumbs up top: Learn/Windows/PowerShell/Defender. As you will soon find out, there is a baker’s dozen of such things there under this heading.

Other Defender Commands get their own listings, but also appear in a handy-dandy table (simplified contents reproduced verbatim below). Indeed, each one also has its individual command reference, for which you find links in said table.

 

Add-MpPreference
Get-MpComputerStatus Gets the status of antimalware software on the computer.
Get-MpPreference Gets preferences for the Windows Defender scans and updates.
Get-MpThreat Gets the history of threats detected on the computer.
Get-MpThreatCatalog Gets known threats from the definitions catalog.
Get-MpThreatDetection Gets active and past malware threats that Windows Defender detected.
Remove-MpPreference Removes exclusions or default actions.
Remove-MpThreat Removes active threats from a computer.
Set-MpPreference Configures preferences for Windows Defender scans and updates.
Start-MpScan Starts a scan on a computer.
Start-MpWDOScan Starts a Windows Defender offline scan.
Update-MpSignature Updates the antimalware definitions on a computer.

As you can see there are lots of interesting and sometimes useful ways to interact with Defender in PowerShell. They’re worth exploring and getting to know. I used a simple one to unstick WU this week, but there are lots of other tools here, ready to help you manipulate Defender in Windows Terminal or via automation scripts. Have at it!

Facebooklinkedin
Facebooklinkedin