Category Archives: Updates

Interesting v0.80.x PowerToys Puzzle

I’ve just stumbled upon — and confirmed — and interesting v0.80.x PowerToys puzzle. Given that every picture tells a story, my lead-in graphic attempts to show what’s going on here. Let me explain, in three sections:

1. Top white text shows the info that pops up after Winget upgrades PowerToys to Version 0.80.0. Notice it reads “Release v0.80.1”.

2. Winget clearly shows it’s upgrading PowerToys to version 0.80.0 in the black text section in the middle.

3. Opening settings in that upgraded version of PowerToys, it self-reports as v0.80.0, and offers the “Install now” button to upgrade the program to v0.80.1. Not coincidentally, that install and upgrade actually work, and result in  a self-report of v0.80.1.

Note: you may have to show the graphic in its own browser tab or window to see the whole thing. Some important stuff is on the bottom edge (v.0.80.1 update notification and install button).

Interesting v0.80.x PowerToys Puzzle Gets Cracked

The way I see it, there are two possibilities here, and Ockham’s razor leans heavily toward one of them. First, it’s possible that winget is actually installing version 0.80.1 but misreporting same. I doubt it. My best guess is the second one, which is that v0.80.0 is showing the documentation for v0.80.1 when it should be showing a downrev version.

I think I just confirmed this because I did click the “Install now” button in PowerToys > Settings. It ran a tool called “PowerToys (Preview) x64 Setup” complete with progress bar.

And when it was finished it showed me the same “What’s new” document shown above, also labeled Release v.0.80.1. What’s different this time is that PowerToys > Settings > General now self-reports as follows:

Seems pretty conclusive to me. I’m guessing that the development team hasn’t yet updated their manifests for WinGet to switch things over from v0.80.0 to v0.80.1. At the same time the new “What’s new” has probably pushed out the old one, so it’s showing even on the v0.80.0 version. Go figure!

 

Facebooklinkedin
Facebooklinkedin

MS Store 22043 Speeds Things Up

I just read online that MS is pushing a new and faster version of its Microsoft Store out through the Insider Preview hierarchy. Figuring out which version I was running on my Canary Channel test PCs showed me that (a) I was running the new version, and (b) that indeed, MS Store 22043 speeds things up notably. Good stuff. The lead-in graphic shows the version number after the app restarted itself following that upgrade.

If MS Store 22043 Speeds Things Up, Then What?

On both of my Canary Channel test PCs (Lenovo Thinkpads: X12 Hybrid Tablet/11th Gen i7 and X380 Yoga/8th Gen i7) , the store was uniformly quicker than before the upgrade. Search times were shorter, update downloads and installs quicker, and navigating around the UI snappier. It still takes a while to download app info in the Library view (but not as long a while as before).

There’s even a new “What’s new…” page that explains new features and improvements in the MS Store, to wit:


Interesting stuff! Thanks to Sergey Tkachenko over at WinAero, whose MS Store story this morning clued me into this new regime.

Facebooklinkedin
Facebooklinkedin

Dropbox Drops Gentle Reminder: RTFM

I have to laugh. I’ve been trying to get a beta version of Dropbox installed on my Windows 10 production desktop this morning. Trying, and failing, with nothing to show in Reliability Monitor, either. Then I decided to read the whole article about the new beta, which appeared on MSPowerUser on April 1 (no joke, alas). In a manner of speaking, Dropbox drops gentle reminder RTFM (read the fabulous manual).

Here’s what it says:

Note: Windows 10 users will need to uninstall earlier Dropbox desktop applications before installing the updated version to ensure optimal performance.

Guess what I didn’t do before trying the install? You got it in one: I did not first remove the old version before overlaying the new one. Sigh.

Heeding When Dropbox Drops Gentle Reminder: RTFM

Creature of habit that I am, I used winget uninstall Dropbox.Dropbox to remove the old version. Worked like a charm. Then I re-tried the Dropbox 196.3.6883 Offline Installer.x64.exe installer file. It too, then did its thing. And it took its sweet time, too.

But when all was said and done Dropbox came up just fine in Windows 10. It was smart enough to keep the old version’s login data, too, so I was able to get in and start working just like the old version. But by looking at the program’s about info I can see I’m running this latest (beta) version. Problem solved. Like I said: RTFM.

It never hurts to know precisely what you’re doing, before you start doing it. Otherwise, like me sometimes, you’ll have to figure it out as you lurch from one step to the next. Sigh again…

Facebooklinkedin
Facebooklinkedin

Windows 11 Insider Preview Channel Switching

OK, then: I HAD to do it. I read this morning that MS is releasing a redesign of the  All Apps aspect of the Start menu in the Beta Channel. Naturally, I kicked one of my production laptops upstairs to join the channel to see that change for myself. Along the way I got to remember (or relearn) what’s involved in Windows 11 Insider Preview channel switching. (Hint: no remote control needed.)

Getting Into Windows 11 Insider Preview Channel Switching

It’s been a while, so I had to go through the motions to remember them. First, I had to join that PC to the Insider Preview program. Then I had to select my Insider Preview channel — Beta, in this case. Then I had to restart the PC and run WU again. In fact, I had to do that twice (run WU, that is — only 1 restart required at that point). And finally, as you can see in the lead-in graphic:

  1. The Update Stack Package that makes the Insider Preview installable
  2. The actual Insider Preview package itself (Build 22635.3420)

Of course once all that stuff gets installed, I’ll reboot again and go through the post-GUI installer stuff. That’s what actually upgrades the OS from the current production version 22635.3374) to the aforementioned Beta build.  When all that’s done I can go look for the new Start menu All apps stuff. As is typical, this takes a while (I’m about 12 minutes into the process and “Installing” for the OS is at 35% complete right now. Thus, it could be another 20 minutes before it’s done.) In the meanwhile, I’m standing by… And indeed it took a total of about 26 minutes to go from start to desktop for that process.

What About All Apps?

It’s another one of those things where MS may still be testing internally only, or doing another of its gradual rollouts. Thus, you guessed it: I still get the left-justified all apps list on my freshly-upgraded test PC. I can’t say I’m surprised, but it’s always disappointing to go looking for something new only to see the “same old, same old.” Sigh.

Of course, I’ll keep checking back and see when the switchover happens. Stay tuned: I’ll keep you posted…

Note Added 1 Hour Later

As I continue catching up with Windows news, I see over at NeoWin that a vivetool hack is required to enable the All apps grid in the latest beta version. I don’t do that on my beta machines to keep them in line with MS releases (it’s an MVP thing). So I guess I’ll have to wait awhile. Rumor has it this might hit “for real” on Patch Tuesday (April 9). We’ll see!

Facebooklinkedin
Facebooklinkedin

Digesting WinGet Updates Gets Interesting

I just noticed something odd about my latest WinGet update cycle. It worked just fine but threw a “Failed in attempting to update the source: winget” error before proceeding. When I check version info on WinGet itself it shows version v1.7.10861. Running winget show Microsoft.AppInstaller (the app name for the environment that includes WinGet) it shows version v1.22.10861.0. When I attempt to update it comes back “No available upgrade found.” When I run another general update check, it says “No installed packages…” meaning “Nothing to see here!” This makes me thing that digesting WinGet updates gets interesting — some of the time, at least. Let me explain…

Digesting WinGet Updates Gets Interesting.store-info

Note App Installer got “Modified yesterday” (that’s an update)!

IMO Digesting WinGet Updates Gets Interesting

When I check the MS Store, I see that it updated App Installer just yesterday. This is the first time I’ve run Windows Terminal and Winget since that update. Methinks it may take an exit-restart maneuver after the update for the new stuff to take effect.

To test my theory, I fire off a new instance of Windows Terminal/PowerShell and run winget upgrade –all –include-unknown again. This time it repeats the “No installed package…” message. That lets me know things are all caught up. No mention of “Failed in attempting to update the source: winget,” either.

That may not prove my theory, but it certainly adds it a bit more credence. How did I figure this out? On my Windows 10 PC, I actually updated Microsoft.AppInstaller as part of the sequence that stated with “Failed in attempting to update the source: winget.” That got me to thinking that a winget self-update might temporarily throw off the access to its source. And, by golly, I think that may just explain what’s going on here. As I said before: it’s interesting!

 

Facebooklinkedin
Facebooklinkedin

Windows 10 Lockscreen Follies

OK, it may be another case of: gradual rollout, I’m on the tailing end. Or it may be something is misbehaving. I’m trying out the new Lock Screen behaviors in Windows 10 Build 19045.4239. I can see the weather bug, and I can turn on the “other lock screen apps” but none of them show up. Right now, I’m updating a VM on another PC so I can take screencaps to show what’s happening. Hence my assertion I’m engaging in Windows 10 lockscreen follies. Fun, actually!

What Windows 10 Lockscreen Follies Tell Me…

I’m a great believer in trying out and observing new stuff as it shows up in Windows. I’ve learned that I don’t understand things anywhere near as well when reading about them, as I do when installing or setting them up, then using them. There’s something about the actual experience that improves my apprehension and comprehension. Plus, I like to tinker with stuff (to the point where I’ll try to break things so I can learn how to fix them).

Once I confirmed I was indeed running 19045.4239 I started playing with the lock screen settings. Again, I can see the background coming from Spotbright, and the weather info. And again, I cannot see status from the other apps I’ve chosen for display. Homer Simpson moment hits: I bet they have to be RUNNING to show something. …goes off to try … doesn’t seem to help (nor does placing the open app window on my #1 screen, which also might be a factor).

Trailing Behind the Gradual Rollout…Again

Looks like I’ve got all the controls up and going, but they’re not doing anything. But about “more content” on the lockscreen, the announcement says “This feature might not be available to all users because it will roll out gradually.” Based on my nearly unbroken record in avoiding the front ranks during such times, I’m guessing it will make its way to my lockscreens later, rather than sooner!

Stay tuned, I’ll keep you posted. The Lord only knows why, but I’m starting to like the idea of a status-filled lockscreen…

 

 

Facebooklinkedin
Facebooklinkedin

Achieving Windows 11 Moment 5

I knew I had to have it, as soon as I read it was available. The “It” in this case is what many observers are calling “Moment 5” — the next step in the evolution and release of Windows 11. Thurrott says it’s supposed to be available as a “Week D Preview” from WU. But I had to visit the KB5035942 announcement, and follow its link to the Update Catalog to get myself a copy. I’m still only partway toward achieving Windows 11 Moment 5 right now, because the MSU is still busy getting the update installed.

Achieving Windows 11 Moment 5.msu-working

It takes a good while for this update to process…be patient!

Is Achieving Windows 11 Moment 5 Good?

The Microsoft Standalone Update (MSU) installer ticks along for several minutes as the install process grinds through its paces. I didn’t see a lot of heavy CPU activity (Thanks to the 8GadgetPack CPU Usage widget, I can always see what my processor is up to) while this was happening, either. A closer look via Task Manager showed the TiWorker.exe process consuming 1-2% of CPU and less for WmiPrivSrv.exe and TrustedInstaller.exe. Otherwise, it didn’t show much evidence of installer activity, either.

TLDR version: it takes forever while the MSU says “Copying packages to the Windows Update cache.” And a funny thing, too: I just checked one of my other production-level Windows 11 PCs (the Lenovo ThinkPad X1 Extreme) and it’s already been updated automatically, entirely on its own. It’s the source of the Winver output that leads off this story, in fact. That leads to an interesting question:

Why X1 Extreme and not P16?

The P16 machine I’m running the MSU on right now is also set to “Get the latest updates as soon as they’re available?” just as is the X1 Extreme. Yet the latter gets it on its own, while the former does not (nor does it see the update offered in WU, either). Methinks there may be some kind of device hold on this newer, more capable mobile workstation model (P16) to which the older laptop (X1 Extreme) is not subject.

So now, I’m waiting to see how it all turns out. And meanwhile, the MSU just keeps grinding away at copying packages. Stay tuned … I’ll report back when the wheels stop turning to tell you what happened.

Progress! The status window just changed to “The updates are being installed” with a progress bar for “Installing.” Perhaps it’s finally getting somewhere. Let’s see…

Now the mills of the Gods are back to grinding at their usual glacial pace. But it is indeed moving ahead, so fingers crossed for a successful conclusion, about 20 minutes into download and install. At 22 minutes in: success! See the next screencap for confirmation:

Time to restart, and let the OS patch itself. Nice to see the Catalog update at work, for a change.

Facebooklinkedin
Facebooklinkedin

MS Edge 122.0.2365.106 Winget Upgrade Puzzle

Here’s a good one, right from my Windows 10 desktop this morning. As per usual practice, I ran winget upgrade –all –include-unknown to see what updates might be available after the weekend.  I promptly ran into a Catch-22 as you can see in the lead-in screencap. I call it an MS Edge 1220.2365.106 Winget Upgrade puzzle, because the package manager finds an upgrade for Edge that I can’t figure out how to install. Let me explain…

What’s the MS Edge 122.0.2365.106 Winget Upgrade Puzzle?

In a nutshell, here’s what the lead-in graphic depicts (there’s more, as you will shortly see in the following list of items):

1. Winget reports that an upgrade for Edge from version 122.0.2635.92 to …106 (first three groups of digits stay the same) is available.

2. Winget upgrade –all –include-unknown fails because “install technology of the newer version is different…” I’ve definitely seen this before. Note the error message advises an uninstall/reinstall maneuver to fix things.

3.  Winget uninstall Microsoft.Edge fails with exit code 93

4. An attempt to force the uninstall fails with the same exit code

5. A visit to Settings > Apps > All installed apps offers no uninstall option for Edge. Indeed, it’s pretty well known in Windows circles that Edge is notoriously tricky to uninstall. See, for example. this github “Remove-MS-Edge” script…

When in Doubt, Report to the Winget Team…

I have to believe this is a slight hiccup on the Winget team’s part. From long experience in working with the program daily since it was introduced at the end of June, 2020, I know that (a) Catch-22s sometimes pop up and (b) they usually get fixed fairly soon after they appear. My best guess is that this particular instance will get handled in the next few days.

For my part, I’m sending a link to this blog post to Demitrius Nelon, the leader of the Winget team via Twitter. This usually provokes immediate and corrective action. Let’s see what happens…

Stay tuned! Note: FWIW, Windows 11 versions are not subject to this gotcha. AFAICT this is a Windows 10 thing only. I even tried a repair install for Edge through its “All installed apps” entry and that didn’t help, either.  Indeed, a version check on the 122.0.2365.92 version comes back to report “all’s well”:

Note Added March 26: Gone!

Edge is still running as version 122.0.2365.92. But Winget is no longer reporting that it needs to upgrade it to 122.0.2635.106. Indeed, Winget show Microsoft.Edge now reports the latter as the current version, in need of no upgrade at all. Thanks Demetrius and team: problem solved!

Facebooklinkedin
Facebooklinkedin

Failed Update Shows Increasing Winget Smarts

Here’s an interesting observation. Since its release in May 2020, built-in Microsoft packaging tool Winget has been a work in progress. I don’t mean this as a critique: it started out pretty good, and it’s kept on getting better and better. I was reminded of this yesterday when an update for my CyberPowerSystems UPS software failed. But that failed update shows increasing Winget smarts. You can see the whole trail of events in the lead-in graphic.

How Failed Update Shows Increasing Winget Smarts

You can see the error message about one-third the way down from the top as it reports:Installer failed with exit code: 1. But it’s the lines above that really show off Winget’s increasing smarts:

v.2.5.1 cannot be updated through the installation package. Please remove the old version of Personal first and then install v2.5.1

This remove-replace (reinstall) maneuver is a fairly frequent occurrence when using Winget to update Windows software. It’s usually the next thing one tries if an update/upgrade fails. What’s new here is that Winget itself explicitly recommends this strategy. Previously it might indicate a “change in installer technology” to make such recommendations. This seems like more general — and broadly applicable — advice. I like it!

Doing What Winget Says…

If you look at the bottom section of the lead-in graphic, you’ll see it did just that (right-click that image, and select something like “Open image in new tab” to see the whole thing). Using the package’s ID string for unambiguous identification, I first uninstall it, then I install it again (note that it picks up the desired version: v2.5.1). That works: good stuff!

Facebooklinkedin
Facebooklinkedin

Office Update Hiccup Is Easily Fixed

Last Friday, WingetUI informed me that Microsoft Office needed an update on my production PC. When I tried to update it, however, it failed inside the tool and running winget inside PowerShell. Then, it did nothing inside Outlook when I clicked Files > Account > Update Options > Update Now. Obviously, something was hinky about Office itself, or perhaps the update package. I got an error message that read “Installer failed with exit code: 4294967295.” Fortunately, this Office update hiccup is easily fixed.

How Office Update Hiccup Is Easily Fixed

As it happens, I wrote a story for ComputerWorld back in April 2021. It’s entitled “4 steps to repair Microsoft Office.” I only had to go to Step 1 “Run the Office Quick Repair tool.” You can see the steps to get there, and the Repair button to run it, in the following screencap:

Here’s how to get to the embedded repair info: Settings > Apps > Apps & features > click on Microsoft 365 Apps (for enterprise in my case, YMMV by version). If you click Quick Repair it uses local windows files from your PC. If that doesn’t work, you can try Online Repair and use files from the MS Office download page instead.

I didn’t have to, because the first try did the trick. After the repair completed the update ran without further difficulties. Darn! It’s nice when an easy repair succeeds. Read the rest of the CW story to see what other steps might be required if the Repair tools shown above don’t work. Things can get interesting in a hurry, so I’m just as glad they did not. As Sinatra famously sang “…nice and easy does it every time!”

 

 

Facebooklinkedin
Facebooklinkedin