Category Archives: Updates

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 OMP Winget Gotcha Is Easily Fixed

I have to laugh. When I opened Windows Terminal/PowerShell yesterday morning, I got a notification that a new version of OhMyPosh (OMP) was available. So naturally, I tried to see the update. When that failed, I tried to update OMP directly, and that failed, too. But thankfully, this interesting OMP gotcha is easily fixed. I’ll explain …

But first take a look at the lead-in graphic above. It starts with the notification. That happens when loading PS causes the OMP environment to start up, too. But running winget upgrade shows an issue with accessing the winget database. Ditto for trying an explicit, directed upgrade on the string “Oh My Posh.” What to do?

OK, Here’s How Interesting OMP Winget Gotcha Is Easily Fixed

First, the fix: I went to GitHub, where developer Jan DeDobbeleer always maintains a current version under its “Latest” link. For the record, I downloaded and installed his install-amd64.exe file there and the upgrade completed without a hitch.

But what went wrong with OMP in the first place? I sent Jan a Twitter (X) message and he replied: “Yes, unfortunately winget, just like the Store, is slower in processing new versions.” I took this to mean the changes were already posted to the manifest database, but that those changes had not yet been committed.

It’s Just a Matter of Time

And indeed, I just checked one of my other test PCs with OMP installed. Running winget just now, it shows — and stands ready to — upgrade OMP to the latest version. Looks like the notification beat the update yesterday, but they’re now back in synch. Here’s visual proof:

Interesting OMP Winget Gotcha Is Easily

This morning’s check works as expected. Database is caught up!

And boy howdy, as we say here in Texas, isn’t that just the way things sometimes go, here in Windows-World. You bet!


So Long SUMo & KC Softwares

Dang! I’ve been through this same situation before with a terrific software update monitor. For the past 3 years or so, a favorite go-to tool in my update arsenal has been KC Softwares Software Update Monitor, better known as SUMo. It looks like it’s time to bid them adieu. As shown in the lead-in graphic’s termination notice, I find myself saying “So long SUMo & KC Softwares.”

After So Long SUMo & KC Softwares, Then…?

Let me tell you how I found out things were shutting down with Kyle Katarn’s operation. I found an oversight in SUMo a few minutes ago. Seems that it’s once again recommending a beta version of DropBox as an update target. The program’s automated “find the highest numbered update” algorithm does that sometimes because beta versions are usually higher-numbered than the most current production ones.

My usual practice for the past year and more has been to send the developer a Twitter (X) message to tell him this needs checking and possibly also fixing. This time, when I attempted to send him a message the application responded “You can no longer send messages to this person.” In turn, this led me to, where I found the termination message you see above. Sigh.

Remembrance of Things Past

Back in 2019, I wrote about an older update monitoring tool, likewise pulled from the market. This was back when Windows Enterprise Desktop was still under the TechTarget umbrella (title: Missing Secunia PSI). Long story short: I used Secunia PSI from 2010 to 2016 with great pleasure and success. When it, too, was withdrawn from the market I had to scramble to find a replacement.

That’s what I’ll do now, too. Stay tuned: both the hunt and its results should be quite interesting.


Post-Update Reboot Restores Snappy Response

Hah! I should’ve known. I downloaded and installed KB5029331 on my production Windows 10 PC yesterday. When I sat down and started working this morning, I noticed two things. First, a notification popped up to remind I had to reboot. Second, this PC was running much slower than usual with lots of screen stuttering (jerky video updates). I’m happy to report, however, that a post-update reboot restores snappy response.

Why Post-Update Reboot Restores Snappy Response

The install process can’t really complete until the system can work on itself, so to speak. That is best accomplished using the Windows Pre-installation Environment (WinPE) to — as this MS Learn article puts it — “Modify the Windows operating system while it’s not running.” In the meantime, until you reboot, there’s a bunch of dangling stuff left hanging that will only be resolved the next time Windows gets to take a timeout to finish the update job that installing a cumulative update (CU) sets in motion.

And indeed there are some pretty significant changes in this update to Windows 10. Among other things, I see that the new Windows Backup shows up as “Recently added” (see lead-in graphic above, top left). I’m a little disappointed that this new facility lacks an image backup capability, though. As far as I can tell it backs up Settings, Preferences and User files only. Looks like it’s not about to replace my daily full image backups using Macrium Reflect 8. Too bad!

Side note: the new Backup takes a while to complete, too, I fired it up when I started this blog post. As I publish and promote it, it’s still doing its thing . I can’t readily tie it to a process in Task Manager, Details view, either — hmmm. This will require further investigation!

Back to Work!

The good news is that my aging but still capable i7-6700 Skylake PC (32 GB DDR4, 0.5TB Samsung 980 Pro SSD) immediately returned to its usual snappy performance after the reboot was concluded. No more lagging or jerky video. As I said at the outset, I should’ve known this could happen and rebooted before I quit for the night last night. Luckily for me, the update process took less than 8 minutes to complete, all told. And now, I’m returning to my usually scheduled activities..


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…


Beta Build 22631 Loses Update Button

It’s not the first change I encountered in this new release. But as soon as I visited the Windows Update page in settings (see lead-in graphic) I couldn’t help but notice that Beta Build 22631 loses Update button. It’s not just gone either — it’s also resistant to restoration according to all known fixes. I felt a little better when I tuned into the ElevenForum discussion for the release and learned that my problem was pretty common. So now, I just chuckle when I think about things.

One of the recommended fixes was to pause (then unpause) updates. As you can see from the lead-in graphic as well, I did that. But there’s no button to turn the updates back on, either. So while I’m chuckling again, I’m down another button. Sigh.

Getting Updates, When Beta Build 22631 Loses Update Button

Even as the obvious approach to updating goes MIA, there are ways to make Windows 11 check for and install updates. I found two pretty good methods that do the trick.

The Windows command USOClient StartInteractiveScreen will actually run WU just as if you’d clicked that missing button. Indeed, if you open WU and watch the top of the screen after you fire off this account you’ll see the panning progress bar as it performs its check.

Beta Build 22631 Loses Update Button.uso-fix

Even though WU is paused, running the USOClient command as shown above still runs the update check anyway.

There’s also a PowerShell Module named PSWindowsUpdate you can install from the PowerShell Gallery (a favorite or at least recurring haunt of mine lately). To add it to your PowerShell environment run this command string:

Install-Module -name PSWindowsUpdate -force

This provides access to the Get-WindowsUpdate and Install-WindowsUpdate cmdlets. As the names suggest, the former shows you what updates are available, while the latter provides a variety of means to install updates by KB ID or name (both values appear in the Get-… output which is handy).

Where There’s a Will…

While we’re waiting for MS to fix this odd little deficit in this Beta release, there are workarounds available to keep things going. It gave me a chance to learn a few new tricks while working around the missing button. And that’s just the way things go sometimes, here in Windows-World.

Note Added September 7: It’s Baaaaaaack!!

OK then: I’m back from a 10-day hiatus for some cool weather in Maine and getting son Gregory moved into his Boston-based college dorm. I just checked WU and the “Check for updates” button is not only back — it also works as expected. Knew this couldn’t last long. Cheers!


Inconsequential Windows Errors: Remove or Ignore?

In refreshing my recollection of what I thought was called “Berkeley’s paradox” — but isn’t — I have to raise the question: If a Windows PC throws an Xbox error and you don’t use an Xbox, does it really matter? In my case, the answer is a resounding “No!” Thus when handling inconsequential Windows errors: remove or ignore are my primary strategies. Let me explain…

Handling Inconsequential Windows Errors: Remove or Ignore?

I repeat: I don’t use an Xbox, so I don’t call on the associated complex of Store apps that offer Xbox connections, controls and capabilities. Interestingly, the Store Library shows only Xbox Game Bar. But if you search Apps on the Store Home page, you’ll find dozens of qualifying hits. Interestingly Xbox Identity Provider isn’t among them.

With a little research, I found a website named “Best Gaming Tips” that directly addresses my issue: Xbox Identity Provider Not Working. It includes a helpful PowerShell command sequence to nix this stubbornly uncooperative beast:

Get-appxpackage Microsoft.XboxIdentityProvider | Remove-AppxPackage

It now seems to be gone, too. If I use winget to search for that package name, it finds nothing. And yet, the entry still shows up in Store. I’m restarting and will try again after that… And indeed, that took care of things. Looks like if you change the underlying app structure (or the packages in which they live) you need to stop/restart the Store to let it continue to reflect current reality correctly. Go figure!

For the nonce, the problem is gone. Should I ever have need of the Xbox Identity Provider, I’ll figure out how to re-install it. That’s a bridge to burn some other day. Here in Windows-World, there are always plenty of such opportunities.


Persistent Windows Intelligence Update Failure

For the past two weeks and more, I’ve had a recurring problem on one of my Canary Channel Insider Preview test PCs. On that Lenovo ThinkPad X380 Yoga, each time I run WU the same error appears upon completion. It reports a specific installation error  — namely 0x80070057 for a so-called “Windows Intelligence Update.”  And despite all my research and repair attempts — including use of TenForums excellent reset/re-register batch file — nothing has cleared this error message. That’s why I see it as a persistent Windows Intelligence Update failure mystery.

Handling a Persistent Windows Intelligence Update Failure

I’ve been hoping — perhaps against the odds — that some new feature update would fix this issue. But so far, it hasn’t. What makes this whole thing a mystery is that you can find these failures in Update history, they still don’t help illuminate things much.  Here’s a snapshot, which I’ll explain afterward as best I can:

Persistent Windows Intelligence Update Failure.other-history

Turns out this update shows up under “Other Update” but it references no related KB number.

Notice that the error repeats thrice (3) on both reported days. Though it’s been going on far longer than August 10 and 11, that’s all the information about this error that shows up in this update history view. Even checking alternate views using the old-fashion wmic command or the Get-WUHistory PowerShell cmdlet fail to shed further light What really vexes me is that this type of update includes no corresponding Knowledge Baase article number to explain what it is and what it does.

About that Error Message

If you look up the error code online, you’ll find a MakeUseOf story that includes these suggestions (I have bolded the one I think applies here):

Error 0x80070057 usually occurs when:

  • You are trying to back up your files, and there is corruption.
  • You are trying to install a Windows operating system and the System Reserved Partition is corrupted.
  • Corrupt registry or policy entries are interfering with the Windows Update process.
  • There were some problems installing updates, and the system will attempt to try again later.

Alas, this doesn’t tell me much about how to fix the underlying issues which have now persisted through two feature updates. I’ve attempted to fix the disk structure, run both dism /restorehealth and sfc /scannow, used the TenForums reset-reregister-WU batch file, and even run an in-place repair install. Nothing has worked. This remains a mystery despite my various attempts to find and fix things. If I can’t come up with another strategy soon, I may just perform a clean install and start over. Time will tell.

And that’s the way things go here in Windows-World. Sometimes you fix the error, and sometimes you have to extirpate it by starting over afresh.

Note Added August 18

Sometime earlier this week, this mysterious failure disappeared. I’m now able to run WU sans error messages of any kind. My WU update history shows no more failure messages either — but I do see two successful “Windows Intelligence Updates” therein. One’s on August 11 (the very day I filed this item); the next is on August 17 (yesterday). Even a more detailed examination with Get-WUHistory fails to turn those earlier issues up (but then, it got upgraded a couple of days ago. I think that clears earlier update history).


Foiling False Upgrade Positives

I use a collection of tools to keep my Windows fleet updated. These include winget (in PowerShell), plus KC Softwares’ Software Update Monitor (SUMo) and PatchMyPC Home Updater. Occasionally one or more of these tools will throw a “false positive” — that is, report an update that doesn’t exist. When that happens I have my way of foiling false upgrade positives to prevent wasting time. Let me explain…

About Foiling False Upgrade Positives

This is a case where one tool can occasionally backstop another, so that one tool’s claim of an existing upgrade can be challenged successfully. Case in point: the item SUMo reported this morning, which refers to a new version of Microsoft PC Manager numbered — look at the lower right in the lead-in image above. A quick hop to the home page for Microsoft PC Manager (Beta), a download (you’ll find two buttons there), and display of Properties details from that  download shows:Foiling False Upgrade Positives.pcmgrproperties

Notice the version number reads Compare that to the “Version” column in SUMo: same!

Likewise, when I turn to winget inside PowerShell, I use its “list” command to show me what’s on my machine, then use its “show” command to show me the latest manifest in its public database. Again, both agree. That tells me pretty unequivocally that the latest version is indeed — and that’s the one I’ve already got. SUMo, in asserting that version is the most current, is somewhere off the beaten track.

What Now, Young Jedi?

I’ve got Kyle Katarn’s email and twitter feed at my disposal. So when something like this happens with SUMo I send him a message saying what SUMo reports and what the software maker (MS in this case) tells me. He’s usually very quick about fixing false positives (on a same-day basis, in fact). Ditto for issues with winget (I likewise interact with Demitrius Nelon, Winget Team Lead at MS). He is also responsive to feedback, and often provides same-day fixes as well. So far, I’ve not yet had a false positive experience with PatchMyPC (but it covers far fewer software items than SUMo’s 400+ and winget’s 2000+ manifests).

Good stuff!

Note Added August 9 Afternoon

At 4:15 PM Central (-05:00 GMT) Mr. Katarn sent me a message this item had been fixed. Ran SUMo again, and sure enough: the false positive is gone. THAT’s what I call customer service…


WinGet Upgrade PowerShell Shows Cancelled

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 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!