Category Archives: Troubleshooting

Upcoming Windows Imperative: Get Help!

OK, then. Troubleshooters are on their way out of newer Windows versions. Instead a series of “Get Help” tools will replace that functionality. That’s the message I take from this February 2023 dated MS Support note entitled “Deprecation of Microsoft Support Diagnostic Tool (MSDT) and MSDT Troubleshooters. A closer look at the story is where I find this new and upcoming Windows imperative: Get Help! You can see it, too, in the lead-in graphic.

Identifying the Upcoming Windows Imperative: Get Help!

If you look at the “redirected” Troubleshooters list above, you’lll see that each one begins with the string “Open Get Help” tied to a related Windows facility, program, or device. Closer reading of this document also explains that the Microsoft Diagnostic Tool (MSDT) is to be retired. Also, numerous “legacy inbox troubleshooters” will be removed from the upcoming next release of Windows 11:

Connection to a Workplace using DirectAccess
Devices and Printers
Hardware and Devices
Incoming Connections
Internet Explorer Performance
Internet Explorer Safety
Search and Indexing
System Maintenance
Shared Folders
Windows Store Apps

Some of these removals make perfect sense — like those related to the now-obsolete Windows Explorer and HomeGroup facilities. Others are somewhat more mysterious — such as Devices and Printers, Hardware and Devices, Keyboard, Power, Search and Indexing and so forth.

The apparent timetable is to get through this transition by this time next year. Thus, I presume Windows 11 24H2 could be the release in which these changes probably manifest. Presumably, they’ll show up sooner in Canary and Dev channel Insider Previews, and then on down the chain from there as the release date approaches.

Relax: Older Versions Are Not Affected

Here’s an important verbatim quote from this Support Note which should calm any concerns about Windows 10 and current Windows 11 versions:

If you’re running Windows 11 version 22H2 and older, Windows 10, Windows 8.1, Windows 7 or any other earlier OS version, your device will not be affected by the MSDT Troubleshooter retirement. Earlier OS systems will continue to run the legacy inbox troubleshooters.

This definition, also quoted verbatim, should further clarify things:

…legacy inbox Windows Troubleshooters are built-in tools that, when launched, automatically diagnose and correct common problems for a variety of Windows features. MSDT Troubleshooters will be deprecated in the next Windows 11 release, with the date to be determined.

Here’s what I really find interesting about this. It will expose a pretty major fork in the road between the  next major Windows 11 release and the mostly-common code base that Windows 10 and 11 still share. I’ll be fascinated to learn about and understand what Get Help! really means in this context. Stay tuned…


Beta Build 22631 Loses Update Button

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.

Beta Build 22631 Loses Update Button.uso-fix

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!


Inconsequential Windows Errors: Remove or Ignore?

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.


Winget Version Numbering Hiccup

Here’s an odd, but interesting, Winget situation. While setting up the replacement Lenovo  ThinkPad P16 Mobile Workstation, I installed CrystalDiskMark (standard “free” version). As you can see in the lead-in graphic, the maker’s website gives it a version number of 8.0.4c. This causes an interesting winget version numbering hiccup, because its manifest contains numbers only (8.0.4) rather than the complete version designator (8.0.4c). This causes an error when running the “do-everything” winget command — namely:

winget upgrade --all --include-unknown

The upgrade command grinds along for a good long while — several minutes, in fact — before it fails with an unexpected error, like so:

Winget Version Numbering Hiccup:c-error

Apparently, the manifest points to a badly-formed or MIA URL, so the upgrade can’t proceed.

Overcoming Winget Version Numbering Hiccup

Attempts to specify an version number (8.0.4), along with an explicit ID (CrystalDewWorld.CrystalDiskMark) likewise fail to complete  (same error message). Then it gets more interesting:

Winget is happy to uninstall the 8.0.4c version, as long as I specify it explicitly.

But winget won’t install CrystalDiskMark, so the only option is to download and install the maker’s version — which doesn’t work with winget right now. I’m communicating this to the winget team (via Demitrius Nelon). Hopefully they’ll figure out a fix. I figure the version number mismatch between the manifest (8.0.4) and the maker’s actual number (8.0.4c) is what’s causing the issue. As soon as that gets resolved, I image things will start working as they oughter.

We’ll see!


Some Deletions Are Easier Than Others

Whoa Nelly! I just came off a Windows filesystem adventure. Apparently, the 2TB 2.5″ HDD used for peripheral storage on the Boss’s Dell SFF D7080 PC once served somebody as a system disk. That’s the only way I can explain how two System-owned folders named ProgramData (hidden, too) and Users popped up thereupon. Making them go away led to this post’s title — namely, some deletions are easier than others. Let me explain…

Why Some Deletions Are Easier Than Others

Part of the difficulty stems from Dell, and part from Windows. On the D7080 to get into WinRE from bootable media, you must first disable Secure Boot. This allowed me to boot from “Alternate Media” — in this case, the Macrium Reflect Rescue Media, from whence I ran its Command Prompt facility.

Part of the difficulty comes from Windows. It really, really wants to make it hard to delete System-owned folders like the ones on the Boss’s F: drive for very good reasons. Unwanted deletion could render programs (in the case of ProgramData) and perhaps even the OS (in the case of Users) unusable. Consequently, one must go to great lengths to remove such folders, even on disks no longer playing the system/boot role. Sigh.

Two Quick Secrets Solve the Command-Line Puzzle

To remove the two directories (and their plethora of sub-folders) I had to use this command syntax:

rmdir /s path-spec

where one spec was F:\ProgramData and the other F:\Users. To confirm the presence of the hidden F:\ProgramData; item, I first had to run this command, though:

dir /a:h

That shows items with a “hidden” attribute, along with those more easily viewed.

How I Got to the Finish Line

So first, I had to turn off Secure Boot. That required the following sequence of activities. I went into Start → Settings → Recovery; and clicked the “Restart now” button under the “Advanced Startup” heading. First reboot. From there I clicked Troubleshoot, then the UEFI Firmware Settings option. Second reboot, whereupon I went into the UEFI/BIOS and disabled “Secure Boot” under that self-same heading. Save the change, then third reboot.

Next, I plugged the Macrium Rescue Disk UFD into the D7080. I rebooted (4th time) into its embrace by starting once again with Start → Settings → Recovery; and clicked the “Restart now” button under the “Advanced Startup” heading. Inside the WinRE menu that serves as the lead-in graphic above, I picked “Use a device.” Next, I elected the Mushkin UFD in the alternate boot selections and booted into that environment (5th reboot). There, I ran the Command Prompt facility. Inside that facility I used the afore-described commands to find and delete the system-owned folders. Then I exited Command Prompt and the Macrium Rescue Disk environment. That led to the 6th reboot.

This took me back into Windows, where I used the System → Restore → etc. sequence again to get back into WinRE main menu. 7th reboot. To undo Secure boot, I had to once again pick UEFI Firmware Settings, then reboot again (8th), find the “Secure Boot” option and re-enable it. Save the settings, exit UEFI and reboot for the last time. NINE (9) reboots in all to delete a couple of folders. Sheesh!

But gosh, isn’t that just the way things sometimes go, here in Windows-World. Making the world safe for system-owned folders is hard work. So is making them disappear…


Send It Back: P16 Goes Home

I’ve been in a pickle since I returned from our family trip this weekend. My beloved and heavily-used Lenovo ThinkPad P16 Mobile Workstation got caught in a “doom loop.” When I asked the reviews team what to do about it, they asked for its return. When they said “Send it back,” P16 goes home to its maker. Now, let me explain what prompted this action.

Why Send It Back: P16 Goes Home

My “doom loop” was insidious because the machine wouldn’t restart. When I instructed it to do so through any and all means (see list), it would hang on the “spinning balls” labeled Restarting, and spin forever. Of course, that greatly limited my repair options, since I couldn’t get at repair stuff through the OS. Before I explain how I would’ve gotten over that hump, let me explain what I tried:

  1.  The Restart option via Start → Power button → Restart
  2. Various other equivalents via the command line (e.g. shutdown /r ...).
  3. Recovery capabilities via Start → Settings → System → Recovery → Advanced startup → “Restart now” button

I even made registry tweaks to turn off Fast Startup and performed an in-place upgrade repair install. None of this worked. I happened to mention this to a member of the reviews team who was working with another review unit I’d just returned to their North Carolina depot. He asked me to return the unit so they could understand what happened. So that’s what I did: I’m expecting a replacement to show up today.

What Would Have Been Next…

While the P16 wouldn’t restart, it would shut down. Thus, I would have shut down, then booted into the BIOS (strike the Enter key during the boot load phase and you still get into the UEFI/BIOS menus). Then, I would’ve attempted repairs from a repair disk of one kind or another (Macrium, Kyhi, DaRT, and more: I’ve got all of them accessible on my Ventoy USB-C NVMe enclosure). Failing repair, I’d have wiped the drive and done a clean reinstall of Windows 11. That pretty much always works.

Instead I’ll unpack a replacement unit later today and restore my most recent backup image from the old machine to the new. That should put me back where I was with minimal time and effort. Stay tuned: I’ll report back on those efforts next week.

Life is always interesting here in Windows-World. That goes double when you have a great group of people like the Lenovo reviews team backing you up!

Out with the Old, In with the New

The replacement unit showed up after lunch Friday (August 4). I didn’t get started on setup, app installs and customization until Saturday (August 5). I’ll be blogging about my adventures with the machine and its specs tomorrow (August 8) as a kind of auto-birthday present (my age will be a prime number greater than 67 and less than 73). TLDR version: great fun, lots of stuff to do, and some interesting nits to pick. However, the new unit restarts without any difficulties. Thanks again, Lenovo Reviews Team: you rock!!!


Reboot Cures MIA USB-C Port

Sometimes, I just don’t get it when Windows gets weird. This time, it’s one of my two Lenovo ThinkPad X380 Yoga laptops (i7-8650U, 16 GB RAM, 1 TB NVMe SSD; vintage 2018). I noticed my USB-C attached NVMe enclosure was MIA, Plugging and unplugging did no good, either. The drive worked fine in another, newer laptop (Lenovo ThinkPad P16 Mobile Workstation: 11th gen i7, 128GB RAM, 2×1 TB NVMe SSD). I soon figured out that a reboot cures MIA USB-C port on the X380. Bizarre!

Hold on: A Reboot Cures MIA USB-C Port

Because the drive worked right away in the other laptop, I was pretty sure the issue was with the USB-C port, not the drive. And indeed, when I rebooted the X380 Yoga the USB-C-attached NVMe enclosure once again showed up and worked at expected speeds (it only ran about half that rate when plugged into a USB 3.2 Type A port via conversion cable).

What the hey? I’m speculating, but my best guess is that when the X380 goes to sleep it loses track of — and connection with — the USB-C port. Works fine now, though… The lead-in graphic shows this as the E: drive with a 1TB SSD ensconced therein.

When in Doubt … Reboot

It never fails to amaze and amuse me that the old “three-fingered salute” (anybody else still remember CTRL-ALT-DEL?) still fixes so many Windows weirdnesses. At least, it’s just something momentary. To no surprise, the search string “X380 Yoga USB-C port disappears after sleep” auto-completes when I start typing the word “disappears.” That tells me my experience is not unique: Google knows about it, too. Go figure!

And that’s the way things go here in Windows-World. Hopefully, I’ll remember what to do the next time this happens…

Added 2Hrs Later: Confirmed!

I let the X380 go to sleep and when I woke it back up, once again the USB-C NVMe drive disappeared. After another reboot, it’s baaaack! I’d have to say this confirms my sleep-based hypothesis. OK, then…




Ongoing Build 22631.1972 Oddities

Hmmmm. Yesterday was “Update Tuesday.” As I made the update rounds on my small PC fleet, I noticed something odd as I was downloading updates for my Beta Channel test PC (a Lenovo X380 Yoga). It’s depicted in the lead-in graphic, and led to further, ongoing Build 22531.1972 oddities when all was said and done. Please, let me explain…

Working Through Ongoing Build 22631.1972 Oddities

First, take a look at the lead-in graphic. Hint: consternation hits at the bottom of the update list. Note the same update occurs twice, each with “Completed” status — namely KB5007651 (a Defender antimalware platform update). Weird!

Immediately after, it gets weirder. First, I rebooted once the updates completed (twice, just to be on the safe side). Then I ran DISM … /StartComponentCleanup. I observed the following outcome:

Ongoing Build 22631.1972 Oddities.dism-clean

Error 6824 “another …pending transaction” pops up. A first!
[Click image for full-sized view: this one’s hard to read.]

As usual, I went haring off to Google to see what was recommended. Heck, I even tried it out on Bing’s ChatGPT sidebar. Here’s what came back:

Alas, a second (and even a third) reboot didn’t clear the error, either. The same condition held upon repeated retries of the afore-cited DISM command — namely:

dism /online /cleanup-image /startcomponentcleanup

I’m thinking it’s time to try an in-place upgrade to repair this Windows installation. It should rebuild the component store which is likely to fix this issue and the strange ongoing presence of 13 spurious items therein in need of (impossible cleanup). I think I’ll visit UUPDump and build an image for 22631.1972. Hopefully, that will do the trick. Stay tuned!


Windows 11 Widgets Need Improved Stability

OK, then. I just happened to check Reliability Monitor (ReliMon) on one of my Windows 11 test PCs. I’d been using it as the platform to put Widgets through their paces late last week. If you look to the right-hand of the reliability graph, you’ll see it craters as I do so. In fact, between June 22 and 27 CoreWidgetProvider accounts for 9 of 11 MoAppCrash errors inside the Dev Home app over that 6-day period. Hence my assertion: Windows 11 Widgets Need Improved Stability.

Why Say: Windows 11 Widgets Need Improved Stability?

Simply put: that’s a LOT of crashing just for using Widgets through Dev Home. For the record MoAppCrash is shorthand for Mobile Application Crash, and goes to the coreclr.dll element in that app. Methinks MS Needs to check this out and figure out how to boost its uptime or resilience. AFAICT this comes from pinning Widgets to the Dev Home dashboard and letting them run. That should be a pretty non-controversial action, right?

That said, the full name of Dev Home right now is indeed “Dev Home (Preview).” That means it’s not fully cooked yet. So you knew there had to be something about it that might not be ready for prime time. What do you bet this is part of that in some way?

What to Do? What to Do?

I’ll be reporting this to Feedback Hub. If you see it on your PCs you should do likewise,  or upvote my item. If MS really wants to supplant Vista Gadgets with Widgets, looks like they’ve got some work to do!



Teams App vs. Application Update Conundrum

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 was most current, but I was still running 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 — 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.