Although I use Stardock’s alternative menu programs on Windows 10 and 11, I also use the built-in Start menu, too. it’s especially good at taking me straight to Windows 10 apps through its search box. That’s true, however, only as long as that search function is working. This weekend, I ran into a situation where it quit doing its thing. Fortunately, I found an easy Start menu search repair technique. Let me share it with you…

What’s the Easy Start Menu Search Repair Technique?

Once again, it’s a matter of jumping into Task Manager to restart Windows Explorer. Note: this also means a restart works equally well (though it takes longer). Why? Because it, too, automatically resets Explorer as part of that overall process.

Here are the steps involved:
1. Open Task Manager (on Windows 10, you can right-click the taskbar and select the Task Manager entry or use CTRL-SHIFT-ESC key combo; on Windows 11, only the latter works).

2. Look for Windows Explorer on the Processes tab. If absent, open an instance from the Taskbar (or your favorite other means). Right-click the entry, then select Restart from the pop-up menu.

That’s it. It won’t work 100% of the time, but it does work most of the time. If it fails, then it’s time to start considering other, more serious windows repairs. These include using DISM and SFC, running the Windows Troubleshooter, an in-place upgrade repair install, and other tried and true repairs.

Fortunately, none of those proved necessary for me this weekend. AND I was able to resume my Solitaire session without having to find the App alphabetically instead. (Note: even when search was munged, that still worked…)

OK, then. I just installed optional/preview update KB5012643 on my Windows 11 X1 Extreme laptop yesterday. This morning, I’ve been fighting camera frame server crashes. You can see the traces of this contest from Reliability Monitor in the following graphic.

You can see an ongoing sequence of repeated “Windows Camera Frame Server” errors at semi-regular intervals. Each one follows a “test reboot.” [Click image for full-sized view.]

Registry Hack Aids Fighting Camera Frame Server Crashes

In researching this error, I came across a registry hack in the HKLM/SOFTWARE/Microsoft/Windows Media Foundation/Platform key. It required creating a DWORD value named “Enable Frame Server Mode.” When that value was set to 1, the Frame Server crash ceased. Instead, I got a crash on Windows Biometrics. And when I restored my camera’s and fingerprint scanner’s ability to support Windows Hello, the Frame Server error popped back up again. I had to laugh!

Choosing the Lesser of Two Weevils

Dispelling the Frame Server error not only turned off the PC’s webcam, it apparently also messed with Windows Biometrics in general. Given a choice between a non-fatal (and only mildly annoying) Frame Server error at startup versus being unable to use Windows Hello, I choose the latter. I’m reporting the error to Feedback Hub, and hoping for a fix. But I’m continuing to use my camera and fingerprint scanner for login/authentication purposes.

Go figure! In Windows-World one must sometimes trade off one thing against another. This time around (and in most cases) easier security via biometrics won the toss…

Yesterday, my production PC (Windows 10, i7-6700, 32GB RAM, 3070 Ti GPU) started the “blinking thing” again. As soon as I logged in, the right-hand monitor would go black then come back at irregular intervals. Previous episodes have responded to a driver update. But this time, no such update was handy. But my 3070 Ti runs either a gaming (for game play and high frame rates) or studio (for creative and production work) version. This time, fixing the blinking monitor required Nvidia Studio Driver to do its thing.

Why Is It That Blinking Monitor Requires Nvidia Studio Driver?

This issue has been popping up on my production PC since I switched out the 1070 Ti for the oversized 3070 Ti in January. I’m starting to wonder if my power supply may be having issues with the load on this system.

Reliability monitor doesn’t show any errors. But a dive into Event Viewer shows a Service Control Error 7031 that points to the Nvidia Local System Container at around the times I was getting the blink behavior. Since I’ve switched from the Gaming version of the driver to its Studio counterpart, the error has not resurfaced. Looks like it may be some kind of software glitch after all.

GeForce Experience lets you switch between the two driver flavors pretty easily. Simply click the vertical ellipsis to the right of the Check for Updates item and it gives you a radio button to pick one or the other, like so:

Fortunately for me, switching from”Game Ready” to “Studio” restored my system to proper operation. Good thing I’m not a serious gamer, eh?

To qualify for Windows 11, a PC must support Secure Boot. It doesn’t necessarily have to be turned on. But if it is turned on, I learned last week that BitLocker follies follow secure boot like ducklings follow their Momma. In other words: if BitLocker is turned on for the C: (Windows boot/system) drive, it must also be turned on for the File History drive that Windows 11 uses as well.

What Does BitLocker Follies Follow Secure Boot Mean?

I learned this hard way when I tried to turn File History on for my Lenovo X12 Thinkpad PC. Because it had secure boot turned on, I had to enable BitLocker for the external drive upon which I targeted File History. This immediately got me to climbing an “interesting” learning curve.

While summiting that slope, I learned the following things:

1. You can’t manipulate an external drive’s BitLocker status through RDP. For security reasons, you must be directly logged into the target system. Sigh.

2. Turning BitLocker on requires setting a password to obtain or deny access to its encryption/decryption capabilities. This makes good sense, but gives me “just one more thing” to remember. Sigh again.

3. At first, BitLocker encryption looks fast. It got up to 84-85% complete in minutes. To my dismay and disappointment, the final 15-16% took HOURS to complete. By no coincidence whatsoever, space consumed on the drive is between 15 and 16%, too. It took the better part of 6 hours for the encryption to finish, in fact (0.71 TB worth).

4. Now, when I want to access the encrypted drive, I must first open it in Explorer, and unlock it by providing its password.

It’s All Good . . . I Hope

At least I now understand the necessary relationship between Secure Boot, BitLocker, and File History. I hope I don’t need to go a-troubleshooting soon. But if I must, I will. Stay tuned: I’ll keep you posted.

For the past couple of Dev Channel builds, I’ve been trying — and failing — to get my Beta Channel test PC promoted to the Dev Channel. For Builds 22593 and 22581 the tap had been opened to upgrade from Beta to Dev Channel. But on my Lenovo ThinkPad X380 Yoga (8th Gen i7, 16 GB RAM and 1 TB SSD) it didn’t work. After many hours of dithering about, a clean install succeeds where Beta promotion fails. Let me explain…

Why Clean Install Succeeds Where Beta Promotion Fails

Wiping the primary system/boot drive was apparently the ticket to success. Given that I seemed to have mystery driver issues, starting over with a clean slate has finally set things right. And indeed, it was a rough and time-consuming ride along the way. Ultimately it took less than 35 minutes to perform the clean install itself. Alas, though, it always takes longer to put all the apps and settings back the way I want them from a clean slate. That’s life!

Interesting Lessons Learned

This is my first clean Windows 11 install since the new OS showed up in mid-2021. I had to be reminded that the BitLocker ID associated with the key needed to enable a USB-based install comes from the device. I spent a while trying to provide the wrong key, because I didn’t start by matching the Key ID value to the Device Name. Only then did I find and enter the right recovery key. Sigh.

I also learned that Norton’s external drive scan function takes FOREVER to complete. I let it run for 1:15 out of curiosity, but that was already too long for me to wait to move onto my next step. So I cancelled the scan (which took no time at all, thank goodness) and went onto the clean install.

Performing the clean install was remarkably quick. It included the option of defining a machine name near the tail end, too (something new to me). That was an opportunity I grabbed gratefully, and saved myself a bit of time moving ahead into post-install efforts.

Bottom line: I’m incredibly grateful to have this machine back where it needs to be. It’s nice not to have the mystery 0XC1900101 error hanging over my PC (and my head) any longer. I’d love to know what caused it, and how to fix it, but I never got enough data to make that happen. That said, it’s nice to know the “repair of last resort” — namely a clean install — still does the trick when other techniques come up short.