Windows 10 Insider Preview Dev Build 21286.1 (RS_PRERELEASE) - Jan. 6 Insider

rseiler said:

I think you'll be interested in this, from your doppelganger:
https://aka.ms/AAas1m2

He had to do a refresh install, which is pretty severe. I wouldn't do it, but if yours is a young/uncomplicated install or you're the type who does a clean install at the drop of a hat (some people do!), you might consider it.

Thanks, rseiler! Mine is a fairly mature install...really, I agree with you about not doing it--there's no reason to do it because then there's the "next time" this happens, and so on...And I think what if I did that...and then the clean installation bonked out, too...? Nah...this build works too well to do that.

Yes, that guy's experience has mirrored my own precisely! You know Microsoft will have to fix it--whatever "it" is--as they can't release a commercial version of a Win10 upgrade that forces people to clean install...I don't think that would go over very well... I even disconnected or disabled all the devices I could, removed the existing drivers so that the install could put in whatever it wanted, but no dice--same error, same gsod, all of them failing at 48%, etc. But no problems all year long up through 20270.1 without me touching anything. I even clocked the ram down and disabled XMP, set everything to default settings--didn't make a bit of difference. I even uninstalled a lot of stuff through programs and features if I even thought it might have contributed--didn't change a thing.

They have to know what it is...I'm not even going to attempt another build until they clearly state they think they've fixed it.

MikeMecanic said:

I did have a couple GSOD in the 202xx cycle with a similar error. In order to force it, retry with the ISO and use CTRL+ALT+DELETE continuously (until restart) in the GSOD to resume the upgrade.

Hope this will help,

Thank you! You know what, I did that two different ways--the first way as you suggested, the second way by hitting the hardware reset to force a reboot--both times when the system rebooted it informed me it was reinstalling my previous build 20270.1. Went straight there. But I think it's worth another shot...Oh, joy...! If things should screw up royally I have a Macrium Reflect backup of the boot partition I can restore...but so far I haven't had to use it.

I may try this again to test the keyboard theory as I'm not sure if I waited until the GSOD hit before forcing the reboot! I'll report if it helped--thanks again for the suggestion...I even tried the SHIFT key, CTRL key, all the keys I've known to bypass stuff in Windows versions before--just nothing.

I am doing all of this...strictly in the interests of science (and boredom)...of course...

None of my own suggestions, or the ones kindly advanced by my gracious friends here, had any effect. But...

I've written several hub bug reports concerning my failures with every build coming after 20270.1. Shortly after I installed 20270.1 on Dec 3 for the first time, I purchased a second NVMe drive for my system--a Samsung Pro 980 500GB (running PCIe4) NVMe drive, which became my boot drive, replacing my former boot drive, a Samsung EVO 960 250GB (running Pcie3) NVMe drive. The 960 was repurposed as a data and programs drive. The 980 got the primary NVMe slot, moving the 960 to the secondary NVMe. Until today, no Win10 iso or Win10 WU version of a build beyond 20270.1 would install, as outlined in my previous hub posts and here.

What happened differently this time was only one thing: I launched the install ISO from the 980 Pro today instead of from the 960 as I had done previously! I think the install program at the 48% mark was getting confused as to which NVMe drive it should install to, thus stalling at 48% with every build and failing.

Launching the install from the boot drive did the trick, apparently, clearing up the confusion--I suppose.

All I did this time was move the .iso to my boot drive (on a hunch) and launch the install from there, and as I waited for the 48% mark to appear so that I could try Ctrl/Alt/Del to try and bypass it--I looked up and suddenly I was sitting at 88%.... No stall, no problem, not even an inkling. Very fast--took ~10 minutes or so. Normal, in other words.

The only thing I can come up with is that the WU install routine--same as the iso install routine, imo--was getting confused as to which NVMe drive to finish installing to--and failing at that point. That's all that makes sense to me right now, anyway.

The Problem is, how does that explain all of the WU failures after 20270.1? I don't know. I wonder if my GPT formatting of the 960 EVO is somehow causing the install routines to get confused as to which NVMe drive is the boot drive? I've got 7 physical drives all formatted GPT which are formatted into 10 separate partitions (I count all the little partitions on C:\ as a single partition)...Up to today I always mount the installation iso on a partition apart from C:\. I thought, "Well, haven't tried that..." so I did and the build installed.

So, I'm now running 21286.1 without a problem...but I am wondering what will happen with the next WU build. Guess I'll find out soon, eh?... The fun is nonstop!