Yesterday morning, I tried to remote into my Lenovo ThinkPad X12 Hybrid tablet. No go. I got the familiar error “Remote Desktop can’t find the computer…” Interestingly, when I went to restart that PC, nothing happened. Eventually I had to disconnect all cables, then hold the power button down for a full 60 seconds to force it to reboot. Then I remembered: I hadn’t touched the machine since the 25967 upgrade hit on Tuesday. That means the X12 Upgrade quit halfway through the process and didn’t come back up after the reboot.

If the X12 Upgrade Quit Halfway, Then What?

Poking around on the Lenovo website, I found an evocative forum post. It was entitled “Laptop suddenly shuts down, won’t turn on.” It confirmed something odd was up, and prevented the PC from restarting. And indeed, my approach (disconnecting all cables, holding down the power button for 60 seconds) is just what the forum rep recommended to the poster, too.

When all else fails, this is one way to get a Lenovo PC to restart normally. And sure enough, once the PC did get far enough along to tell me what it was doing, it showed the spinning circle and progress that goes along with finishing up an upgrade or update install.

Just for grins, I opened up Reliability Monitor on the X12. I found a shutdown error staring me in the face. The detail reads: “The previous system shutdown at 5:55:00 PM on 10/10/2023 was unexpected.” Last Tuesday, at the end of the working day, just when I wouldn’t notice that the X12 failed to come back from the pending reboot during the update process. Go figure!

There’s proof that the PC shutdown when it shouldn’t have.

Speculating on Causes…

This device is attached to a CalDigit TS4 hub for power, GbE, video and storage. I’m wondering if something about that kind of complex USB-C/Thunderbolt 4 connection might not complicate boot-up. OTOH, I’ve upgraded plenty of times before on the same overall rig without difficulty. That’s what keeps things interesting, here in Windows-World.

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
HomeGroup
Incoming Connections
Internet Explorer Performance
Internet Explorer Safety
Keyboard
Power
Search and Indexing
Speech
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…

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…

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…

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:

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!