Category Archives: Troubleshooting

Clean Install Succeeds Where Beta Promotion Fails

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.


Build 22593.1 Fails Beta Promotion

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.


NonCNVi M.2 Wi-Fi Device Delivers LAN Access

It’s always the little things that jump up to bite you (or me, anyway). In today’s case, it was my blithe assumption that Intel Integrated Connectivity (aka CNVi) wouldn’t prevent the AX201NGW M.2 Wi-Fi card from working on my AMD B550/Ryzen 3 5800X build. Yeah, right! But when I replaced it with a no-name (REKONG) Media Tech MT7921K module (depicted in the lead-in graphic), Device Manager picked up that non-Intel hardware immediately. After a bit of driver fiddling, this US$29 (tax included) nonCNVi M.2 Wi-Fi Device delivers LAN access as it should. It does have interesting limitations, though . . .

Fiddling Means NonCNVi M.2 Wi-Fi Device Delivers LAN Access

At first, after plugging in the device, I saw only non-working BlueTooth and Network Adapter devices in Device Manager. This informed me that Windows couldn’t find the required drivers on its own. But a quick search on “Windows 11 drivers for MT7921K” quickly turned up what I needed. They’re available from Lenovo, as it turns out, with a separate .exe for each of Bluetooth and Wi-Fi.

As the owner/operator of half-a-dozen (or more) Lenovo laptops, I’m quite familiar with their self-installing drivers. After downloading and installing them, here’s what I see in Device Manager:

NonCNVi M.2 Wi-Fi Device Delivers LAN Access.DevMgr

With the right drivers installed, the BT components and the Wi-Fi interface all show up. Good!

Just a Few More Things

Wi-Fi behavior on desktops can be interesting. The interface has a tendency to turn itself off upon reboot, I’ve learned. I’m also trying to figure out why I can access the LAN (via the nearby Asus AX6000 router), but I can’t yet get Internet access through this interface. I have a wired GbE connection that works fine, but had hoped to switch over to wireless. So now, I’m researching those two issues in hopes of finding solutions soon.

A little more time put intro troubleshooting the M.2 Wi-Fi card tells me lots of interesting stuff:

  • The lack of an external antenna means the device doesn’t see that many wi-fi interfaces as it scans the airwaves. Thus, for example, it doesn’t see the Spectrum-supplied router in my bedroom closet (all of my laptops in the same office see it quite well).
  • The fastest throughput I can get on the device is between 250 and 300 Mbps (observed through a connection to
  • The 2.4 and 5 MHz connections to the “office router” are flaky in interesting ways: sometimes, I can access one or the other to get on the LAN, but don’t get Internet access. At other times one channel or the other will be inaccessible. Again, I attribute this to lack of an external antenna. My son has a PCIe 802.11ax adapter card with triple external antennae in his bedroom, and he gets up to 900 Mbps from the bedroom closet router, and up to 500 Mbps from my office router.

No External Antenna Is NOT a Plus

I’m increasingly inclined to observe that an M.2 Wi-Fi card makes sense only where close proximity to a WAP is available. It’s probably not a good idea for machines that do lots of heavy upload/download stuff, either. That’s kind of what I wanted to learn more about, so I’m not disappointed by this experience. I feel like I understand the capabilities and limitations of these devices much better now. I will keep my GbE wired connection going forward, too: the M.2-based Wi-Fi is not fast enough for my needs. If I’m ever *forced* to go wireless, I now understand that a PCIe device is my fastest option.


Beta Promotion Difficulties Continue

I must report that my various efforts to get from Beta build 22000.588 to Dev channel build 22581 have gone nowhere. Hence my title “Beta Promotion Difficulties Continue,” to punctuate my lack of progress. I did, however get a more informative error message from one of those attempts (see item 3 below), as shown in the lead-in graphic above.

Attempts Undertaken, as Beta Promotion Difficulties Continue

Here’s a list of all of the fixes I’ve tried in attempting to overcome this increasingly vexing hurdle (of which exactly  none have worked):

1. Simple repetition of the WU update/upgrade process (2 or 3 times, most automatic). I’ve now paused updates for a week to save time and energy.

2. Unplug all non-essential peripherals (an mSATA SSD inside a Sabrent USB 3 enclosure in this case).

3. Use setup.exe from the website-based ISO for Build 22581.1. It didn’t work, but did provide the more informative error message shown in the lead-in graphic for this story.

4. Remove .NET 3.5 and all related Windows 11 features, and try again. Greatly speeded up the update and install processes, but produced the same outcome as the preceding item.

5. Run dism /online /cleanup-image /restorehealth and then sfc /scannow. No joy there, either.

So far, in fact, I’m getting exactly nowhere. Sigh.

What’s Next?

I supposed I could try a clean install of Windows 11 from the aforementioned ISO. But recent reports of install problems (in completion, and in the state of Windows 11 after the fact) give me pause. I don’t think I want to go there just yet.

According to other advice tied to the 0XC1900101 – 0X30018 error code, I could also try some or all of the following:

1. Reset Windows Update components. The TenForums tutorial on that topic includes a handy-dandy batch file that also works on Windows 11.

2. Disable antivirus — in this case Windows Defender. This is working on my other X380 Yoga, so I wouldn’t expect it to help here.

3. My BIOS is up-to-date already and I’m not aware of running any “problematic applications.”

You can get advice galore at stories such as How to Fix Update Error 0xc1900101-0x30018 in Windows 10 ( and others of that ilk. For the moment I’m not inclined to spend more time chasing rabbits and rainbows.

What, Then?

My current plan is to wait for the next Dev Channel build to appear (which it should do, if not this week, then next week for sure). At that point, I’ll try again — and hope for a successful outcome. At the moment I’ve spent more than enough time. I’m content to take a time-out and wait for another try. . .


In-place Upgrade Repair Install Fixes Mystery Windows 11 Woes

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.



Troubleshooting Failed Beta 22581 Promotion

I’d like to report on a snag in upgrading my Windows 11 Beta Channel test PC to Build 22581. As I wrote yesterday, MS has paired up the Dev and Beta channels with this build. Both of my Dev Channel PCs updated successfully; the Beta Channel test PC did not. So now, I’m troubleshooting failed Beta 22581 promotion. This is an interim progress report. Although I’ve already learned a lot, I’ve not yet resolved the problem. Here’s what I know so far. . .

Progress on Troubleshooting Failed Beta 22581 Promotion

The list of data about this update failure reads as follows:

1. The update fails during the final, final phase of post-GUI install after update progress gets to 100% complete.

2. WU Update History reports an error code of 0XC1900101 in its “Failed to install” error  message

3. MS Docs offers a Resolution Procedure for this error code,  from which the following $Windows.~bt items appear important:

3.1 This error code most typically indicates a driver install problem during the Windows install/upgrade process

3.2 If present, the \Sources\Rollback folder may include a minidump file named setupmem.dmp. (Mine does not)

3.3 Event logs may appear in \Sources\Rollback*.evtx (I have no such files)

3.4 The device install log can capture driver install issues, and appears in \Sources\Rollback\setupapi\ I *DO* have one of these and have read it over, and shared it with install experts at Looks potentially fruitful because I do see various errors therein.

4. A typical fix attempt when WU updates fail, is to try an ISO from I’ve built one, but I’m also reading online that nickel release ISOs — including Build 22581 — from are not working properly right now. See this Elevenforum thread (especially pages 6 & 7). Just in  case it blows up, I’ve already made a Macrium Reflect image backup of the current working-but-not-upgraded install. Thus, I can restore it easily booting from the MR Rescue Media.

What Should Happen Next. . .

I’m up against a major deadline today, so I don’t have time to follow all the leads I’ve found. But I do have a task list to follow when the weekend rolls around and I have more free time:

1. The afore-linked Resolution Procedure recommends another WU attempt with all nonessential peripherals unplugged. I’ll do that next.

2. If that doesn’t work, I’ll attempt to use the UUPdump ISO to perform an in-place “repair upgrade” by running its setup.exe file.

3. If that doesn’t work, I’ll check back into the ElevenForum thread to see if any of my appeals for guru help have produced suggestions.

4. If I can’t resolve the issue through typical troubleshooting, I’ll wait and try again when the next Dev/Beta build is released. In my experience of nearly 8 years as a Windows 10 and 11 Insider,  that works more often than not. I’m inclined to believe this is possible because one of my other working Dev Channel PCs is a near-identical Lenovo X380 laptop (only config difference is the built-in NVMe drive: one’s a Samsung, the other’s a Toshiba, now Kioxia).

Stay tuned, and I’ll keep reporting on progress. Cheers!


GPU Driver Update Fixes Flickering Solitaire

I cheerfully confess: I start most working days off with a rousing round of Microsoft Solitaire. When the game pane started flickering this morning, I asked myself “Time for a new Nvidia driver?” Sure enough, a new one issued on March 22 (yesterday). And, as usual, that GPU driver update fixes flickering Solitaire as desired.

Keep Calm and Carry On: GPU Driver Update Fixes Flickering Solitaire

I upgraded the Game Ready Driver to yesterday’s version 512.15 using GeForce Experience. The whole process took under 10 minutes. No reboot was required. Interestingly, Reliability Monitor collected no errors nor warnings while the monitor was flaking out on me, either.

It’s a good thing that the symptoms are both obvious, and easily diagnosed. And FWIW, a keyboard GPU restart (CTRL+WinKey+ Shift+B) didn’t fix things. That’s why I was hopeful that a driver update would make it all better. Luckily for me, that turned out well.

What If a New Driver Flops?

Things rapidly get more interesting if a new GPU driver fails to fix monitor flicker. First and foremost, I’d check cables next, starting (in this case) with the DisplayPort cables that stretch from the Gigabyte RTX 3070 Ti GPU adapter to the affected Dell 2717D. If a cable swap didn’t fix things, I’d try rolling back two driver versions or more (for Nvidia GPUs, that means using its manual driver search facility). If no joy after two or three older driver attempts, I’d next run monitor and GPU diagnostics.

Most of the time, it’s the driver. If it’s not the driver, it’s usually the cable. If I have to get down to diagnostics (usually available from GPU and monitor makers), things can quickly get expensive. Glad to have avoided such issues this time around.

But, here in Windows-World, it’s always something, right?


911 Works Even With Low/No Coverage

In case you’ve wondered, I’ve been on a family vacation to points west. Our itinerary included great visits to White Sands (Las Cruces, NM), the Petrified Forest (Holbrook, AZ) and Tucson. While driving home on Friday, we found ourselves with a flat tire in a remote  area as night was falling. Our splendid E250 Bluetech is a great car, but does not sport a spare tire. Fortunately, I learned 911 works even with low/no coverage.

That’s extremely fortunate. Alas, I was unable to call out for local help. Mercedes roadside assistance needed to be dispatched from San Antonio, over two hours away from our then-present location. But dialing 911 on my iPhone 12, I was able to reach the local emergency response center.

Thank God: 911 Works Even With Low/No Coverage

At first, I was concerned that our situation didn’t count as a real “emergency.” Then my wife made several trenchant observations. We were nearly 20 miles from the nearest small town (the other, next closest was nearly 30 miles away). Night was falling. We were stuck on a narrow shoulder. Cars were zooming by, and our downhill stretch was a popular spot for faster vehicles to pass slower-moving ones. OK then: it was a bad spot to be in.

Her opinion: lack of local services, a bad location, and no outgoing cell or data connections meant it WAS an emergency. In less than a minute I was talking to a very friendly and helpful 911 operator. He agreed we needed help, and dispatched a tow truck from Brady, TX (about 40 miles away from our location).

Call Me Back, If You Hear Nothing…

Because the local signal was so weak, he asked me to call him back in an hour. When I did so, he said he’d tried to call me himself but couldn’t get through. A car carrier was on the way, and should be arriving in another half hour or so. Indeed, I’m glad 911 works to carry outgoing messages when other cellular traffic is impossible. Here’s an interesting explanation of what’s involved: How Can Mobile Phones Make ‘Emergency Calls’ When There’s No Network Coverage?

And indeed, about 90 minutes after my initial call to 911, a car carrier (my favorite brand: Jerr-Dan) appeared on the scene. Shameless plug: Henry, the helpful and skilled operator from Brady-based Back on Your Feet Towing had us loaded and back on the road in under 15 minutes. We would wind up negotiating a price to take our car to a tire repair center near our Round Rock home, over 200 miles away. It was infinitely preferable to spending the night in Brady, and waiting for repairs the next morning. As the ensuing repairs would prove, that was the right decision…

The Morning After

We wound up getting home after 1 AM that morning. Our flat occurred just before 8PM, with about 2.5 hours of driving time left to get home, But with several stops to refuel Henry’s truck, to check the tie-downs on our wounded car, and for bio-breaks, it ended up taking 3.5 hours to make the rest of the trek home.

At the tire repair place the next morning, I learned that the tread and the sidewall had started to separate on the passenger side front tire. I also figured out they were just over their 50,000 mile lifetime warranties. A new tire was immediately installed, and I’ll be ordering a new set this week. I have to imagine that in Brady we’d have waited hours for a replacement tire to come from Austin or San Antonio. In Round Rock, the whole repair took under half an hour!

We’re very lucky the tire didn’t fail more catastrophically. We’re also lucky that 911 works even with low/no coverage, even in the Texas boonies. That was an adventure I’d not wish to repeat any time soon.

Needless to say, we’re very, very glad to be home, safe and sound. A typical sentiment at any vacation’s conclusion, but more heartfelt than usual this time. And remember, when all else is unavailable, 911 is worth a try. Thank goodness it worked for us on Friday!

Note Added 1 Day Later: Worth Reading (and Remembering)

By default, the iPhone turns off Data Roaming (which lets a cellphone access other providers’ networks). Settings → Cellular Data → Cellular Data Options → Turn Data Roaming on. Had I done that on the deserted roadside, I’d have been able to tap into the same AT&T network my tow truck driver used to call from that location. Sigh: after talking to a friend who lives in Mullin, TX (also out in the boonies, not too far from our breakdown location, in fact) I learned that AT&T’s coverage in that part of Texas is much better than Verizon’s (the provider from whom Spectrum purchases their nationwide coverage). Good to know! Now you know, too…


22572 Explorer Tabs Causing Problems

Wow! When I read about the new tabbing mechanism in Windows Explorer in the latest Dev Channel build, I couldn’t wait to try them out. Alas, they appear broken on both of my test PCs. In fact, they don’t behave at all as described in recent articles from WinAero and WindowsLatest. On those PCs, alas, 22572 Explorer tabs causing problems is the best I can describe my own experience.

What 22572 Explorer Tabs Causing Problems Means (to Me)

My symptoms are as follows:

1. I don’t see the iconography and layout that the afore-cited stories show. Instead i get a duplicated and somewhat mixed-up title bar:

22572 Explorer Tabs Causing Problems.dup-titles

Click item for full-sized view to show garbled text at left in upper nav/title bar, with lower nav/title bar beneath.

2. As I try to use the control keys for tabs (CTRL+T, CTRL+W, etc.) File Explorer crashes pretty regularly. While creating new tabs (CTRL+T) does something, it does not create tabs across the top of the UI as you’d expect it to. Closing tabs (CTRL+W) is as likely to crash Explorer as it is to close the duplicate title bar. Other tab controls (CTRL+Shift+Tab, etc.) do nothing visible.

3. I can use only the “lowest title bar” (the bottom one) actively. The others do not respond to mouse or keyboard activity.

Both of my test PCs look and behave exactly the same way. I’m tempted to do a clean install (or spin up a pristine VM) to see if that fixes things. But I don’t have time to do that today (other tasks loom large on my schedule. Sigh).

Something’s Busted…

It seems clear that further work is needed from MS to get things straightened out. Or, it could be, I’ve hit some kind of fatal interaction with something else I have installed on my test PCs. I’m hoping I’m not the only Insider who’s experiencing these difficulties. Otherwise, my life is about to get a whole lot more interesting.

We’ll have to wait and see what kinds of reports come in from other 22572 users. Rest assured, I’ll be keeping a close watch on this to see what’s happening, and what’s reported, around the symptoms I’m seeing





MSA Login Doesn’t Connect Via RDP

Here’s an interesting problem that I apparently share with lots of people. Try searching on “can’t login to RDP” or “MSA login to RDP doesn’t work.” You’ll see what I mean. For me, MSA login doesn’t connect via RDP from my trusty Win10 production desktop to my new Ryzen 5800X build. Sigh.

So, of course I went through all kinds of contortions and research to try to get it working. I tried a variety of GPO settings, registry hacks and more, all without getting any love.  I spent 45 minutes trying to make this work to no avail. Even though I double-checked my passwords (and in one case, reset it just to make darn sure) I kept getting errors. Either “The password used to connect to the remote PC didn’t work” or “The credentials didn’t work” (RDP app and mstsc.exe, respectively).

MSA Login Doesn't Connect Via RDP.rdp-app-error

Words alone can’t convey the frustration in using a known, good, working password and getting such an error. Ouch!

When MSA Login Doesn’t Connect Via RDP, Use Local Account

Then, in several of the posts I read online, I noticed that similarly afflicted individuals succeeded in opening an RDP session using a local (client) account. So I set up a local account on the client PC using the “Add account” facility in Settings → Accounts → Other Users. Hint: you have to say you don’t know the user’s sign-in info to get to the right screen, where you choose the “Add a user without a Microsoft account” (MSA) to create a local account. Sigh again.

So, I created an account named LocalU, and then promoted it to Administrator status. Then, on my next RDP attempt into that PC the login succeeded using that account name and its associated password.

Even though you can’t always make Windows do exactly what you want, you can often find a way to get what you need through some workaround. This is actually a pretty good example. I can’t say I’m happy about this (and plan to report it to Feedback Hub next). But at least I can RDP into my new desktop. This will be very important when I start migrating files and stuff from the current production desktop to what will be my new production desktop next month.

Stay tuned! I’ll keep you posted as things progress in their usual “two steps forward, one step back” fashion. Should be fun…