Failed automatic update - KB4489899 and KB4486553

(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?

I agree the update problem appears to be gone & time will tell whether it comes back. Every one of your failed updates is superseded by something that did come in well, as you said. Whatever goodies were in the ones that failed have come in through its successor because these are all cumulatives.

Yes, Windows uses the BCD in EFI in carrying out the reboot involved in these cumulative updates. So, it looks like EFI has been fixed. But I'm working up a bigger post about that.