Failed automatic update - KB4489899 and KB4486553

(1) OK. It's a sin that Startup Repair failed when you needed it. One could wish it would either make a repair or declare it couldn't, but not crash. But now that EFI is recognizable (which cured Windows Update), let us see whether Startup Repair will run & what "SrtTrail.txt" looks like. It won't hurt, & the file is small enough to copy/paste.

(2) I don't like a second flip flop of your NVMe drive numbers. I can't think of a reason for it. To my understanding: BIOS is first to put numbers on them, & that is determined by which port they are plugged into. Unless you switch them in the ports or remove one, I'd expect the numbers should stay the same each boot. I'm not sure whether Windows uses the numbers BIOS assigned or discovers them for itself. But I'd think they also would be assigned by the order they are in the ports each boot. Since the numbers can legitimately change by removing, adding or switching drives, I guess it doesn't matter that they change inexplicably too - just remember to do a List Disk in DiskPart to see which is which before doing something destructive like "clean" which would wipe the drive.

The BCD Boot Manager device entry showing HarddiskVolume9 is saying that is the partition that held the boot manager at boot. If EFI is being used, it should point to it. If there were no EFI, I would expect it to point to the Windows partition (C:) which can sometimes double as the system partition. Check it immediately after a boot. If it points to neither of those, maybe BIOS is achieving a boot without a boot manager at all.

Go into BIOS, & report whether it is set to boot to the Windows boot manager (bootmgr) or directly to the SSD.

(3) If 1903 comes in through Windows Update, its unlikely to put EFI where it belongs. But it may give you a recovery partition. OK, wait & see.

(1) Remember that I ran Startup Repair before I used Set ID to relabel the EFI partition. I suspect that it just failed because it couldn't find an EFI partition at all (and thus had nothing useful to dump to the logfile). Now that the system is (apparently) working properly, I'm inclined to leave well enough alone.

(2) Curiously, the disks have swapped again - the system drive is now Disk3 and the other NVMe drive is Disk4. There are definitely 9 partitions counting from Disk 0 to Disk 4 though (see below screenshot), so that's consistent with BCDEdit's labeling from yesterday. Reminder: Disk0 is a SATA SSD, Disks 1 and 2 are SATA HDDs, Disks 3 and 4 are M2 NVMe.

Though, even more curiously, BCDEdit still thinks that it's partition 9 today, despite the system drive being Disk 3 again:

I haven't rebooted since yesterday though, just let it come in and out of sleep mode.

(3) I agree, but for now I want to wait and see what happens with future updates. Also, even though there aren't a lot of things to reinstall, it's still annoying enough that it's worth avoiding. If 1903 has issues installing, then it's easy enough to download the media creation tool again and then wipe/reinstall directly to 1903, and I can create the recovery partition then.

(1) It sounds like you really do have a Startup Repair problem. Can you run it again & report exactly what does appear on the screen? If it works, you should get the screen I copied off TenForums - & a "SrtTrail.txt".

(2) Oh, gosh - you show "HarddiskVolume9" in BCDEdit, where I expected "...3". A little research...

http://diddy.boot-land.net/bcdedit/files/device.htm

Devices

...says it's actually counting all the partitions of all disks until it reaches the partition that holds the boot manager, which is EFI. So, you must have other hidden partitions (besides the MSR) that won't show up in Disk Management. Let us see...

DiskPart

List Disk

Select Disk 0

List Part

=== repeat last two for disks 1-4 ===

Exit

Counting down from the top, I expect 8 partitions to precede EFI. This will prove definitively (if it hasn't already been) that Windows is using that EFI to boot & your BIOS is NVMe-boot capable.

(3) I think the best way to get a recovery partition now is to do a clean install. It is good to have the partition as it has options not as easily available from external media. A clean install will also put your EFI in the spot it belongs. You said, you have no big installs of 3rd-party stuff to do afterwards - so, why not? When 1903 comes in shortly as an upgrade, it will appreciate a neat & orderly partition structure to work with.

(1) Yes, I suspect that the drives swapping was just due to the BIOS update.

(2) That log file doesn't exist; the \LogFiles\ folder doesn't have a \Srt\ subfolder. I also don't remember it mentioning a log file on the error screen, but I can't be sure.

(3) Yep, have rebooted a few times without issue now.

(4) Updated BCDEdit below.

(5a) Nope, the only thing in tat Recovery directory is a ReAgent xml file.

(5b) Fails, output shown below

I should add that I went back into DISKPART to see what that produced, and got the following results:

So DISKPART is aware that it's FAT32, even though Disk Management isn't. And DISKPART thinks it's Volume4 when BCDEdit thinks it's HarddiskVolume9, though I'm not sure those volume numbering schemes are necessarily consistent with one another.

(1) I can think the flip-flop of your two (I guess) NVMe devices is attributable to going from the oldest to the latest BIOS version. There must have been many tweaks between the two not described fully in the little blurbs.  I wouldn't worry unless it happens again & for no apparent reason. I have a hunch Disk 4 may be the better of the two M2 slots you've got. I'm thinking it might be the lower of these, & that the top one might not be "x 4"...

1 x M.2 Socket 3, with M key, type 2242/2260/2280 storage devices support (both SATA & PCIE mode)*^2^

1 x M.2 Socket 3, with M key, type 2242/2260/2280/22110 storage devices support (PCIE 3.0 x 4 mode)

Now that Windows Update is working again, I would go back to the site & take all the drivers that have a greater version than shows up in Device Manager. Maybe click for them first in Device Manager (search automatically). Sometimes that will get one of even a greater version

• but the dates at your site are impressive.

(2) Startup Repair says it "couldn't repair" even when there was nothing to repair in the first place. Here is a picture stolen from Shawn Brink...

https://www.tenforums.com/tutorials/27649-run-startup-repair-windows-10-a.html

Run Startup Repair Windows 10

Go to "C:\Windows\System32\Logfiles\Srt\SrtTrail.txt" in File Explorer to see what is in there. Or ask Cortana for "SrtTrail.txt". Does it say anything even more suspicious inside?

(3) I'm puzzled that "FAT 32" has dropped off your EFI. Have you rebooted to see whether it returns? Maybe the shock of that flip-flop confused it on the first boot. We could put a letter on it & see whether SFC will straighten it out. Also we must decide whether to leave well-enough alone or to move that EFI to its fit & proper place in front of the MSR. Likely it loses its identity again, but we know we can fix that.

(4) Well, let us see your "BCDEdit" now. Yours should show "HardDiskVolume3" where mine shows "...1".

(5)

(a) Do you have a WinRE.wim file at "C:\Windows\System32\Recovery"?

     That is an alternate location for the recovery environment.

(b) Whether it is there or not, what is the result of...

Open an Administrator Command Prompt, & enter "ReagentC  /Enable"?

If it reports success, what is the output of "ReagentC  /Info" now?