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

Yesterday, I was bopping along and working away. Somewhere after lunch I noticed my D: drive had gone missing. I’ve been working feverishly to try to resuscitate that volume, but it ain’t coming back. Good thing I back it up frequently. I just restored the folders I care about most from that backup (and know where to find more, if I need them). So now, it’s time to say: Bye bye Seagate STL1000LM014.

Impacts from Bye Bye Seagate ST1000LM014

A bit of surprise and upset was my first reaction. But then, I looked at the manufacture date: 2014. Hmmm … let’s see … that’s 8-9 years ago. So, actually, not too surprising. I spent a couple of hours trying to recover the drive. But it won’t read in Windows for more than a minute or two before it falls over and throws a “failed USB device” error. So, I’m retiring this drive from service. I wasn’t able to recover its contents or restore it to working condition using Disk Management, MiniTool Partition Wizard, or SeaTools. That means it’s time for it to go.

It’s already been replaced with a different 2.5″ drive. It was mounted in a pop-out drive cage, which made it easy to remove the dead drive and drop in a live replacement. This time around, I’m going with a Seagate ST2000LX001FireCuda 2TB model, manufactured in 2020 or thereabouts. It should last for a while yet (at least 5 more years if the previous iteration is any guide). I think I’ll be OK.

Thank God for Good Backup!

I’m so glad I made the old D: drive part of my daily backup routine. I didn’t lose more than a day’s work. Now, I have to clean up the backup definition and make sure I’m still covered when the next drive fails. As they often say here in Windows-World: it’s always something!

I can tell the end is near — for my Microsoft Wireless Mobile Mouse 3500, that is. In this case, a flaky switch prompts mouse hunt for a replacement. What’s going on? Sometimes, when I click the mouse nothing happens. Sometimes, when I want to left-click once, it clicks twice — and even more annoyingly, vice-versa. Alas, this means the left-side contact switch is starting to fail. I’ve ridden enough meese into the dirt to recognize that this device is at end-of-life.

When Flaky Switch Prompts Mouse Hunt, Amazon Calls…

I have to laugh. It’s going to cost me a whole whopping US$12 to replace this unit. I always buy two, in fact, so I’ll have a spare if something goes wrong with the primary. I blush to confess, therefore, that when the previous primary went south and I fired up the secondary — the one I’m using now — I neglected to order an immediate replacement. That’s why I need to order two today. Just ordered!

I’m a great believer in keeping spares around — for everything. Indeed, if this current mouse dies before its replacement shows up, I’ve got a couple of Bluetooth meese (and corresponding USB3 dongles for my desktop) that I can use in the meantime. Ditto for network interfaces, removable storage, GbE cables and switches, keyboards and more. In my experience the only spare you really, really need is the one you forgot to order when the predecessor failed.

So far, things here at Chez Tittel are OK. As a Prime member, Amazon will get me both replacements tomorrow. I’m not worried. But it’s always good to stay on top of these things.

Cheers!

Note Added March 30 (Morning)

Amazon came through last night after I’d left home for my Wednesday evening pool league. The Boss left them sitting out on the kitchen island for me, so I saw them as soon as I walked into the house. It’s hard to overstate the satisfaction that near-instant gratification of one’s technology needs can deliver. I’ve already got one installed on my production PC. And now I have a ready spare as well. Good-oh!