Cumulative Update borks system with Multiple drives inc SSD and UEFI

[HarryStottle]

I am an experienced victim of multiple generations of Windoze but this is a new one on me and google searching didn't find anything similar. I'm currently running 4 personal systems on 10 and managing several others.

Upgraded two of my systems to use 240Gb SSD drives as system drives with W10 a few weeks back and was very happy with the results. I've updated both a few times without difficulty.

Foolishly allowed one of them to update itself yesterday and let it reboot today. The boot obviously recognised the SSD drive and began booting but then decided the SSD drive was no longer the right one and prompted me to insert valid boot media.

Changed the SATA connections to make the SSD Drive 1. Changed the UEFI bios, to set the SSD drive as first and boot. No effect. Tried disabling UEFI. No effect.

Tried repairing using the same bootable usb stick I'd installed it from a couple of weeks ago. It claimed to be diagnosing the system and not only left it even deader than when I started but it even managed to corrupt the usb boot stick (I've just finished rebuilding it). When it woke up, it presented me with this information on screen: 00007779 0000DFAO 97C05400. Nothing more. Nothing less. (and google doesn't recognise that as any meaningful error code)

I'm pissed off but perfectly capable of starting from scratch and getting the bloody thing up and running again, but I'm looking for clues as to what may have happened and how to prevent it.

Fortunately one of the things I've learned since venturing into 10 is that, despite Microsoft's attempts to force updates down our throats, there are ways to prevent them (although not, unfortunately, to select the ones you want to allow and reject others) and, until I have some idea of what the hell is going on, I'll simply block them all, especially with my other SSD system.

I'm speculating that the problem arose because Windoze is trying to be too clever and updated the boot manager in the UEFI with the wrong drive information, partly because I deliberately left the previous system drive in place and it was in as drive 1 while the SSD was in as Drive 3.

Does anyone know how to reset a UEFI boot manager to point to the drive we want? Or whether is best to simply disable UEFI and rely on user choice?

All suggestions welcome

 

[HarryStottle]

Just spotted this post which might answer my question...

 

[Trouble]

It's likely that since the "old system drive" was left in the computer that it contains the EFI partition / BCD data / Windows Boot Manager.
I'm kinda surprised that you didn't just clone that to the SSD and then do the upgrade.
Can you remove the SSD, put the "old system drive" back to the way it was, connected as SATA 0 and set the BIOS back to UEFI or at least UEFI & Legacy if that is an option and see if you can boot the system or at least repair it.

 

[HarryStottle]

Thanks for the reply NW.
I actually rebuilt the system from scratch this afternoon. It doesn't take long on an SSD drive (basic OS is fully installed in less than 10 minutes) Cloning wasn't a preferred option. I was taking the opportunity for a fresh build. I did have a Paragon VD backup, which did fully restore the partitions, but it still refused to boot. Nothing I could do manually, even with all other drives disconnected, using fixboot and diskpart, could make the partition active and bootable. Ferinstance, when I used fixboot /rebuildbcd it found the OS on the restored drive and asked for permission to add it. I gave permission and it responded with "Requested system device not present" or something of that ilk. Googling that returned no hopeful solutions (everyone just said if you see that, it's time to rebuild, so I did)

I'm sure it was connected with the prior system drive still being present, although it no longer contained any system partitions as I'd wiped them. But it was still Disk 0 in the BIOS and the BIOS had UEFI enabled.

Anyway, after the rebuild, (but before I wasted any time installing my routine software) I let it perform the same update that broke it last night, under the new config, it worked like a charm.

Windows direct access to BIOS is a menace. It means even tools like Rollback can't help recovery after it breaks your system. Lesson 14983: Disable UEFI, control your own boot regime.

Got any thoughts on making Updates selectable? I've got it to the "All or Nothing" stage but we obviously need, occasionally, to allow the updates to take place...