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.

Drat! I’d feared this might happen, and it did. As you can see from the lead-in graphic, waiting for a new Dev Channel build on my second Lenovo Yoga X380 did no good. It, too, failed to upgrade with error code 0xC1900101. Thus, for that PC, Build 22593.1 fails beta promotion, just as with the previous build .

That leaves me with two potential paths to follow:

1. Find a fix for, and repair the cause of the error
2. Wipe the PC and use a current ISO to perform a clean install

I haven’t had much luck with Path #1, so I’ll probably give Path #2 a shot this weekend. I wish I knew what was causing the error.

Why Build 22593.1 Fails Beta Promotion

I am not alone in this error. Both Windows Report and The Windows Club have stories about this very error in their recent output. Reasons for this error vary, and can include the following:

• Insufficient disk space on the target device to accommodate upgrade files and working space
• Issues with non-essential peripherals (drives, scanners, and so forth)
• Outdated BIOS
• Incompatible device drivers
• Third party AV or antimalware programs
• “Software conflicts” with installed third party programs

As far as I can tell I may have a driver issue. But I can’t find proper details in the various log files to know for sure what’s up. I’m pretty sure I’m not subject to any of the other potential causes.

Clean Install Offers Easy (Potential) Out

Although there’s work involved after a clean install to bring the apps and applications back, this may be worth trying. I’ve spent hours and hours — unsuccessfully, so far — chasing after one or more errant drivers. I can get through a clean install in under an hour, once I have the ISO file built and ready to rock’n’roll.

Stay tuned! This promises to be interesting. . . I’ll report back as soon as I have some news.

It’s an old-school repair technique that remains relevant even for the latest Windows version. While fiddling with my up-and-coming production PC this weekend, I encountered absent apps. This is my latest PC build — Asrock B550 Extreme4 mobo, AMD 5800X CPU, 64 GB RAM, 2TB Sabrent Rocket SSD, and GeForce 1070 Ti . At a bare minimum, I found both Windows Defender and Windows Terminal MIA on the then-current install. Fortunately, an in-place upgrade repair install fixes mystery Windows 11 woes.

Indeed In-place Upgrade Repair Install Fixes Mystery Windows 11 Woes Quickly and Easily

The principle behind this technique involves over-writing the current Windows image with an equivalent replacement. Essentially, it replaces all of the OS files and related scaffolding without touching local files and applications. It also re-creates the default app environment for Windows 11, which was my real motivation for this maneuver.

I visited the Download Windows 11 page to grab the ISO. I clicked on “Download  now” under the Create Windows 11 Installlation Media heading, and used the Media Creation Tool to create an ISO file. After mounting that ISO on the target PC, I ran setup.exe to perform the in-place upgrade repair install.

Before: no Windows Defender or Windows Terminal (the packages themselves were absent from the runtime environment). After: both Windows Defender and Windows Terminal were present and ran as expected. Total time involved in this repair: 10 minutes to download the ISO file shown in the lead-in graphic; 20 minutes to perform the install itself (total time: half an hour).

The Half-Hour Troubleshooting Rule

Once i figured out that the apps were missing completely, I immediately decided to run the upgrade repair install. Normally, I will troubleshoot for half an hour on a problematic Windows image. If I haven’t solved the problem by then, my next move is to try this repair technique. Most of the time, it works when problems are OS related (it may not help with application issues, though).

And fortunately for me, it worked as desired this time. I’ll continue my “slow migration” from my 2016 vintage Z170 i7-6700 (too old to meet Windows 11 hardware requirements) later this week, after I meet some pressing deadlines first and foremost. Stay tuned: I’ll keep you posted on progress and issues encountered.