Failed automatic update - KB4489899 and KB4486553

Anonymous
2019-03-12T20:07:09+00:00

2019-03 Cumulative Update for Windows 10 Version 1809 for x64-based Systems (KB4489899) -Error 0x8007371c

2019-02 Cumulative Update for .NET Framework 3.5 and 4.7.2 for Windows 10 Version 1809 for x64 (KB4486553) -Error 0x800703f1

These two automatic updates failed.  Any ideas?

Thank you.

Taner

Windows for home | Windows 10 | Windows update

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

61 answers

Sort by: Newest
  1. Anonymous
    2019-05-27T09:20:55+00:00

    I think that is too much a wreck to fiddle with. But...

    Oh, that's right, I forgot the MSR partition which is not visible in Disk Management. So, it is partition 3 that is your EFI partition, which holds the BCD & other important boot files. When you moved the EFI partition, it lost its identity. I think it was "Troubleshoot > Advanced Options > Startup Repair" that brought mine back. Did you try that? Otherwise try Set ID...

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc753840(v=ws.11)

    Set ID

    Open an Administrator Command Prompt, & enter...

    DiskPart

    Select  Disk  3

    List  Part

    Select  Part  3

    **Set ID=**c12a7328-f81f-11d2-ba4b-00a0c93ec93b

    Detail  Part

    Exit

    If that doesn't error out, Detail Part should now show EFI has its identity back. But you may still have to do a Startup Repair afterward to have Windows recognize it.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2019-05-27T07:09:05+00:00

    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.

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2019-05-26T21:24:41+00:00

    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.

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2019-05-26T07:59:20+00:00

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

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2019-05-25T15:05:17+00:00

    "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.

    Was this answer helpful?

    0 comments No comments