Category Archives: Updates

Cool Tools, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

Extra C++ Redistributable Must Go

August 22, 2023 Ed Tittel Leave a comment

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…

Insider stuff, Recent Activity, Troubleshooting, Updates, WED Blog, Windows 11

Beta Build 22631 Loses Update Button

August 21, 2023 Ed Tittel Leave a comment

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.

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!

Cool Tools, Insider stuff, Recent Activity, Troubleshooting, Updates, Windows 11

Inconsequential Windows Errors: Remove or Ignore?

August 17, 2023 Ed Tittel Leave a comment

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.

Insider stuff, Recent Activity, Updates, WED Blog, Windows 11

Persistent Windows Intelligence Update Failure

August 11, 2023 Ed Tittel 2 Comments

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:

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

Cool Tools, Recent Activity, Updates, WED Blog, Windows 10, Windows 11

Foiling False Upgrade Positives

August 9, 2023 Ed Tittel 1 Comment

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 3.4.6.0 — 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:

Notice the version number reads 1.2.4.22027. 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 1.2.4.22027 — and that’s the one I’ve already got. SUMo, in asserting that version 3.4.6.0 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…

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

WinGet Upgrade PowerShell Shows Cancelled

June 30, 2023 Ed Tittel Leave a comment

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 TekkiGurus.com 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!

Cool Tools, Recent Activity, Troubleshooting, Updates, WED Blog, Windows 10, Windows 11

Teams App vs. Application Update Conundrum

June 23, 2023 Ed Tittel Leave a comment

I’m chuckling as I report this. Right now many people — including me — run both the app and the application version of Microsoft Teams on their Windows 10 and/or 11 PCs. I’ve been sussing out another update mystery in keeping Teams current, and have finally figured it out . . . I think. It seems there’s an easily overlooked Teams app vs application update conundrum in play. The Microsoft Store keeps the app version current on its own; regular applications often require human intervention for updates. And to make things more interesting, this is apparently a case where WinGet isn’t always equipped with pointers to the latest, greatest update packages. Sigh.

One more thing: Because the Teams application runs as part of the Office (365 or 2019 or later “dated versions”) running update in Outlook, Word, PowerPoint and so on also takes care of the Teams application update. Good to know!

Solving the Teams App vs. Application Update Conundrum

I started twigging to my issue when I saw two entries for Microsoft Teams in my update scanner SUMo. Winget told me one of those instances was an application (ID: Microsoft.Teams; version 1.6.00.12455 was most current, but I was still running 1.6.00.6754). The other one was an app (ID: MicrosoftTeams_8wekyb3d8bbwe; version 23134.300.2089.5908; the _*weky… string in the ID is what tells you it’s an app, BTW).

That led to my “Aha!” moment. Microsoft Store keeps apps up to date pretty darn well without requiring human intervention. Regular applications, not so much. So I had to fire up the application, log in, navigate into Settings, and tell it to “Check for updates.” That did the trick, after which Teams was finally up-to-date. Amusingly it’s now running version 1.6.0.16322 — a higher version number than the SUMo recommendation that twigged me to this interesting issue in the first place. Go figure!

Keeping Windows apps and applications up-to-date is always interesting. In cases like this one, in fact, it may even be a little too interesting. But it’s always fun to figure things out.

Insider stuff, Recent Activity, Updates, WED Blog, Windows 11, Windows Update

Post-Update Cleanup Causes DISM Loop

June 14, 2023 Ed Tittel Leave a comment

I’m not sure what’s causing a fascinating Windows 11 issue. But you can see what it looks like in the lead-in graphic for this blog post. Basically, post-update cleanup causes DISM loop, whereby cleanup keeps repeating 100% completion, until I forcibly stop it with Ctrl-C. Weird!

I’ve never seen anything like this before. It occurred on Windows 11 Canary Build 25387.1200, after applying KB5027120 “2023-06 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows Version Next for x64.” This comes in the wake of KB5027849, released June 7, that takes the build to minor release number 1200. Again: Weird!

When Post-Update Cleanup Causes DISM Loop, What Now?

The traditional “next move” when something odd and extraordinary occurs in Windows is to reboot, and try again. So that’s what I did. The affected PC — a Lenovo ThinkPad X380 Yoga — came back up without any obvious signs of distress or damage. I was able to remote in without issues, either. And on a retry of the DISM… /startcomponentcleanup command it ran through to completion without further issues.

There’s a known oddity that this DISM command causes a weird doubling of the progress bar if (a) a CU is applied to a Windows 10 or 11 PC and (b) the command is run before the target system is rebooted for a second time. I can only speculate this oddity has been somehow exacerbated in this version of Windows 11.

Be that as it may, the old standby troubleshooting technique — reboot, and try again — seems to do the trick. Once again, the old “three-fingered salute” comes to the rescue. Go figure!

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

Tracking Minor Updates Poses Diminishing Returns

June 13, 2023 Ed Tittel Leave a comment

Here’s a question whose best practices answer may save admins time and effort. While indeed many developers now push regular updates for their software, not all are equally urgent. Why? Because whereas some updates add valuable new functionality or plug serious security gaps, others may not introduce much of note. That’s why, IMO, tracking minor updates poses diminishing returns against the time and effort required to find, download, and install them.

A case in point appears in the lead-in graphic. Antibody’s WizTree is a tree graph oriented disk space layout visualization and management tool. You’ll notice that winget doesn’t track release numbers past the first sub version level (e.g. 4.14 is what its “show” sub-command displays, and what its “list” sub-command finds on the target PC).

Why Say: Tracking Minor Updates Poses Diminishing Returns?

Simply put, if winget doesn’t track it and package labels don’t include it, not even the developer thinks it’s noteworthy. I’ve had other development teams confirm this approach to me. Thus, for example, when I contacted IObit to ask about minor revisions to their Driver Booster tool (example version number 10.4.0.127) they’ve told me that they don’t advise users to update unless something new or security-related is changed in a new version. If so, their policy is to increment version numbers more significantly, and to use the tool’s auto-update function to recommend and flog the update process forward.

Long story short: if the developer doesn’t recommend installing every minor update that comes along, I can’t do otherwise. For one thing: life’s too short to keep up with absolutely everything. For another, working toward scheduled update windows for most corporate software means choosing only “worthwhile updates” for inclusion. This reduces the amount of change — and its attendant risk — during such windows, and keeps the time and effort required to survive them as manageable as possible.

The old saw: “If it ain’t broke, don’t fix it” somehow seems apt. Don’t let OCD tendencies to keep up with all change put you in a bind. Relax, and watch the blinking lights instead…

Cool Tools, Insider stuff, Recent Activity, Updates, Windows 10, Windows 11

Winget Upgrade May Require Cleanup

June 2, 2023 Ed Tittel 7 Comments

OK, then: yesterday dev lead Demetrius Nelson and his Winget team pushed an upgrade to winget. This comes courtesy of the Microsoft Store, and shows up as part of the App Installer and/or Windows Terminal packages. I noticed also that winget would occasionally throw the error “Failed in attempting to update the source: winget” as you can see in the lead-in screencap. What made it interesting was that it happens on some, but not all, of my Windows PCs. Now, let me explain why this post says that the “Winget upgrade may require cleanup.”

Why Say: Winget Upgrade May Require Cleanup?

When I saw this pop up in the wake of the new release, I figured the changes involved in pushing it out the door might have been involved. So I contacted Mr. Nelson and sent him (among other info) the screencap that leads this piece off. He responded this morning and explained how I could fix the issue, using the commands:
winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe winget source reset --force
The first string removes the winget package from the PC. The second resets the winget environment, which is why the user must agree to Terms again before winget will run. After that it shows no upgrades are available (“No installed package found matching input criteria” with no accompanying error message (“Failed in attempting to update the source: winget”).

Problem solved; case closed. It’s always good to get the fix right from the source. Had to laugh about the “It won’t break while the engineer is watching” comment he sent me, too. Isn’t that just the way things go in Windows-World (and elsewhere in life)? LOL

See the whole thing here:

The fix is in — and working! Good stuff…