All posts by Ed Tittel

Full-time freelance writer, researcher and occasional expert witness, I specialize in Windows operating systems, information security, markup languages, and Web development tools and environments. I blog for numerous Websites, still write (or revise) the occasional book, and write lots of articles, white papers, tech briefs, and so forth.

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.


Beta Channel Rollback Follies

Found myself in an interesting pickle after running an in-place repair install on the 2018 vintage X380 Yoga for Build 22635.3495. Before the repair, DISM . . .  /AnalyzeComponentStore was showing me bogus reclaimable packages (see lead-in graphic). After the repair install, those bogus packages were gone — but alas, so were my start menu and task bar icons. Thus, I found myself engaged in Beta Channel rollback follies as I returned to the earlier status quo.

Before Beta Channel Rollback Follies, Some Flailing Around

Before I went to System > Recovery > Go Back to return to the previous status quo, I tried a bunch of repairs on the affected PC. None of the traditional usual suspects gave up the goods:

  1. Turned off Start 11v2 and went back to default Start menu
  2. Tried jacking around with Start11v2 settings galore
  3. Ran explorer.exe from Run box/Task Manager run

Whatever I tried, I was stuck with an invisible Start menu and no visible Taskbar icons. In the end it proved to be more trouble to run Windows without easy menu access than to put up with those bogus reclaimable packages.

Follies, Enumerated and Excoriated

Along the way back to where I started, I had a few bumps in the road. Because I typically run my test PCs through an RDP window on my main desktop, I had to remember “Oh yeah, you have to run Recovery options from the physical desktop.” I also stumbled around numerous Start11 menu settings that didn’t work as they’re supposed to — simply because the underlying Start menu was itself out of order.

Once I realized local repairs weren’t getting me anywhere, I knew enough to say, “Time to roll back.” I’ll stand pat on my current situation until MS comes out with a new Beta update (it usually happens once every week or two). Then, I’ll try again. Hopefully the next one will work properly and not show a bunch of spurious reclaimable packages, either. We’ll see…

A Terrible Trade-Off

Normally, running an in-place repair install results in a Windows image that’s pristine and works well. This is the first time I can ever recall that such a repair took a mildly bollixed image and left it unable to work properly after it was applied. As I’ve been thinking about what this might mean, I’m pondering a clean install on this test PC as an alternative to waiting for the next Beta Channel release. It will probably depend on how much free time I have this week. Stay tuned! I’ll keep reporting on this one…


PowerToys Puzzle Locks Together

Last week I blogged about how two quick back-to-back Powertoys releases seemed  to have left WinGet one release behind. No more! What I described as an “interesting PowerToys Puzzle” was indeed a function of lagging manifest updates. This morning,that former PowerToys puzzle locks together as you see WinGet update it from v0.80.0 to the current v0.80.1 in the lead-in graphic.

After PowerToys Puzzle Locks Together, WinGet Gets It Right

If you look at the top block of text in the lead graphic, you’ll see WinGet  recognizes the PowerToys version 0.80.0 needs an update to version 0.80.1. And indeed, that’s exactly what WinGet does in the center block of text just below the list of possible/pending updates that WinGet finds.

I did get a reply to the afore-linked April 11 blog tweet from WinGet team lead Demitirus Nelon. As I had guessed there was a lag between the second release and the WinGet manifest definitions. And it was apparently a completely routine fix, too.

So now, when the “What’s new” document shows v0.80.1 in its lead paragraph that actually agrees with the version that’s running on the target PC. Ain’t it great when things work the way they should? Three cheers for the PowerToys and WinGet teams for working quickly and accurately to fix this sooner rather than later.

I continue to be impressed with the dispatch and dedication of these folks. All I can say is “Keep up the good work!” I’m enjoying being part of the process.


Teams Versions Running Side-by-Side

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

Teams Versions Running Side-by-Side.about-new

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.


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!



22635.3430 Post-Reboot Black Screen Fix

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, 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, 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:

22635.3430 Post-Reboot Black Screen Fix.IPRI

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.


Recent Windows 10 Uncommonly Reliable

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!


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.


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…


Beta Channel Sign-up Spawns Bogus Reclaimables

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

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