Cumulative update KB5003214 fails to install

[Jauhar]

Hello Good afternoon Everybody ! Well unexpectedly ONCE AGAIN Windows cumulative update windows 10 version 21H1 build 19043.1023 failing to install after multiple attempts. This means this is the 4th update in last 3 months that causing severe headaches to Microsoft Users. Just 2 Weeks ago I moved front 20H2 to 21H1 and it went successful but then again the problem starting coming out of nowhere. Shout loud if you have been facing the same issue as I have been facing for quite sometimes now. Cheer Pals

[#2]

@A1-A1 

I mentioned previously I managed to do a clean install of Windows 10 Version 21H1 on a brand new clean 1TB drive.  I did make a mistake of not disconnecting my 😧 drive when I did the installation. Because of this, when I did a system image backup my 😧 drive was also backed up and there was no option not to select the 😧 drive.  It transpired my 😧 drive is now treated as a system volume because when I did the clean install of Windows some boot files found their way into the 😧 drive hence, my image back up took longer and used more drive space. I did a printscreen (see below) of my disk management console.

The C: drive is Boot, Page File, Crash Dump, Primary Partition and the 😧 drive is System, Active Primary Partition.  Both drives have MBR partitioning according to Minitool. You can also see the C:\ drive doesn’t show a System Reserve Partition, neither the 😧 drive shows any other partition.

So, can I disconnect my 😧 drive just to do a system image backup on the C:\ drive only and is there a way to disable the 😧 drive as a system volume without disconnecting it. Also, will Windows boots up without the 😧 drive connected ? The C: is already configured as the 1st boot priority after the DVD drive in the bios.

[#3]

I would risk disconnecting drive D - but it is certainly difficult to predict whether the system will boot, but reinsisting drive D again - should restore the system.
But I have never had such a problem .
, so it is not checked and you will do it at your own risk.

[#4]

@A1-A1 Noticed there are the three files in the 😧 drive that are treating this 😧 drive as a system volume when creating a system image backup:

Bootmgr

bootnxt

bootsect.bak

Is there any safe way to move or copy these 3 files to C: drive.

[#5]

But the recovery disk was created correctly - without these files?

[#6]

@A1-A1 No issues with Windows booting up - its pretty quick.  When I did a clean install of Windows I didn't disconnect my 😧 drive data HDD so some system files must have crept into this drive. The 3 system files I mentioned previously are in the root of the 😧 drive.  The system files in the root of the C: drive are AMTAG.Bin, Dumpstack.log.tmp, hiberfil.sys, pagefile.sys and swapfile.sys.

The recovery system image was created OK.  The image backup now includes the contents of the 😧 drive hence, it took longer to create and required more disk space. 

You can see from my disk management console screenshot that no separate system reserve partition is shown on either the C: or the 😧 yet Windows boots up with no issue. Using Minitool it told me both are MBR partitions. 

[#7]

This is great information!
Congratulations.

[#8]

@A1-A1 Just an update.  I managed to transfer all the boot system files from the D:\ drive to the c:\drive using cmd with admin rights with the following syntax

bcdboot c:\windows /s c:

There were two boot system files - bootmgr and bootnxt - left in root of the 😧 drive. These 2 files are copies of the ones transferred to the root of the C: drive by bcdboot. Because of this the 😧 drive still remained active. What I did next was to make the C:\drive active and the D:\drive inactive. By making the D:\drive inactive bootmgr and bootnxt no longer showed up in the root.  Restarted the PC and Windows booted up with no issues.