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…

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!

Here’s an odd an ind interesting situation. After applying the CU that took the PC to the most current Beta Channel build, it reported an astounding 16 packages amenable to cleanup. After running DISM …/startcomponentcleanup, that selfsame PC running Build 22631.1900 shows 13 spurious reclaimables.

Why do I claim those reclaimable packages are spurious? Because running and re-running the same DISM command (which normally removes them all):

(a) reports successful completion
(b) leaves the number of reclaimable packages unchanged (13)

I’ve seen this happen on some Insider Previews in the past, as far back as Windows 8.x. But never with such a high number of packages — indeed, it’s “lucky 13.” WTF?!

If Build 22631.1900 Shows 13 Spurious Reclaimables, Then?

I’ve reported this situation to Feedback Hub along with screencaps to show what DISM reports. But otherwise, there’s not much a mere user — even an Insider MVP like myself — can do about this kind of problem. If the machine were showing signs of instability, odd behavior, or reduced performance I’d try an in-place repair install. I’d follow that up with a clean install if such problems persisted.

But since this seems to be purely an artifact from inside DISM that doesn’t affect the machine’s overall behavior or capability, I’ll leave it alone for the time being. If MS responds to my feedback, I’ll take whatever advice they dispense. Otherwise, I’ll wait for the next Beta Channel release with hopes that such an upgrade will clear this strange and weirdly high count of non-existent reclaimable packages.

Stay tuned: I’ll report back in after the next CU or new Build. I’m betting this problem will disappear once the “next thing” gets installed. We’ll see!

Minor Build Number Goes to 1906 (June 23)

Yesterday, CU KB5027311 got applied, as did an Update Stack Package. No change to the reclaimables count, nor did a cleanup attempt with /startcomponentcleanup have any effect. I’m guessing this won’t change until the next major version increments through an upgrade of some kind. Let’s see…

Note Added January 20, 2024

With the installation of Build 22635.3066 (23H2 Beta Channel Insider Preview), the “spurious 13” have vanished from DISM’s notice. The announcement says nothing about any relevant changes, and  the one for the base level release for this feature upgrade says only “a handful of fixes to improve overall reliability.” Somewhere, somehow, though this finally got fixed. Go figure.

Hmmmm. About 18 months ago, I blogged about a source of regular crashes on my Windows 10 production PC. Entitled “Chronic COM Surrogate Windows 10 Failures” it goes into possible causes of and fixes for APPCRASH errors relates to the Windows COM Surrogate. As you can see in the Reliability Monitor output at the head of this story, my Windows 10 COM Surrogate errors continue, sometimes multiple times in a day. Sigh.

If Windows 10 COM Surrogate Errors Continue, Then…?

I’ve already tried all of the fixes described in the earlier item and the errors continue. My current error history goes back to May 6, and the COM Surrogate error is mentioned in over half the total error reports involved (5 of 7 items). As I look around online, I see I’m not alone in this situation. It also shows up on most, but not all, of my Windows 11 PCs (of which I currently have 11 at my fingertips).

This feels more like a “feature” even if it is manifestly an “APPCRASH” event. Thankfully, it doesn’t seem to impact system stability, reliability or performance. Sometimes, things like this just pop up in Windows. This one is interesting and mildly vexing, but overall doesn’t seem to impair the user experience.

Feedback Hub Search Results

As I search Feedback Hub on some combination of COM Surrogate, APPCRASH, MoAppHang, and so forth, I see that PowerToys sometimes enters the picture, sometimes not. The nature of the error appears to depend on whether it emerges from an app (usually on the PowerToys components) or an executable (usually DllHost.exe).

But it looks like this issue hasn’t gone away since I dug into it a while back. And based on its common presence on Windows 10 and 11 PCs alike (across production, preview, beta, dev and canary channels as well) it looks like something more constant than intermittent. While I hope MS does fix it sometime (sooner would be better than later), I guess I can live with it while they’re searching for the right “round tuit.”