Category Archives: Troubleshooting

Enduring Konyead NVMe USB4 Drive Mystery

Wow! I’m really stumped. I’ve got a Konyead M.2 NVMe drive enclosure that works on only one computer right now. For a long time, I was unable to eject the drive safely. But after backing off the write caching setting for quick removal, and resetting the drive letter from F: to X:, I can now do that. But even so, if I then unplug the drive and plug it into another PC it’s unrecognizable. This enduring Konyead NVMe USB4 drive mystery is driving me nuts!

Showing Enduring Konyead NVMe USB4 Drive Mystery…

When I plug the Konyead into any compatible USB port on another PC (USB3.1 via Type A connector, or USB4 via USB-C connector) it won’t come up. If I go into Disk Management, it immediately throws an error message that says the drive must be initialized. Options offered are MBR and GPT. Choose either one, and the right-hand error box pops up citing a “fatal device hardware error.” Yet, the drive works fine on my Lenovo X1 Extreme (8th gen Intel CPU). What gives?

I’ve tried fixing it with MiniTool Partition Wizard, too. It shows me the device, but also shows it at zero length. Thus, it’s unable to access the raw disk data to find the partitions (and related tables ) that I know are on the drive.

I’ve checked the Crucial SSD’s firmware and driver: both pass the tests from Crucial Storage Executive (the maker’s diagnostic/mgmt tool for this drive). This mystery remains opaque to me. I’m galled that the device works in one PC, but not in others: what’s the point of a removable drive in those circumstances?

Next Steps…

I’ve not been able to find anything about this kind of problem via online searching. I’ll reach out to Crucial’s tech support operation and see if they’ve ever heard of anything like this before. Konyead is impenetrable: shows the NVMe enclosure, but all text is in Chinese, and the page for my device won’t come up. They do have a contact page, though, so I suppose I should give it a whirl.

Stay tuned. I won’t quit bulldogging this, but I’m afraid I’m up against what might be an intractable language and culture barrier. We’ll see.


X12 Hybrid Gets 25309 Clean Install

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, 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!

X12 Hybrid Gets 25309 Clean Install.winver

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!


Short-Lived CalDigit TS4 Hiatus

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…


Surface Pro 3 Dock Fail

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.

Surface Pro 3 Dock Fail.dockshot

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:

Surface Pro 3 Dock Fail.battlevel

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!


Frustrating Firefox x86 Follies

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.


Obvious Fix Addresses 0xC1900101 Install Error

I run two Dev Channel test PCs. Yesterday, the Lenovo ThinkPad X12 Hybrid failed to upgrade to Build 25284. And it threw a familiar error code — one I’d just written about on ElevenForum just two days ago. Fortunately, the obvious fix addresses 0xC1900101 install error, as I will explain. But gosh! What a coincidence to have dispensed advice about this error only to experience it myself shortly afterward.

What Obvious Fix Addresses 0xC1900101 Install Error?

First let me share the text from my ElevenForum post (from which a screencap appears above):

Check out this MS Learn article: it asserts that an incompatible driver is present when this error code presents:

So what I did next was to review all of the device drivers on the problem PC, and to upgrade those that weren’t current. To that end, I used a 3rd-party tool from IObit called Driver Booster (available in both free and for-a-fee versions). It found over 20 drivers in need of updating, and I updated all of them.

Long story short: two reboots later (one from the drivers the program found, another from a Lenovo Vantage update) I retried the 25254 install. And this time it completed successfully, sans the driver-related error. As I poke around online, I also see this is a fairly common install error where the obvious repair strategy is most often effective.

Shoot! It’s nice when things work the way they’re supposed to. Luckily, that does happen here in Windows-World from time to time.


Windows 11 Power Options Oddity

OK, here’s one for the “Stranger Things” file. I was checking Power Options on a test laptop yesterday. In fact, it’s one of a pair of nearly identical machines: both are Lenovo ThinkPad X380 Yogas that differ only in SSD brand and OS variant (this one runs Beta Channel, the other one Dev). Yet this machine will show only two power plans under Power Options (see lead-in graphic). The other one shows all default items just as it should, and then some (see below) .

Windows 11 Power Options Oddity.devchannelx380

The Dev Channel X380 lets me view or hide additional plans; the Beta Channel X380 does not. What gives?
[Click image for full-sized view.]

Working Around Windows 11 Power Options Oddity

To attempt to fix the issue, I worked my way through the various — and terrific — Power Options tutorials over at These include the following items:

Of those items, the first put the X380 in a state where I could restore missing power plans. The GUIDs for other plans remained available, but I couldn’t get the utility to offer an “Unhide” option so it would only show two Power Plans at any given moment. That said, having made other Power Plans accessible that workaround proved good enough for me.

Even the Master Remains Baffled

I exchanged a series of private messages with Shawn Brink, fellow WIMVP and a primary operator and tutorial writer at Eleven Forum on this mystery. We ended up concluding that a Lenovo OEM power management driver might be impacting the built-in Power Options control panel widget. I found and installed a new (Nov 29, 2022) Lenovo Power Management Driver for Windows 11.

At first, it made no difference in Power Options behavior. Following a reboot, though, while I still could not unhide other power plans in the initial Power Options pane shown as the lead-in graphic, when I click “Create a power plan,” it now shows all three default items correctly — namely Balanced, Power Saver and High Performance.

Windows 11 Power Options Oddity.partial fix

Here’s progress, of a sort. All the defaults show up when creating a custom plan. [Click image for full-sized view.]

I still have to work around the lack of an unhide capability to access invisible power plans using PowerShell. But at least I can now access and use all  such power plans. This time, close enough is also good enough. Sigh. And that’s how things sometimes go, here in Windows-World.

Note Added January 23

I built an ISO to match the currently running beta image (22623.1180) from Then, I performed an in-place repair upgrade. I’d hoped this would fix the Power Options oddities. No dice: apparently, this is among the few problems that a prair install won’t fix. Sigh again.


Visual Studio Build Tools 2017 Mystery Masticated

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!



Curious Reliability Monitor Incident Occurs

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.


Transient Mysterious GeForce Experience Error

It’s great that I love a good mystery, because I have one on my hands. Yesterday (November 30) I ran GeForce Experience to update the Lenovo P16 Mobile Workstation’s Quadro RTX A5500 GPU. An odd error message showed up at the tail end of the process. It read “Unable to install driver” but didn’t identify which one. Immediately thereafter, GeForce Experience announced a successful driver update (see lead-in graphic). I can only describe this phenom as a transient mysterious GeForce Experience error. As usual running things down means learning and figuring more things out.

Chasing A Transient Mysterious GeForce Experience Error

I did some searching around to see where GeForce Experience keeps its installer logs. It’s a long file-spec, like so:

C:\Users\<acct-name>\AppData\Local\NVIDIA Corporation\NVIDIA GeForce Experience

My source for this insight came from an Nvidia Support article entitled “How to enable NVIDIA Graphics Driver and GeForce Experience installer logging.” The log files, obviously enough, end in the “.log” extension. There were plenty of them to look through, too:

Transient Mysterious GeForce Experience Error.logs

Four different readable log files, no joy in any of them.

I couldn’t find any errors in any of those logs, though, which is why I’m calling this a transient mystery. If I read the afore-cited NVIDIA Support note correctly, I probably needed to enable logging before installing the latest GeForce driver. But it’s kind of a Catch-22: I didn’t know I had an error until the error already happened. If I really, really wanted to get to the bottom of this, I’d roll back to my preceding OS image, enable installer logging, and then reinstall the driver. But because it’s working as it should be and is throwing no errors I can see (Event Viewer and Reliability Monitor) I’ll live with the status quo.

But that’s the way things go sometimes, here in Windows World. I’m just glad things are working as they should be.