Category Archives: Updates

Chrome Makes MS Catalog Get Weird

Here’s something I’ve never run into before. It’s quite interesting, actually.  This morning I read about a new update –KB5040527 — for both Windows 11 22H2 and 23H2 versions. When WU failed to produce same upon an update check, I followed the link in the Windows Latest story that caught my eye, and tried to download the update via Chrome. First up: Dutch, next French, and then Spanish on a third try. Edge showed it to me in en-US (English – United States) right away. Thus I couldn’t help but aver that Chrome makes MS Catalog get weird. You can see the French version in the lead-in graphic.

We are from France: Chrome Makes
MS Catalog Get Weird

I wasn’t sure what could happen if I were to install an update for some language with no corresponding language pack present. Now that I write out those words: I’ll probably make an experiment on another test PC to see what happens. Hoping to avoid language issues, I instead used the English-United States version (en-us) that Edge handed me for the update. In passing, I’ll observe it took some while for this to finish, both in download and install phases (about 15 minutes in all, longer than a typical WU update by 10 minutes or more).

Further adding to the mystery, I can’t replicate this behavior on any of my other production-line Windows 11 test machines. I guess I can try on my wife’s and son’s PCs later today to see if I can provoke multiple languages again. If it is truly a one-off, I blame cosmic rays!! One must’ve crashed through my PC recently and flipped an important bit. If you’re not laughing yet, too bad you can’t hear me carrying on. IMO, this is hysterical…

 

Facebooklinkedin
Facebooklinkedin

Word Gets Seriously Weird

I should know better, so I have no one to blame but myself. Yesterday, I was beavering away on an MS Word project for one of my regular customers. An update notification popped up in Word and I confess: I clicked “OK” before I really thought about what that might mean. Alas, I was about to find out — the hard way. My project entailed “rolling up” three tech briefs into one single, larger document which made it mostly a cut-n-paste exercise with some minor reformatting, intro/outro content creation, and a QA pass over about 6,000 words of copy. Then, as MS Word gets seriously weird in the wake of the updates, I notice things aren’t working correctly.

When Word Gets Seriously Weird, Start Over

As somebody who’s been writing professionally in MS Word since the mid-1980s (40 years or so), I’ve seen my share of Word weirdness. Because I was heads-down, trying furiously to hit a deadline, I didn’t really notice what was going on. But slowly it dawned on me that:

  • cut-n-paste boundaries were off
  • item selection was acting strange
  • keyboard and mouse responses were slow and cranky
  • menu commands were sluggish

Finally I thought to myself “Maybe updating Word while I was working wasn’t such a good idea.” I did close and then reopen all files, but apparently that was insufficient. So I went for the first step in any real Office repair: a reboot. I closed all open apps, initiated a restart, and crossed my fingers.

Shoulda Done That in the First Place!

After the reboot, it took a while to set my content elements back up. I opened three source files, a target file, and a template/go-by file, and then started over on the target file. Everything worked just like it was supposed to. I was able to finish the second try at the project in about an hour and half, more or less in line with my original estimate.

What I hadn’t counted on — and won’t get caught on again for a while — is that permitting Office to update itself while I was trying to hit a deadline wasn’t a good idea. I ended up losing another 90 minutes to that debacle. But eventually, I figured out what was up, and responded appropriately. And isn’t that just the way things go sometimes — especially when deadline loom — here in Windows-World? You bet!

Facebooklinkedin
Facebooklinkedin

WinGet Source Hiccup Self-Repair

I saw a new WinGet error message yesterday. In attempting a “blanket update” PowerShell showed a “Failed when opening source(s)…” error instead (see intro graphic above). That same error also suggested its own fix via WinGet source reset. I didn’t read carefully enough to see that the –force option was also required. But my next upgrade attempt succeeded anyway. There was apparently a WinGet Source hiccup self-repair at work. What happened?

OK, Why Did WinGet Source Hiccup Self-Repair?

I can only speculate that there was a transient communications glitch between my test PC and the URLs associated with the Microsoft Store and WinGet itself. To me, this dual drop most likely indicates an interruption of service at the ISP level. Both domains have vastly different IP addresses so it’s unlikely to have been something at their end. Hence my best guess that something affected the lookups from my end through my ISP,  Spectrum.com.

It’s amusing that I discovered this hiccup simply by entering another command (albeit an incorrect one). Upon re-entering the original blanket update:

winget upgrade –all — include-unknown

Everything went through as expected on the second try. Through well-cultivated habits, in fact, my first impulse with Windows when things don’t work as expected is simply to try again and see what happens. In this fragile world of ours (including Windows-World) what doesn’t work at first often succeeds on a subsequent attempt.

Had it turned out otherwise, I’d be showing a different screencap, and telling a different story. This time, second try was the charm!

Facebooklinkedin
Facebooklinkedin

Forced Win10VM Upgrade Gets Stuck

This is pretty strange. I checked in on one of my Windows 10 VMs this morning, and found WU stuck part-way through a Windows 11 upgrade. This popped up, courtesy of toggling the familiar “Get the latest updates…” option in Settings > Windows Update. Alas, this forced Win10VM upgrade gets stuck. I’m trying some things to undo that state. Bear with me, as I report on what things I try…

Before I start introducing repair maneuvers and upgrade counters, let me explain I’m running this VM deliberately to check and test Windows 10 stuff.  Thus, I have ZERO desire to upgrade it to Windows 11, even though I know full well that I could if I wanted to.

Fixing Forced Win10VM Upgrade Gets Stuck

The excellent and usually reliable batch file from TenForums.com “Reset_Reregister_Windows_Update_Components….bat” returned WU in the VM to a normal appearance. Then I ran “Check for updates…” While watching the sliding balls, I wondered if I’d find this VM in the same situation as before. Not yet: it offered a routine Defender update, plus KB5037849. I let things roll.

Interesting results ensued. Defender download threw a 0x80070643 error.  A quick jump into Windows Security > Virus & threat protection > Check for updates showed that everything was already up-to-date. Subsequent “Retry” attempt dropped the same error anyway. Odd…

Back in WU, KB5037849 went through download and install. Eventually it got to the “Restart now” button, which I pressed. I’m pretty sure the Security Update error was bogus because of internal status in Windows Security, so off it went…

Beta Channel Sign-Up Effected!

When I got back into Windows Update, I found a successful transition to the CU, but an error report on the Security Update, to wit:

But because another visit to Windows Security showed the same update was still current, I’m seeing this as a Windows Update problem, not as an issue with security updates on this VM. So I jumped over to Windows Insider Program and signed up for the newly re-opened Beta Channel for Windows 10. Indeed, that was the whole reason I started down this rockier-than-expected road.

Then I restarted again, to see what would happen on the next go-round. WU came back clean, and I’m opted into the Beta Channel. Success, but without some oddities along the way. Another magic day in Windows-World…

 

 

Facebooklinkedin
Facebooklinkedin

WinGet Updates Quiescent Browsers Best

Here’s one to ponder. Just this morning, in going through a gaggle of WinGet updates, I noticed something interesting. WinGet will happily install browser updates on Windows PCs, whether or not the target browser is running. But if that target is not running, it will invariably succeed and leave the program ready to run it’s newest, best self the next time it’s called. When run against running browsers, though, WinGet will often be unable to finish the job completely, despite reporting installation success. Hence, this epigram: WinGet Updates Quiescent Browsers Best.

What WinGet Updates Quiescent Browsers Best Means

Over the past 3 years or so, I’ve gotten pretty darn familiar with WinGet, Windows’ built-in package manager. It’s bundled into Windows 11 and easily available through GitHub (microsoft/winget-cli). I use this tool pretty much every day to check for updates on my fleet of 10-12 Windows PCs here at Chez Tittel. And as I use it, I get the chance to observe and report all kinds of issues and oddities, both large and small.

This is a pretty small one, as it turn out, but worth noting even so. What happens if you don’t exit a browser before using WinGet to upgrade same? It varies. Chrome will sometimes stick stubbornly to its pre-upgrade state, and require an in-app update to catch up. Firefox may require you to “Relaunch” the browser to finish things up completely. Edge does a good job of self-updating but also works well with WinGet (as you’d expect, as they’re both MS software).

Is This Just “Same-old, Same-old”?

Yesterday, I wrote a post entitled When WinGet Balks, Try In-App Updates. In a small way, this post is a further musing on some of the same themes. But because I leave browsers open on the desktop all the time — as do many other users — this one is a more focused and directed play on the same general topic.

And isn’t that just the way things sometimes (or even often) go, here in Windows-World? At least for me, anyway…

Facebooklinkedin
Facebooklinkedin

When WinGet Balks, Try In-App Updates

OK then, I’m still working my way back into the groove after 8 days of vakay. Yesterday, I started running WinGet upgrade … on the whole fleet, to get things caught back up. I quickly noticed that WinGet wanted to update a slew of stuff, including MS Teams and MS PC Manager. But on at least a couple of test PCs, WinGet wasn’t up to those tasks. I quickly remembered that when WinGet balks, try in-app updates often works. And indeed, it did the trick for both those items.

Remember: When WinGet Balks Try In-App Updates

Most often when I see a WinGet upgrade fail to update an app, it’s because the app is running and something inside its runtime environment won’t let go of some resource necessary to bring the update to a successful finish. Apparently, that was the case for both Teams and PC Manager yesterday, where I could see a valid version mismatch between what was running and what WinGet wanted to install.

You can see what I wound up with in the lead-in graphic after I ran the in-app update function for both programs. They show the “latest and greatest” versions for Teams (left) and Microsoft PC Manager (right) up and running. It took me a minute to recollect the right approach, but it was dead easy to implement once those neurons had fired.

If this technique works for me, it can work for you, too. Enjoy!

Facebooklinkedin
Facebooklinkedin

Varying Office Visions for Up-to-date

Here’s an odd one: I find myself trying to reconcile varying office visions for up-to-date. I’ve got a Microsoft 365 Subscription on the one hand, and the Microsoft 365 Apps for enterprise – en-us on the other. Both currently stand at version 16.0.17425.20176. The update checker in the application version (top of lead-in graphic) says it’s up to date. WinGet, however, wants to update the apps version to 16.0.17531.20046, says it’s succeeding, but not getting anywhere. What to do: yikes!

Reconciling Varying Office Visions for Up-to-date

I blogged about a similar gotcha last month (Office Update Hiccup Is Easily Fixed: March 11). Alas, this time the same fix (Repair the office install, then try again) does NOT appear to resolve the issue. Indeed, even though I tell it to fix the apps version, the repair tool works on the subscription version anyway.

Despite some interesting discussion and suggestions at Microsoft.Answers, I can’t get any of their proposed “other fixes” to work, either. Sometimes, when updates get wonky, you just have to wait for MS to get the picture and provide fixes from their side. Methinks this could be one of those times. Indeed, I’ve spent enough time trying to handle this myself, so I’ve decided to wait for a next update and see if that fixes things.

Ain’t that just the way things go from time to time, here in Windows-World? Rhetorical question, I know, but my answer is “Yes!”

Facebooklinkedin
Facebooklinkedin

Busy Week Brings 9 WinGet Updates

It’s been a busy week, so I’ve been doing stuff more, and playing less with Windows. How do I know? I just ran WinGet on my production desktop and it tossed up a new personal high. That’s right: my busy week brings 9 WinGet updates to my Windows Terminal PowerShell session. You can see the intro part in the lead-in graphic. Wow!

When Busy Week Brings 9 WinGet Updates, Install Them

So that’s what I’m doing right now, as I write this blog post. The whole 9 items took about 2 minutes to complete. It brought 8 successes and one failure. Because I have numerous M365 components open right now, the M365 Apps for Enterprise install failed. That’s probably because I’m using a different subscription version tied to a different MSA. The one I’m using cheerfully reports itself all caught up.

It’s the one I’m NOT using that reports itself out-of-date (which is perfectly OK, because I’m not using it. Maybe I should remove it?) Isn’t it funny how using multiple MSAs in a Windows PC can occasionally make life interesting when you login with one such account, and use assets tied to another such account?

It’s All Part of Windows’ Inestimable Charms…

Learning where the eccentricities reside or potholes lie, and steering around them, gives me countless opportunities for learning and enjoyment when it comes to working with Windows. But less so than usual this week: I’m busy. In fact, I need to go do some paying work as soon as I’m done here. Cheers!

Facebooklinkedin
Facebooklinkedin

PowerShell Install Goes Cancelled to Abandoned

Here’s a good one. Take a look near the bottom of the lead-in graphic. It shows what happens at the end of a WinGet upgrade sequence with the PowerShell installer. But whereas that installer used to say “Installation cancelled” it now says “Installation abandoned.” Hence my assertion: PowerShell Install Goes Cancelled to Abandoned. In truth, this simply means the Windows Terminal window must be closed and re-opened for a new PowerShell version to take effect.

What PowerShell Install Goes Cancelled to Abandoned Means

Things get interesting when a program that’s currently running gets updated. Generally, for the code to take over from the old, the old must first stop. Then, the new must start up and run, so it can use all of its newly-minted capabilities and capacities. The “cancelled” and “abandoned” stuff is text for an error message that indicates the installer itself had to terminate in some kind of unexpected, unusual, or surprising way.

Look at what comes up when I close Windows Terminal, and then re-open it. Just for grins, I add WinGet list microsoft.PowerShell and another WinGet upgrade … check. The former shows the new version 7.4.2.0 is present (as does the lead-in prompt above it). The latter shows that a new WinGet check no longer reports that PowerShell needs an upgrade. Case closed!

PowerShell Install Goes Cancelled to Abandoned.follow-up

The new PowerShell version is running so it no longer generates an update notification. [Click image full full-size view.]

Facebooklinkedin
Facebooklinkedin

Reboot After NVIDIA 552.22 . . . Or Else!

I updated my production desktop with its RTX 3070 Ti GPU yesterday. When that process completed, the installer asked me if I wanted to restart now or wait until later. Because I was busy working, I elected later. Then in the usual crush of a frenetic afternoon, I completely forgot that reminder. It came back crashing down upon me this morning when I noticed that graphics performance was discernibly laggy. “Aha!” I thought to myself: “The reminder should have said ‘Reboot after NVIDIA 552.22 . . . or else suffer the consequences.”

Why Reboot After NVIDIA 552.22 Update?

That was the question I asked yesterday when the installer gave its reminder. I got my answer this morning when I noticed that graphics performance was visibly slower than usual. Turns out that while the 552.22 release notes don’t explicitly say “You must reboot upon installing,” it’s considered a best practice to do so when updating a big, complex driver like the one that drives a relatively modern GPU.

That’s probably why the installer asked me to reboot when it finished. I got my demonstration this morning, after forcing my system to sleep at 4-something AM this morning when I saw the monitor was on after wandering around on a predictable nocturnal mission.

Next Time, I’ll Do It When I Quit for the Day

Upon reflection, I now realize something obvious. When I got up from my PC in the evening, with no intent to return until the next morning, that would’ve been the ideal time to reboot. As it is, I had to wait around 90 seconds, all told, for the machine to shut down, restart and reboot to the desktop. Tolerable, but not the smartest way to take the NVIDIA installer’s apt advice.

Facebooklinkedin
Facebooklinkedin