KB4474419 will not install

Hi, Fix worked in my case. Thanks !

I followed those steps (from link submitted before) :

1. Temporarily assign a drive letter to the System Reserved partition from the "Disk Management".

2) Open an elevated command prompt and run fsutil usn deletejournal /N /D X: where "X" is the assigned drive letter of the "system reserved" partition.

3) Remove the drive letter to the "system reserved" partition (which should remain without assigned drive letter).

4. Launch the KB4474419 update

In my case, my system reserved partition is 350 MB large and was totally full.

Clearing the logs only cleared 40 MB (310/350). It worked anyway.

I have installed this system and several others myself using Windows installer. I perfectly remember that when you create partitions using this installer, it asks if you want to create a Reserved partition or not.

So I confirm that you can install Win 7 without any reserved partition using only the official tool (I've done this at least twice).

On earlier versions of the installer, the partition was 100 MB large only.

Sometimes I use Gparted to clear the disk before install. I had issues when trying to create Windows partition in Gparted before installing. The installer didn't accept the partition if I remember correctly.

Anyway, looks like you can create this partition without re-installing Windows.

Here

I tried your fix with the drive letter and fsutil just to have tried the only solution which is not smashing MBR.

I have the 100MB system reserved partition which was installed by Win7 Ultimate.

No other tweaks (you wrote about gparted ;-)  ).

The reserved partition has 71.6MB free from 99.9MB.

The above fix did NOT work on my dual boot system.

So I am still excluding KB4474419 from updates.

The problems with the April 2019 updates are showing, that MS has some problems here anyway.

Which means: waiting till MS fixes this mess.

I succeed with the update.

Go in BIOS, set the windows disk as first boot device.

Let the windows update reboot the computer as it likes.

When the windows update succeed, reboot to BIOS to set the "GRUB" (boot loader) disk back as the first boot device.

You get your multi-boot back to normal.

Well, if you are in my case, have one disk dedicated for Linux, and one disk dedicated for windows.

I had the same issue with Ubuntu being the Primary boot menu (grub as Active Partition; being the Primary Boot Drive in the BIOS.  My system is dual boot with Grub bootloader on one hard drive and Win7 MBR bootloader on the other drive. After switching the Primary boot device in the BIOS to my win 7 bootable drive, installing the update manually using KB4474419 MSU, letting the machine reboot using the Windows 7 boot drive he update went though no problem. It should also be noted that I have no 100MB Reserve Drive and instead windows is installed with the reserve drive Drive C.  All steps about 100MB reserve drive problems were not needed in order to install the update. I then switched back to the bookable MultiBoot Grub Partition is bootable though Grub.

My only thought or why this worked is Windows is looking to update code in MBR, boot sector or some code relating to how Windows is loaded after the POST of the BIOS  because all I did to get the update to work was change the boot drive in the BIOS.

I am still waiting for the April 2019 security update to be available on my system to see if the update goes though OK using Grub as my bootloader.

I am familiar with the process you described and know that it works for many who are dual-booting. The issue I have, as do some others who dual-boot, is that selecting to boot the Windows disk directly from within the BIOS fails. You end up with a GRUB rescue prompt. For some reason, the dual-boot setup we have requires the Windows installation to boot from GRUB. Windows will not boot without it in our case. Now I am sure this can be corrected by repairing the MBR using a Windows rescue disk, but I know from past experience that this will likely damage the GRUB bootloader, requiring that it then be reinstalled, which is straightforward enough, but my point is that it should not be necessary. A fully booted Windows should install the required updates, no matter how the OS is booted. This is something Microsoft should fix.

When you install the April update that includes the monthly security rollup, I would not be surprised if you have to go through the same process you did to get the March update. Again, this should not be necessary.

Possible solution for dual boot on same disk.

The idea came from Post #23 of the following forum and I simply provide further clarification:

https://www.sevenforums.com/windows-updates-activation/418834-unable-install-kb4474419-win7-x64-ultimate-3.html

I run Clover to dual boot (legacy boot) MacOS X (hackintosh) and Windows 7 on the same disk with MBR partitions. Initially marking Windows partition as Active caused me problem because the system failed to boot and I had to run Gparted to remove the 'active flag'. Then I remembered when I set up Clover to boot Windows, I needed to select the System Reserved partition (Windows) in order to work. So next I marked the System Reserved partition as Active and the system booted directly to Windows bypassing Clover. The update KB4474419 then went through successfully and subsequently KB4493472 as well. Finally I removed the active flag from the System Reserved partition and everything is back to normal with Clover menu coming up where I can choose to boot Windows or MacOS. I didn't bother to change the MacOS partition back to active as it doesn't seem to matter.

So in my case, it is a simple change without the risk of corrupting the original boot loader already installed. Hope this may also work for others.

I'm sick and tired of Windows expecting to be the only OS in the system.  This has happened on many Window updates in the past.  Have they not learned or just don't care!