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.