Failed automatic update - KB4489899 and KB4486553

Oh, I forgot to mention that. Yes, it's a UEFI bios and an EFI partition, and Disk 3 is GPT.

I don't remember which disk the Windows installer placed the EFI partition on initially, but it was one of the non-NVMe drives (Disks 3 and 4 are the NVMe drives, 0 is a traditional SSD, 1 and 2 are HDDs). Disks 0 and 2 are both MBR, while 1/3/4 are GPT.

I'm pretty sure the EFI partition was working correctly when it was on the other disk, I just didn't want it to be split up that way (in case I were to replace the other disk). I remember I had some trouble moving the partition, but eventually got it working, and it's been long enough that the details are fuzzy.

But my recollection is that the EFI partition was placed at the end of the original disk as well (probably because it already had partitioned space). So when I moved it to Disk 3, I just kept that the same.

So it sounds like increasing the size of that EFI partition won't help then, since 100 is standard. My next best guess is to nuke the entirety of Disk 3, unplug all of the other drives, and reinstall from scratch with only Disk 3 present to force the installer to keep everything on that drive. Unfortunately if I do that, I won't know until later whether it fixes my problem (e.g. will future updates also continue to fail?). So I'd like to try any solutions that don't involve a fresh install first, just in case that isn't going to fix the problem anyhow.

"My next best guess is to nuke the entirety of Disk 3, unplug all of the other drives, and reinstall from scratch with only Disk 3 present to force the installer to keep everything on that drive."

Yes, I would do that and I think the problem will be resolved.  If you try to fix things otherwise, you will end up wasting countless hours trying to figure out every little thing to see it will work.

Just form a partition at least 50 GB, and let windows do the rest.  It resolved my update problem.

Good luck.

Forgive me. I couldn't believe you that it was an NVMe problem, thinking no one would invent something that couldn't handle an EFI. And, indeed it can handle EFI - but older BIOS won't recognize the NVMe controller, so it cannot boot to an SSD that uses it. I guess you installed the NVMe & it didn't come with the computer & a BIOS that could see it. Therefore, Windows put EFI onto a separate partition - for the reason you said, not what I came up with.

I don't think the clean install I suggested would put EFI onto the NVMe SSD. But I wonder, did you clear it down to unallocated space & install into that the first time? Or did you create a partition that encompassed the entire SSD to install into? I don't know whether detaching all other drives would work. It might have worked for others for a different reason.

But I'm surprised your computer continues to boot now that EFI has been moved to the NVMe SSD. Let us see your BCD. At an Administrator Command Prompt, enter "BCDEdit". I expect yours to say the Boot Manager is located on HardDiskVolume2, which means partition 2. Since only one of your drives has two partitions, it has to mean BIOS sees the NVMe SSD now.

And let us see this...

DiskPart

Select  Disk  3

List  Part

Select  Part  2

Detail  Part

Exit

We will want to get yours to look like mine, & to move it in front of C: too.

Edit: You definitely need to make a Windows system image backup before moving EFI, though. That time I moved mine (with AOMEI Partition Assistant), it lost its type ID & Attrib. The computer booted into an automatic repair that failed, but offered an option to go into the on-board recovery partition (recovery environment - WinRE). There, I ran Startup Repair, which did fix the boot. I then used DiskPart to set the Attrib right. I'm hazy on whether I also had to fix the Type ID or whether it was Startup Repair that did that.

But I don't see that you have a recovery partition. Your WinRE may be in your C: partition, or it may not exist. In that case you must boot to one on external media. Do you know how to do that? It would also be necessary to get there to restore the system image, if that need be done. At an Administrator Command Prompt, enter "ReagentC  /Info". Does it say you've got an on-board WinRE...?...

It's a new system I built in March. Brand-new motherboard (Asus ROG STRIX Z39-E Gaming), and I decided to go with an NVMe drive to try it out. The BIOS is UEFI and was able to see the drive just fine. But what I learned from reading some other forums is that Windows for some reason doesn't like to install the EFI partition on one. Several other people reported the same sort of thing happening, where it would put the EFI partition on a different drive when installing Windows.

Note that I didn't make the partition first - I just booted off of the Windows Installer USB and pointed it at Disk 3 and let it do its thing.

I ended up having to do a bunch of work in diskpart to move the partition, and had the same experience as you - wouldn't boot off of the existing partition, so I had to repair it.

Regarding the command prompt handiwork, I've attached screenshots below. Here's the overview:

BCDEdit fails to run (Error: "The boot configuration data store could not be opened. The requested system device cannot be found."

DISKPART shows 3 partitions on Disk 3, as seen in the images.

-Part 1 is a 16 MB Reserved

-Part 2 is the 465 GB Primary (C:)

-Part 3 is the 100 MB Primary (EFI)

There is no WinRE. I can always do that from USB if needed (in fact, I'm fairly certain that's how I did it when I had to move the EFI partition in the first place).

If I do end up nuking the drive and reinstalling, I may add the recovery partition to that disk for convenience later. But I'm not really worried about a recovery image. There's nothing of value kept on the C: drive that cannot be fairly quickly reinstalled.

Images:

edit: after thinking about it more, the BCDEdit results could be the issue. Not sure how to fix that though, but willing to try if you have suggestions.

Someone someday should make a list of the reasons Windows would put its EFI on a separate drive. If Windows saw an EFI already existed elsewhere, it would want to use that. It doesn't like more than one in the system. That situation exists when one installs to a new drive while leaving the current installation still plugged in. But the install likely would end up in a dual-boot. That wasn't true in your first install, was it?

And I believe, if Windows can't find unallocated space for an EFI on the drive to which it is being installed, it will look elsewhere for unallocated space. That situation is realized when one creates a single partition encompassing the full  drive & installs into it. I think normally EFI would be omitted & C: would get the boot files & become the boot drive. But, I'm guessing, if it sees unallocated space on another drive, it would put the EFI there instead. You said, "I didn't make the partition first". Are you sure the NVMe hadn't come already partitioned - i.e., the line you clicked for the install said "unallocated space"?

Anyway, here is that computer's site...

https://www.asus.com/us/Motherboards/ROG-STRIX-Z390-E-GAMING/HelpDesk_Download/

ROG STRIX Z390-E GAMING

The specifications page shows it to be ready for SSD & to have sockets suitable for NVMe...

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)

But it may be able to see NVMe & still be incapable to boot from it. I saw one article deep down on the FAQs page that mentions NVMe, but doesn't say whether it can be booted. And I read each of the little blurbs for all the BIOS updates. Here is the latest one...

It doesn't mention NVMe - none of them did. But I would take it, if your version (shown in MSInfo32) is less than 1005. That's a good date & a great computer - I think ASUS would want to have its BIOS be NVMe boot capable having sockets for it. Here is how...

https://www.asus.com/us/support/FAQ/1012815

[Motherboard] ASUS EZ Flash 3 - Introduction

After that, I would redo the clean install. Things look too wrecked to try to fix that install any other way. I guess - maybe - unplug all the other drives. Maybe Windows is purposely putting EFI onto a separate drive because it doesn't check, but assumes BIOS wouldn't boot it otherwise. Then...

Ensure BIOS is set for UEFI mode. Boot to the Installation media with the UEFI boot option. Click "Install Now", then "Custom Install". At the "where do you want to install Windows" screen - delete both/all partitions on Disk 3 so that only unallocated space is left. Then select the unallocated space, & click next. This way should automatically create 4 partitions:  Recovery, EFI, MSR, & Windows. If that won't boot or create all 4 partitions, then plug back in the other drives, redo the install, & let it put the partitions where it will.

After the clean install, go back to the site & update all the drivers that need it.