Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 10, Windows 11

Teams Versions Running Side-by-Side

April 12, 2024 Ed Tittel Leave a comment

Gosh, it gets confusing sometimes. But it could be mostly a Windows 10 vs Windows 11 thing. On Windows 10 I find myself with multiple Teams versions running side-by-side. That is: Teams (work or school) vs. Teams Classic. The lead-in graphic shows their taskbar icons serious magnified in that order (Modern: left; Classic: right). It’s interesting and a little vexing from time to time. Fortunately, MS will be retiring Teams Classic sometime later this year (no earlier than July 1, 2024 says Copilot).

Issues with Teams Versions Running Side-by-Side

I know I’m in the minority but I don’t have a current, actively administered MSA that’s tied to an AD, Azure AD, or Entra ID based environment. These are the MSAs that work best and most reliably with the new version of Teams (see about info from my ThinkPad P16 Mobile Workstation, running production Windows 11).

The latest version from my Windows 11 production PC (Build 22635.3430)

Here’s what Teams Classic tells me about itself (through an unusually tortuous path to get to its “About” info).

The latest Classic Teams from Windows 10 (Build 19045.4291)

I sometimes have trouble using the new Teams version as an app, though it does work consistently and reliably on the Web. But too often — especially in view of impending retirement — Teams Classic wants to run when I really want to use the new version. MS says the Classic version is supposed to uninstall automatically after switching over to the new version. So far, it’s not going anywhere…

I have to pay close attention to the icons to see which one I’m using at any given moment. Thus I’ve learned to distinguish the white background and blue symbol for new versus the blue background and white “T” for classic as a quick differentiator. Man, will I be glad when classic Teams finally retires into obscurity. But hey, that’s the way things go here in Windows-World from time to time where more versions of Teams may not be better but are seemingly inescapable in Windows 10. Sigh.

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

Interesting v0.80.x PowerToys Puzzle

April 11, 2024 Ed Tittel Leave a comment

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!

Insider stuff, Recent Activity, WED Blog, Windows Update

22635.3430 Post-Reboot Black Screen Fix

April 10, 2024 Ed Tittel Leave a comment

Here’s an interesting item. Yesterday was Patch Tuesday for April. As per normal due diligence, I updated my various Windows 10 and 11 PCs. When I tried to remote into the production PC (ThinkPad P16 Gen1 Mobile Workstation) it showed me a black screen. Fortunately, I was able to come up with this 22635.3430 post-reboot black screen fix: Ctrl+Alt+Esc launched Task Manager. Then I was able to run Explorer.exe. After that, the desktop and all came up normally. Weird!

After the 22635.3430 Post-Reboot Black Screen Fix…

The system seems to be working properly. Nor is reliability monitor showing an error in its output for today. Whatever caused this strange pause in screen output during startup seems to have been benign (no errors) and purely transitory (I can’t make the system do it again).

After I did get to the desktop I installed a handful of winget updates, plus Intel DSA updates for Bluetooth, Wi-Fi and Iris Xe. This made another reboot mandatory. After that second reboot, all worked as it should have. So whatever caused my initial black screen was apparently a one-time hiccup.

The DISM /cleanup-image Report

I try to run dism /cleanup-image /analyzecomponentstore any time I install a CU. This time it quite startlingly shows 16 (!) reclaimable packages. Based on recent experience I’m guessing 13 of them are bogus (that’s a recurring number). Check it out!

What’s more the cleanup fails with error 6824 “another transaction is depending on the fact that this property will not change.” I’ve learned this means it’s time for a repair install based on recent experience.

Methinks something went awry with the latest CU KB5036992. I wonder how many others will report similar difficulties. In the meantime, I’m off to fix this, and move on. This time, I will have to use UUPDump.net, too. Sigh. The new way in Canary and Dev versions “Fix problems using Windows Update” is ever so much easier…

Note Added +3Hrs: IPRI Does It!

An indeed, though it takes quite a while to work through all the steps, building an ISO for 22635.3430 from UUPDump.net, mounting same, and running install from setup.exe gets rid of the high count for reclaimable packages (including “the bogus 13”). Here’s what I get from
dism /online /cleanup-image /analyzecomponentstore
after in-place repair install and its final reboot:

After the IPRI, reclaimables drops to zero.
[Click image for full-size view.]

Fixed! Now I need to figure out how to report this on Feedback Hub.

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

Recent Windows 10 Uncommonly Reliable

April 9, 2024 Ed Tittel Leave a comment

It’s my habit to drop in on the built-in Reliability Monitor tool in Windows from time to time. That gives me a rough and ready read on how well — or badly — the focus system is doing. I usually launch this tool by typing “Reli” into the search box, but you can launch it from the Run box or the command line by typing perfmon /rel. If you examine recent history from my production PC, it should be obvious why I say “Recent Windows 10 uncommonly reliable.” In other words, nothing to see here, folks. That’s good!

Fingers Crossed: Recent Windows 10 Uncommonly Reliable

Noticing that things are going smoothly is one thing. Talking about it — and risking some kind of jinx — is entirely another. So I’m tempting fate here, but I must also observe that:

I actively run the target system at least 9 hours a day (weekdays) and at least 6 hours on off days
I’m not hesitant about installing or changing stuff around as I’m researching software, tools, scripting, and OS configurations
I take a complete image backup at 9 AM every morning (7 days a week) so I’m always prepared to restore same should I shoot myself (or my PC) in the foot
It’s been a busy 18 days since my last critical error on March 28. I replaced the CyberPower UPS software that day because the old version kept crashing. The replacement has been quiet since.

Gosh, it’s nice to see my trusty old (closing in on 8 years: i7-6700 Skylake, Z170 mobo, 32 GB RAM, NVIDIA RTX 3070Ti GPU) desktop still chugging along so well. I know I’ll need to replace it soon, but I feel little pressure or need to do so immediately, in the face of these recent Relimon results. Jinx factor aside, that is…

Alas, as I know only too well, this could change in a moment. Good thing I’ve got a 2021 vintage B550 mobo with 5800X Ryzen CPU, 64 GB RAM, and so forth, already put together and ready to drop in should the need arise. But I still don’t feel a pressing need to migrate just yet. Stay tuned…that will no doubt change!

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

MS Store 22043 Speeds Things Up

April 8, 2024 Ed Tittel Leave a comment

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.

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

Dropbox Drops Gentle Reminder: RTFM

April 5, 2024 Ed Tittel 2 Comments

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…

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

Beta Channel Sign-up Spawns Bogus Reclaimables

April 4, 2024 Ed Tittel Leave a comment

“Hey, wait a minute,” I thought to myself, “I’ve been here before.” Indeed I reported in June 2023 about “13 spurious reclaimables” in a different Windows 11 installation. This time, the same thing showed up when I switched my Lenovo ThinkPad X1 Extreme over from production Windows 11 (Build 22635.2274) to the latest Beta Channel release (Build 22635.3420). No sooner did I run dism /online /cleanup-images /startcomponentcleanup than it threw the error shown in the lead-in graphic. What you can’t see is that my beta channel sign-up spawns bogus reclaimables — 13 of them, to be more exact. Yikes!

Fixing Beta Channel Sign-up Spawns Bogus Reclaimables

For this version of Windows 11, I had a trick up my sleeve. This build includes the ability to repair a “hinky” Windows installation by repair installing the current version (aka “upgrade repair install” or “in-place upgrade repair install” in the can familiar to readers of TenForums and ElevenForum tutorials and advice).

This
Invoking this option downloads the files for the running Windows version and re-installs the OS, using files from WU instead of local copies to try to fix things. In my case it worked. You can see the successful outcome in the next screencap, which shows zero bogus reclaimables in either of the two dism /online /cleanup-image
/analyzecomponentstore entries it shows. Good-oh!

To me, this proves the value and convenience of this new Windows 11 facility. Previously I’d have had to visit UUPdump.net, create an ISO script, then download all this stuff myself. Now, Windows does it on its own automatically. I think it’s great, and it fixed my problem, too.

The last time I ran into this problem I had to perform an in-place upgrade repair install to clear out the bogus reclaimables, too. If you ever find yourself in this boat, be aware that this technique has fixed this problem for me every time it’s happened on one of my PCs. Hopefully, it can do the same for yours.

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

WingetUI Announces UnigetUI Name Change

April 3, 2024 Ed Tittel Leave a comment

Though you can use it nicely with the Windows Package Manager, aka WinGet, WingetUI also works with other package managers. As you can see on its GitHub page, WingetUI also works with Scoop, Chocolatey, Pip, Npm, .NET Tool and the PowerShell Gallery. That’s a whole heap of package managers, and helps to explain why WingetUI announces UnigetUI name change in the app right now (see the lead-in graphic for same).

How WingetUI Announces UnigetUI Name Change

When I fired up WingetUI yesterday — for the first time in a couple of weeks, I cheerfully confess — the lead-in graphic popped up on my upstairs Windows 11 test PC (Asrock B550 mobo, Ryzen 5800 CPU, 64 GB RAM, Nvidia 1070TX GPU, etc.). In that little explainer, Marti Climent makes it clear that while WingetUI was initially designed to work only with Winget, it now covers numerous other package managers as well. Hence, the name change.

Of those other package managers, I’ve messed with Scoop and Chocolately. I’ve also turned to PowerShell Gallery on many occasions (though I’d call it a package repository more than a package manager, even though WingetUI/UnigetUI has worked with it for some while now).

WinGet CLI vs. WingetUI/UnigetUI

When I first discovered WingetUI I found it compelling and interesting because I was still learning the intricacies of WinGet commands and their sometimes convoluted syntax. But these days, I’m pretty darn comfortable with WinGet. Thus, I don’t find myself using WingetUI as much as I once did. Nevertheless, it’s a worthwhile tool that’s worth getting to know.

Indeed, I wrote a story about WingetUI for TekkiGurus last August (part of a 4-part Winget series). If you’re curious to learn more about either or both of these topics (Winget and WingetUI/UnigetUI) be sure to check them out. [Note: you’ll find links to the other 3 elements of the WinGet series if you visit the WingetUI story linked above.] Cheers!

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

Windows 11 Insider Preview Channel Switching

April 1, 2024 Ed Tittel 1 Comment

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:

The Update Stack Package that makes the Insider Preview installable
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!

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

Digesting WinGet Updates Gets Interesting

March 29, 2024 Ed Tittel Leave a comment

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…

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!