A couple of months back, Windows 10 starting crashing when I would plug a USB-C NVMe device into one of my Belkin Thunderbolt docks. I soon learned this was a known gotcha, and simply switched to plugging the device into my USB-C/Thunderbolt port instead (which kept working). As per the Windows 10 20H2 Known and Resolved Issues page, KB4586853 fixes Thunderbolt NVMe SSD stop error.

Checking KB4586853 Fixes Thunderbolt NVMe SSD Stop Error

As an eternal skeptic, I tried my Sabrent-enclosed Samsung 760 NVMe drive through the Thunderbolt dock on the Lenovo X380 Yoga, the X1 Extreme, and the X390 Yoga laptops I have at my disposal. It worked fine on all of them. I haven’t tried it on the Dell Optiplex 7080 Micro (it’s upstairs) yet, but I expect it will be fine as well. Makes one wonder what started this off in the first place.

The Conexant Audio Driver Issue

As you can see in the lead-in graphic, the long-standing error with Conexant audio drivers remains unresolved. I guess I should be glad that it doesn’t affect my newer Lenovo laptops. As you can see from the following Device Manager screen cap, all of them list a Conexant SmartAudio HD device as the first entry under Sound, video and game controllers. Given the gotchas out there, I’m happy when they don’t bite me!

Although my newer (2018 and later) Lenovo laptops all include Conexant audio chips, none seems affected by the unresolved issue for such devices. Dodged a bullet?

In general when things get weird with devices or their drivers on Windows 10, I usually check the issues list before I go into heavy-duty troubleshooting mode. As with the Thunderbolt NVMe device issue just resolved, such issues do bite some of my PCs some of the time. Thus, this saves me from trying to solve problems that other, better-equipped engineering teams are already working on. Now, if I could just learn to be patient while those fixes are in progress…

First, an admission: I’m a long time user of Stardock Software’s Start10 program. In fact, when I first started using this tool, it was called Start8, in keeping with the version of Windows then in vogue. I think my problem may be related to an unwanted interaction between Start10 and the default Windows 10 Start Menu. Nevertheless, I’m happy to report that an unresponsive Start Menu gets easy fix. Let me elaborate…

Unresponsive Start Menu Gets Easy Fix Explained

I don’t have this problem on unaltered Windows 10 installations where Start10 is absent. That’s what make me think it results from some kind of unwanted or unplanned interaction. I’ve checked the Start10 forums and can’t find any other reports of the same kind, but that’s neither here nor there.

On machines running Start10, when this happens I simply launch Task Manager. Then I right click the Windows Explorer entry beneath the Processes tab. When the resulting pop-up menu appears, one of its options reads “Restart.” When selected, this restarts the primary Explorer process. Among other things, it handles the task bar and the default Start Menu.

Following that restart operation, my access to the default Start Menu is restored. If I’m using Start10, why do I still need the default start menu? Simple: there are some programs and searches (such as using the string “reli” to launch the Reliability Monitor) that work in the default Start Menu but not in Start 10. Thus, I do have the occasional reason to dive into that default instead of sticking solely to Start10’s capabilities.

My old friend and former partner at Win10.Guru, Kari the Finn always said “If there’s a built-in tool or utility in the OS, there’s no reason to use a third-party tool.” Let’s just say that I’ve recently been reminded that he had good reasons to make that assertion. Even so, I remain a fan of third-party tools in general, and a fan of Start10 in particular. I’ve just had to learn to work around this particular issue. Cheers!

Hmmm. I just read a disturbing story over at Gizmodo. Something of a rant from Sam Rutherford, it explains “Why I’m Finally Getting Rid of All My HDDs Forever.” I’ve been following his work for some time, and he usually has intelligent and useful things to say. This time, though, I’m opposed to his position. In fact, I still firmly believe that hard disks remain useful PC storage devices. Quick count: I have at least 10 of them here in my office, at capacities ranging from 1 TB to 8 TB.

Why Say: Hard Disks Remain Useful PC Storage Devices?

If I understand his complaint, Mr. Rutherford is giving up on HDDs (Hard Disk Drives) because several of them gave up on him recently. One failure cost him 2 TB of data, some of it precious. I say: Boo hoo!

The lead-in graphic for this story comes from my production PC running a freeware program named CrystalDiskInfo. (Note: grab the Standard Edition: the others have ads and bundleware). Notice the top of that display lists Windows drives C:, J:, K:, G:, D:, I:, F:, and H:. In fact, all of them show blue dots and the word “Good” as well. These elements provide rude measures of disk health for both HDDs and SSDs. Of the 8 drives shown, 3 are SSDs, 4 are HDDs, and 1 is a so-called hybrid HDD; all are healthy.

Mr. Rutherford could have used this tool. Or used others like it, of which there are many (see these Carl Chao and WindowsReport survey pieces, for example). Then, he would have known his problem HDDs were headed for trouble before they failed. Plus, he himself admits he erred in not backing up the drive whose failure caused data loss. I check all my drives monthly (both SSDs and HDDs) looking for signs of impending trouble, as part of routine maintenance.

Backup, Backup and More Backup

SSDs are not mechanical devices, so they don’t suffer mechanical failures. Over the 10 years or so I’ve owned SSDs (perhaps a couple of dozen by now) not one has ever failed on me. Over the 36 years I’ve owned HDDs, I’ve had half-a-dozen fail out of the hundreds I’ve used. But it’s inevitable that I will suffer an SSD failure sometime, even though I’ve yet to experience one personally. Why? Because all devices fail, given enough time and use.

Personally, I think HDDs still have a place in my storage hierarchy. I just bought 2 8 TB drives earlier this year, for about $165 each. That’s way cheaper storage than even the cheapest of SSDs on today’s market, and much more capacity in a single device than I’d want to purchase in solid state form. (Note: a 7.68 TB Samsung 870 QVO SSD costs $750 at Newegg right now. Thus it aims at those with more money than sense, or those with cash-generating workflows that can actually cover such costs.)

The real secret to protecting data is multiple backups. I bought those 8 TB drives to back up all my other drives, so they’re my second local line of defense. I also pay for 5 TB of online storage at OneDrive and DropBox and have two extra copies of production OSes, key files and archives in the cloud as well. I backup my production PCs daily, my test PCs weekly, and key bits and pieces to the cloud weekly as well). Basta!

I’ve been raving about the SFF Dell Optiplex 7080 Micro a fair amount lately. I remain convinced it’s a good purchase and will be a great machine for long-term use. That said, there is the proverbial “one thing” that lets me know for all its glories, it’s still a Windows PC. I’ve been dealing with an RDP mystery — as shown in the lead-in graphic for this story — that actually affects RDP traffic in both directions. Its 20H2 RDP mystery remains unsolved, as all my troubleshooting efforts so far have failed.

Read on, though: I did eventually figure this out, and get RDP working. It turned out to be a basic and obvious oversight on my part. Sigh.

What Do You Mean: 20H2 RDP Mystery Remains Unsolved?

Despite chasing down a large laundry list of things to check and set, I get password related errors when trying to RDP into or out of the 7080 micro. The lead-in graphic shows what happens when I try to RDP into the box. When I try to RDP out of the box, I get an out-and-out invalid password (“may be expired” error) instead.

Obviously, something funky is up with authentication on this Win10 install, because when I try to access the device through the File Explorer network connection, I get a request for network credentials, too. Again, presenting valid credentials doesn’t work. I see a “not accessible” error message instead:

Here’s the list of what I’ve tried so far:

1. Double-checked Remote Access is enabled.
2. Relaxed all relevant settings in Advanced Network Sharing for Private, Guest/Public, and All Networks categories.
3. Enabled all Remote Access checkboxes in Defender Firewall settings.
4. Ran the Network Troubleshooter
5. Ran the Microsoft Support and Recovery Assistant

It’s the Account, Stupid!

After noodling about with this for a couple of hours I realized that I had defined a local acount as admin. Worse yet, I had not promoted my Microsoft Account on the Optiplex 7080 Micro from ordinary user to administrator.

Because I was using my MS account credentials to attempt network login and access, I didn’t have permission to do the password lookups in LSASS needed to make the process work. Once I promoted that account to admin level, everything started working.

Sheesh! Talk about an obvious mistake. As with many problems with Windows 10, this one turns out to be entirely self-inflicted. At least, I know who to blame!