![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hi all,
I haven't seen anything new from MSFT on this subject. I've continued some experiments on my own to learn a bit more about what's happening. The main obstacle to installing the patch is whether the system drive's "recovery partition" is large enough (768MB) for the installer to successfully complete putting the patch into a system. For one thing I've been looking at what it takes to create the "right" size Recovery partition at the time of installation. There might be later problems when a user attempts to re-install Windows 10 (often on Tech Support's advice). Is the re-install tool going to resize the recovery partition to the original size?
Starting with a newly "cleaned" (done by diskpart) drive (only drive in this system), I observe that the Windows 10 installer (from a Microsoft supplied Windows 10 image file) creates a 500MB recovery partition as the first partition on the drive. The installer creates 3 more partitions immediately after the first with no space between the partitions. Microsoft's manual patch to the fix is to create a 768 MB partition after all the other partitions since the first partition has no room to have its size increased in place. Afterwards there's a 500 MB empty partition in the first position on the disk. It also seems this partition should have a partition allocated for it because the patch installer tries to use the first Recovery partition it finds.
In one experiment I manually created a 250MB NTFS partition as the first and then let the installer create its usual partitions including a 500MB recovery partition as the second partition. After the install I followed MSFT's manual instructions up to removing the installer's own too small recovery partition along with my own 250 MB partition. I used MSFT's partition allocation script next and this produced the target partition size (768) in the disk's first position. The online patch successfully completes with this configuration.
I can't say more about the success of this effort because I discovered I was working with a broken SSD, and I've had to replace the drive. Not a Windows problem, a Linux installation using this drive also met with failure.
You can readily see what's on the system (C:) drive using diskpart or Disk Management. These will show you the drive's partitions including their sizes and order of placement. If you have a ~500MB Recovery partition and the urge to install the patch, then following MSFT's manual instructions will fix the problem.
While this patch doesn't seem to notice whether BitLocker is installed, you might be right about whether this patch is relevant to the Home edition. That the patch makes repeated efforts to install itself is likely another indication of MSFT doing inadequate testing before releasing the patch.
Good luck to us all.
art