The late, great Gerald Weinberg is one of my “tech heroes.” He wrote a lot of great books. My personal fave is The Secrets of Consulting. One of its many gems is called “Rudy’s Law of Rutabagas.” Essentially, it boils down to “As soon as you solve one problem, another one pops up to take its place.” As I maneuvered — and maneuvered some more — yesterday so that my X12 Hybrid gets 25309 clean install, Rudy’s Law was ever on my mind. Let me explain…

Why X12 Hybrid Gets 25309 Clean Install

First, a bit of background. As I tried to upgrade to Build 25309 last week on the X12, I hit all kinds of snags. It kept failing at the FIRST_BOOT stage. Ironically this refers to the first reboot after the reboot that transitions from the GUI-based portion of a Windows install (where the running OS is in control) to the post-GUI portion (where the WinPE for the newly-emerging OS is in control).

I kept getting error codes 0XC1900101 and 0XC1900131 while attempting WU-based updates. After building an ISO for 25309 at UUPdump.net, I elicited a more informative error message after that installer failed during an in-place repair install, as part of its post-fail reporting (see lead-in graphic). This usually means there’s a device driver conflict or incompatibility of some kind. But I’ll be darned if I could figure out what it was.

All in all, I attempted to install 25309 four times on the X12. And when 25314 appeared yesterday, I tried that one, too via WU. None succeeded. Nor could I get any tips or tricks for working around this from the MS Insider Team after reporting my woes to Feedback Hub.

The Upgrade of Last Resort: Clean Install

When all upgrade attempts fail, you can always wipe the system disk clean on a Windows PC, then overwrite everything with a fresh, clean install of your chosen OS version. Most people (including me) shy away from this technique because it requires re-installing all applications and apps added to the PC since it first booted up, and re-adjusting all preferences and settings. That takes TIME, and lots of it. But it is something of a silver bullet for fixing munged Windows installations. It seems pretty clear that’s what I had, so in this case a clean install made good sense.

Remembering Rudy’s Law…

I ran into plenty of obstacles along the way to achieving a clean install yesterday afternoon. Let me simply list them briefly along with my response(s):

• Couldn’t get the X12 to boot to a USB drive. Response: turn off BitLocker, suspend Secure boot.
• Couldn’t provide the proper BitLocker key to enable boot process to complete. Response: boot into running image, use Control Panel Bitlocker utility to print BitLocker keys.
• Couldn’t get the X12 to boot to the USB NVMe drive enclosure with Ventoy and the 25309 image. Response: use RUFUS to build a bootable USB flash drive with that image installed.

Eventually after 3.5 hours or so of kibitzing around, I got to setup.exe on the USB flash drive, and fired off installation. After all that prep work, the process took less than half an hour to get me to a desktop. But those various gyrations (bulleted above) reminded me that indeed, solving any one problem inevitably leads to solving the next one.

Where’s the X12 Install Now?

Because a new Canary channel build — namely 25314 — emerged while I was still grappling with 25309, I had upgrades to apply once 25309 was clean-installed. I fired off the reboot for the next iteration last night before heading off to bed, with fingers crossed for its success. When I hit my desk this morning, 25314 was ready to run on the Lenovo ThinkPad X12 Hybrid Tablet. What a relief!

As proof of workability, the feature upgrade to 25314 succeeds. Good-oh!

Now the REAL Fun Begins…

Over the next days (and probably weeks) I’ll find myself putting the X12 together again. I’ve already set up Remote Desktop. I can see I need some changes to Power Options, File Explorer options, and more. Plenty of apps and applications to install, too. That’s what always follows in the wake of a clean install. Here we go!

My first job out of college, I worked as a studio engineer in recorded sound. I remember one of the senior engineers telling me one day: “The hardest problems to diagnose are the intermittent ones.” Over the years, I’ve seen that revealed as a terse understatement. I was reminded of that principle last week when my $400-plus Thunderbolt 4 dock quit working. As I dickered with CalDigit tech support to try to get an RMA number for that momentarily dead device, it came back to life. Because of this Short-Lived CalDigit TS4 hiatus I never did get an RMA; instead it’s back at work. Sigh.

When Short-Lived CalDigit TS4 Hiatus Ends, Then What?

As you can see from the front and back views in the lead-in graphic, the CalDigit Thunderbolt 4 Station (aka TS4) is a port-laden beast of a dock. I purchased it last August because I wanted to test this top-of-the-line Thunderbolt 4 (TB4) unit against other TB4 docks from Belkin and Lenovo. Until last week, it has behaved flawlessly, and worked well under every test of its capabilities I could devise.

Initially, I explained my symptoms to CalDigit tech support: no power light, no DC pass-through to power plugged-in devices, no appearance in Intel’s Thunderbolt Control Center (TCC) app when plugged in (and ditto for inserted TB4 or USB4 devices, either). They didn’t seem to want to believe me. So, under their guidance, I tried the device by itself (no power light, TS4 box didn’t warm up as it previously did). Next, I tried the device with their TS4 cable into a laptop. Still nothing. I reported those results and asked again for an RMA.

The Waiting Is the Hardest Part…

While waiting for a reply from Tech Support, I unplugged the device and left it completely alone and unused. When I got a response from CalDigit a couple of days later, they had me try one more thing: hook it up to a different laptop, in a simple configuration (TB4 from CalDigit to laptop for power and connectivity, GbE and USB-C for a storage device on the dock). To my utter astonishment it worked! And it kept working, even when I switched it back to the original laptop.

As far as what happened, nobody knows. Now the power indicator works. Pass-through power has kept my Lenovo ThinkPad X12 Hybrid Tablet humming for the past 4 days without interruption. And the TCC has consistently reported the presence of the dock and the Konyead USB4 NVMe drive enclosure also plugged into an open USB4/TB4 port (see below).

I’ve gotten into the habit of checking things as I sit down with my first cup of coffee to start up my day. And since last Thursday, everything been peachy. No problems at all.

But gosh, doesn’t that just underscore the loathing and dread that an intermittent failure can inspire? Why am I checking this stuff every day? Because I’m waiting for the next failure to pop into view. CalDigit doesn’t seem concerned, and hasn’t issued an RMA. Why can’t I be as cheerfully indifferent to the possibility of impending doom? Because I bought and paid for the unit, the problem is mine, all mine, I guess!

And boy, isn’t that just the way things go sometimes, here in Windows-World? Stay tuned…

Oh boy! For more than a few minutes yesterday, I thought I’d completely lost my now-ancient Surface Pro 3 hybrid tablet. It took me a while to diagnose, but it was actually a Surface Pro 3 dock fail, not the PC itself. Seems that the brick that provides power to the dock is no longer working. It wasn’t charging the battery anymore, so once the battery died, so did the PC.

As you can see in the Speccy motherboard info screencap above, this unit goes all the way back to the Haswell CPU days. That makes it a Gen 4 Intel CPU. According to Intel, this model launched in Q3 2013, about 9.5 years back. That’s a long run for any PC, if you ask me.

After a couple of tests, I determined that power to the dock itself wasn’t working.

Diagnosing Pro 3 Dock Fail

At first I couldn’t get the SP3 to keep running. It would start up, then immediately fall over. I checked the battery and saw it had 0% charge. Upon leaving it alone and plugged into the dock for a couple of minutes, the charge level remained the same. “Aha!” I thought “No power to the charger, no power in the battery.”

And so it proved to be. I still had the standalone charger for this unit. Upon plugging it into the wall and the SP3, the battery charge level started to climb. It took almost 2 hours but it eventually reached a full charge, to wit:

Given sufficient time, the SP3 returned to full charge.

Here’s the Question: Do I want to spend $41?

I can replace the AC adapter charger for the dock for the aforementioned price. Do I want to do that? I’ve been thinking about retiring this machine for more than year now. I’d been keeping it to ride Windows 10 to its retirement date with a machine likewise fated. But now I’m wondering if it’s worth it. $41 ain’t much, so maybe I will. Let me think on it, and I’ll post again…

Note added 20 mins later: I found a cheaper replacement on Amazon. For under $19 (including tax) I’ve ordered a new AC adapter for delivery next Monday. I’m hoping it will restore the dock to operation upon plug-in. I’ll follow up…

Note added Saturday AM, February 19: The El-Cheap AC adapter showed up at our front door late last evening (thanks Amazon Prime!). I removed the old unit and replaced it with the new one this morning. It works: as you can see in the next screencap the Surface has its wired GbE connection back, courtesy of the powered-up dock.

With power to the dock restored and Surface re-seated; Ethernet now works!

That was definitely worth the near-sawbuck expended for the replacement part!

Oh boy! I just shot myself rather nicely in the foot but managed to call back the bullet. Let me explain, in the context of unfolding and frustrating Firefox x86 follies here at Chez Tittel. The lead-in graphic for this story shows two entries for Firefox as you can see in the red outline box. Therein hangs this particular tale…

Fixing Frustrating Firefox x86 Follies

I noticed this earlier this week when, after updating Firefox x64 on my production PC, I noticed a second copy still running the previous version. WTF? Using SUMO to show me the containing folders for each instance I saw what was up. One 64-bit copy is running in the Program Files folder tree. More interestingly, a second 64-bit copy is running in the Program Files (x86) folder tree. WTF again?

Nothing loath, I went into Explorer and deleted the Mozilla Firefox folder from the (x86) folder tree. This is the shooting myself in the foot part. Turns out that particular instance has all of my favorites, stored passwords, and yada yada yada. The true x64 instance is a “clean install” — but not in a good way. Sigh.

I called the bullet back by opening the Recycle Bin and restoring the entire, just-deleted Mozilla Firefox folder. I see that I can export all my stuff from one instance and then import it into the other. As soon as I have time to figure all that stuff out I can grab my “vital stats” from the x86 instance and make ready to transfer it into the x64 instance. Then, I should be able to safely delete the x86 instance without losing my valuable accreted data. Sigh again.

This Raises an Interesting Question…

What I really want to know is: how did an x64 instance of Firefox wind up in the x86 folder? I’m pretty sure that’s another self-inflicted wound. When I updated the trailing second instance earlier this week, whaddya bet it was a now-obsolete 32-bit instance for which only a 64-bit instance can serve as an update? Sigh one more time, and wonder why Firefox let me do this to myself. Go figure!

Alas, that’s the way things go for me sometimes in Windows-World. I’m just glad I was able to figure out and recover from my own foible without losing too much time or wasting too much effort.

This was a weird one. The lead-in graphic shows that although I plainly installed version 15.9.51 of the Visual Studio Tools 2017, it reports in as version 15.8.9. No amount of uninstall/reinstall (aka R&R for “remove & replace”) made any difference. I finally solved my Visual Studio Build Tools 2017 mystery by installing the latest version of Visual Studio Enterprise. (That came free, thanks to my WIMVP privileges and its attendant VS subscription.)

Workaround Solves Visual Studio Build Tools 2017 Mystery

Take another look at the lead-in screencap. It shows me uninstalling version 15.8.9 using Winget. Then I force-install version 15.9.51 explicitly. But even so, Winget list still reports version 15.8.9 as clear and present. Sigh.

Thus, I resorted to a total workaround. Because I have access to a VS subscription — thanks to my 2022 WIMVP status (I’ll be finding out next week if it gets extended for 2023) — I installed a full-blown VS version. This was enough to kill the VS.2017.BuildTools update messages in Winget (at least, after I uninstalled same).

What Gives?

Because I can’t find any definitive explanation, I can only speculate. I’m guessing it’s either (a) a  mistaken version tag  for what is really version 15.9.51 or (b) a unreported install failure that leaves the Build Tools at version 15.8.9. Whatever that case might be, I switched from the free version to the for-a-fee version. That made my apparent problems disappear. I’m grateful!

Sometimes, solving Windows problems requires resorting to creative workarounds. I would definitely include today’s odd situation, and its equally odd solution, in that category.

Happy New Year 2023 to one and all. May the coming year bring you joy, prosperity, good health and plenty of interesting Windows issues to solve (or read about here). Best wishes!

Sometimes, no news is itself news. One of my favorite Sherlock Holmes stories, The Adventure of Silver Blaze describes a “curious incident of the dog in the night-time” wherein “the dog did nothing…” Lately, as the lead-in graphic from Reliability Monitor shows, my production PS is such a dog. Over a 19-day period, it shows exactly one critical event. And that one is easily explained, thanks to an aging UPS battery.

Good News When a Curious Reliability Monitor Incident Occurs

According to WinFetch, I have 308 packages installed on my production desktop, of which Winget recognizes 226. Those numbers provide ample opportunities for things to go sideways. I confess: I check in on Reliability Monitor when seeking blog topics. It seldom fails to point toward interesting troubleshooting or clean-up exercises.

I use the heck out of my production PC: 8-10 hours a day, 6-7 days a week. Consequently, I’ve seen many less happy Reliability Monitor traces than the one at the head of this story. It is, in fact, something of an anomaly in my 6-plus years of working this PC as a daily driver. And that, to mangle Mr. Holmes, is what makes for a “curious incident” — namely that I could work both hard and long on this PC while maintaining a nearly perfect reliability score.

Windows 10 Gains a Ringing Endorsement

When nothing shows up in Reliability Monitor, the presumption is that the PC is behaving itself well. For example, I’m currently logged into 4 RDP sessions: 3 on various Windows 11 versions, 1 on Windows 10. Only one of them shows one critical error event like the lead-in graphic. It’s from a Dev Channel build that’s been running for 11 days, and the critical error it shows resolves into 4 events that occurred just after the new build installed on November 29.

The other 3 PCs show 3 or more critical events over the default 19-day interval typical for Reliability Monitor displays. And these, too, devolve into a half-dozen error events of one kind or another. My point is: the production PC is manifesting unusual calm and stability, especially as the other machines are less heavily used (though subject to beta software and primarily test or experimental situations).

I see this as another explanation for the relatively slow changeover from Windows 10 to 11 I wrote about yesterday (Where Windows 11 Business Use Stands). If the OS ain’t broke, there truly is no need to fix (or replace) it. I find it comforting, in a weird way; MS undoubtedly has more mixed feelings on this subject. But it offers a pretty compelling explanation as to why businesses aren’t yet taking the Windows 11 plunge in significant numbers.