Windows Server 2012 R2 manual reparation of UEFI system bootloaders.

  • Sun 03 September 2017
  • Debug

tl;dr: ShadowProtect Recovery restore does not restore partition tables automatically.

Recently, I reconfigured a RAID array on a server. When a RAID configuration is deleted, the data on the volume is lost.

Intuitively, a backup of the system was taken and then was to be restored post of the new RAID configuration being implemented.

This was the job of Storage Craft's Shadow Protect - a system image can be generated, and then via a "Cross Platform Recovery Environment" (A modified CentOS 6 live image) can be used to restore this image.


For whatever reason, ShadowProtect stored the GPT bootloader partition as a VFAT volume instead of FAT32. My guess is this likely being an implementation anomaly of Linux interacting with a FAT32 filesystem. Just a guess.

Anyway, restoring the volume results in a situation where Windows will not boot and gives the error: "A required device isn't connected or can't be accessed0xc0000225"


A lot of guides online will tell you to use the following commands to fix this:

bootrec /ScanOS – Scans for compatible OSes.
bootrec /FixMbr – Writes a new master boot record to the HDD or SSD.
bootrec /FixBoot – Writes a new boot sector to the OS partition.
bootrec /RebuildBcd – Scans for compatible Windows installs and creates a new boot loader.

Big problem, these are for BIOS systems - not UEFI.

Older BIOS systems use Master Boot Record (MBR), the process starts by simply reading the first few sectors of the disk (where early stage code is stored).

Newer UEFI systems are capable of reading FAT file system "EFI system partitions". They do not rely on bootsector code at the beginning of a disk!


For further reading, check out this blog by Adam Williamson, the section under "EFI system partitions" pertains to the above specifically.

ShadowProtect restore complete - Windows doesn't boot.

Note: For those of you booting USB drives, you may need to enable CSM or change from UEFI to BIOS to get the USB to boot.

Boot into a Windows installer, go into the repair system menu, open a CMD shell, drop into DISKPART, select your disk and list the partitions.

This is what I got:


Partition 1 shows type as "Unknown", that's bad.

select partition 1
create partition primary
select partition 1
format fs=fat32 quick
list partition

Now it should look like this:


Partition 1 shows type as "Primary", that's good!

select partition 1
assign letter=a

list volume

You should get something like this:


Now you've got:

  • EFI System Partition on A:
  • System Reserved on D:
  • System Data (Windows Installation) on C:

Now it's a simple matter of running bcdboot with the correct arguments:

bcdboot c:\Windows /s a: /f UEFI


/s specifies where to put the boot files, /f specifies what firmware type (BIOS, UEFI, ALL)

Congratulations, you have fixed error "A required device isn't connected or can't be accessed0xc0000225".

Now reboot - make sure your system is in UEFI mode and load the disk.

UPDATE 12/09/17(DMY): Flagging Window GPT EFI System Partitions as Bootable with diskpart

Recall this command:


bcdboot c:\Windows /s a: /f UEFI

We had to manually mount the FAT32 EFI System Partition (ESP) on "A:" and instruct BCD to place the boot files there. If you dont, bcdboot would error: "The boot configuration data store could not be opened. The system cannot find the file specified."

Manually specifying the target "fixes" this, however the system is still unable to locate the data store on it's own. This is a problem if you attempt to install the Hyper-V service as the BCD record gets modified with hypervisorlaunchtype auto* - *if the system can't find the data store, the Hyper-V installation will fail with code 0x800f0922

So, running diskpart, selecting our disk, and listing the partitions gives up this.


Our ESP shows as PRIMARY and we want it to say SYSTEM. I assumed that bcdboot simply looked for the SYSTEM partition for the BCD store, this assumption turns out to be correct. Setting the "boot" flag on a partition makes its type SYSTEM.

DISKPART can set a boot flag by running the command ACTIVE. Sadly, if you attempt to use DISKPART, you'll get the following error:

The selected disk is not a fixed MBR disk. The ACTIVE command can only be used on fixed MBR disks.

There is an easy workaround for this, reboot into a live linux instance and use GPARTED to mark the partition as bootable.


Reboot back into Windows, running diskpart and listing your partitions shows SYSTEM type now.


Running bcdboot c:\Windows /f UEFI (note: without /s target) works now! The system can find the BCD data store automatically, concordantly Hyper-V installs successfully.