Interactive Troubleshooter

Published: Sep 10, 2026

UEFI Boot Device Not Found After Clone

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Comprehensive root-cause diagnostic tree to resolve non-bootable storage drives after disk cloning. Fixes missing EFI system partitions, missing NVRAM firmware boot entries, BCD pointing errors, and MBR/GPT partitioning scheme mismatches.

Full Diagnostic Tree & Step-by-Step Overview

What specific error message or system state occurs when attempting to boot from the cloned drive?

Firmware displays 'No Bootable Device Found' or boots directly into BIOS Setup utility.
Windows Boot Manager loads, but halts with BSOD Error Code 0xc000000e or 0xc0000225.
System attempts to boot, but displays a black screen with a blinking cursor or 'Operating System Not Found'.
Windows starts loading (spinning dots appear), but crashes with INACCESSIBLE_BOOT_DEVICE BSOD.

What is the structural condition of the partition table on the cloned drive?

The source drive was MBR formatted, so the cloned drive lacks a GPT EFI System Partition (ESP).
The cloned drive is GPT formatted, but the EFI partition was omitted during partition-only cloning.
The EFI System Partition exists, but motherboard NVRAM has no registered boot entry for bootmgfw.efi.

Converting Cloned MBR Drive to GPT and Creating EFI Bootloader

Solution:

Root Cause: Legacy MBR Partitioning Scheme Incompatible with Pure UEFI Firmware Mode

When cloning an older operating system installation structured around Legacy Master Boot Record (MBR), the disk lacks the GUID Partition Table (GPT) structure and the 100MB FAT32 EFI System Partition (ESP) required by modern UEFI firmware. Modern systems configured in pure UEFI mode (CSM/Legacy Boot disabled) bypass MBR Sector 0 boot code execution entirely, searching strictly for a valid FAT32 volume containing \EFI\Boot\bootx64.efi or \EFI\Microsoft\Boot\bootmgfw.efi.

# Diagnostic Verification:

Boot into a Windows Installation Media environment and open Command Prompt (Shift + F10).

Execute diskpart, run list disk, and check if the target cloned disk has an asterisk (*) under the Gpt column. If blank, the drive is MBR.

# Step-by-Step Fix:

1. Convert Disk Partition Style without Data Loss:

Run the MBR2GPT conversion validation tool in Command Prompt:

cmd
     mbr2gpt /validate /disk:0 /allowFullOS

If validation succeeds, execute the non-destructive conversion:

cmd
     mbr2gpt /convert /disk:0 /allowFullOS

2. Re-assign and Populate EFI System Partition:

Enter Diskpart to confirm partition creation:

cmd
     diskpart
     select disk 0
     list partition

Locate the newly created 100MB System Partition (FAT32), select it, and assign a drive letter:

cmd
     select partition X
     assign letter=S
     exit

3. Generate New Bootloader Environment:

Write clean UEFI boot files from the Windows directory to the new EFI volume:

cmd
     bcdboot C:\Windows /s S: /f UEFI

# Prevention & Long-Term Monitoring:

Always perform full-disk sector or disk-level clones rather than individual volume clones when migrating OS installations to modern NVMe/SATA SSDs.

Manually Recreating Missing EFI System Partition (ESP)

Solution:

Root Cause: Omission of EFI System Partition During Volume-Level Cloning

Cloning software configured to copy only the primary OS partition (C:) leaves behind the original drive's hidden 100MB FAT32 EFI System Partition. Without this partition, the destination drive contains Windows kernel binaries (ntoskrnl.exe), but lacks the initial boot manager binary, BCD hive, and boot sector certificate signatures scanned by UEFI motherboard firmware during Power-On Self-Test (POST).

# Diagnostic Verification:

Launch diskpart from Windows PE, select the target disk, and run list partition.

Verify that only an OS NTFS partition (and optional recovery partition) exists, with no hidden 100MB–500MB System partition formatted in FAT32.

# Step-by-Step Fix:

1. Shrink Windows Partition to Allocate Space:

Open Command Prompt via WinPE media (Shift + F10) and launch diskpart:

cmd
     diskpart
     select disk 0
     list volume
     select volume C  # Select primary Windows partition
     shrink desired=200 minimum=100

2. Create and Format EFI System Partition:

Create a dedicated FAT32 volume in the unallocated space:

cmd
     create partition efi size=100
     format quick fs=fat32 label="System"
     assign letter=S

3. Build Boot Files and BCD Store:

Re-synthesize boot infrastructure:

cmd
     bcdboot C:\Windows /s S: /f UEFI

Unassign drive letter and exit:

cmd
     select volume S
     remove letter=S
     exit

# Prevention & Long-Term Monitoring:

Select 'Disk Clone' instead of 'Partition Copy' in imaging applications like Macrium Reflect or Acronis Cyber Protect to ensure system structures are included.

Registering UEFI NVRAM Boot Entries via BCD Boot and Firmware Interface

Solution:

Root Cause: Stale NVRAM Boot Path Register References

UEFI boot options do not rely solely on partition structures; motherboard Non-Volatile RAM (NVRAM) maintains explicit hardware device paths pointing to specific disk GUIDs and partition unique identifiers (PARTUUIDs). When replacing a drive, the motherboard NVRAM holds reference identifiers to the old drive hardware signature. Even though the cloned drive has identical files, the firmware ignores it because its physical PARTUUID signature differs.

# Diagnostic Verification:

Boot into BIOS Setup Utility (F2/Delete).

Check Boot Priority List: The cloned drive is visible as a physical storage drive under SATA/NVMe options, but missing under the 'UEFI Boot Devices' category.

# Step-by-Step Fix:

1. Force NVRAM Path Registration via Windows PE:

Boot using Windows Installation USB, open Command Prompt (Shift + F10).

Identify drive letters for Windows and EFI partitions:

cmd
     diskpart
     list volume

Run bcdboot with the /p flag to force explicit NVRAM boot entry registration:

cmd
     bcdboot C:\Windows /s S: /f UEFI /p

2. Alternative: Manual UEFI Boot Option Addition via BIOS Setup:

Enter motherboard UEFI settings.

Navigate to Boot Settings > Add New Boot Option.

Name the entry Windows Boot Manager.

Select the target drive partition and path manually: EFI\Microsoft\Boot\bootmgfw.efi.

Save settings (F10) and restart.

# Prevention & Long-Term Monitoring:

Disconnect the original source drive prior to performing the first boot sequence on the newly cloned drive to prevent NVRAM identity collisions.

What is the primary status or fault condition indicated by the BCD Blue Screen error?

Error 0xc000000e: 'The Boot Configuration Data for your PC is missing or contains errors'.
Error 0xc0000225: 'A required device isn't connected or can't be accessed'.

Rebuilding Corrupted Boot Configuration Data (BCD) Store

Solution:

Root Cause: Hardcoded Disk Signature Mismatches inside BCD Object Parameters

The Windows Boot Configuration Data (BCD) registry hive contains object entries like {bootmgr} and {default} that use disk signatures and partition offset values to locate winload.efi. Cloning changes physical disk identifiers, causing BCD parameters to point to non-existent drive signatures, resulting in immediate boot failure before kernel initialization.

# Diagnostic Verification:

PC successfully initializes UEFI firmware, displays the blue recovery screen, and explicitly cites file \WINDOWS\system32\winload.efi with error code 0xc000000e.

# Step-by-Step Fix:

1. Mount the EFI System Partition:

Boot into WinPE Command Prompt.

Assign drive letter to FAT32 system volume:

cmd
     diskpart
     select disk 0
     select partition 1  # Verify FAT32 volume
     assign letter=S:
     exit

2. Purge Existing BCD Registry Hive:

Navigate to the Microsoft Boot folder on the hidden EFI partition:

cmd
     cd /d S:\EFI\Microsoft\Boot\
     attrib -h -r -s BCD
     ren BCD BCD.old

3. Reconstruct Clean BCD Entry:

Rebuild BCD pointing to the correct active Windows installation:

cmd
     bootrec /rebuildbcd

When prompted Add installation to boot list?, type Y and press Enter.

Alternatively, force clean synthesis:

cmd
     bcdboot C:\Windows /l en-us /s S: /f ALL

# Prevention & Long-Term Monitoring:

For detailed Microsoft guidelines on BCD command parameters, consult the Microsoft Official Support Documentation.

Perform system imaging utilizing VSS (Volume Shadow Copy Service) rather than direct raw physical disk block dumps.

Fixing BCD Volume Guid Path Mapping and Active Partition Conflicts

Solution:

Root Cause: Invalid Volume GUID Association Post-Migration

Error 0xc0000225 indicates that Windows Boot Manager located the BCD file, but the BCD store's internal parameters (osdevice and device) point to a partition GUID (unknown) that does not match the cloned OS partition on the destination disk.

# Diagnostic Verification:

Execute bcdedit /store S:\EFI\Microsoft\Boot\BCD from WinPE.

Look at output fields for device and osdevice under *Windows Boot Loader*. If listed as unknown, path associations are broken.

# Step-by-Step Fix:

1. Inspect BCD Device Variables:

Open Command Prompt in WinPE and mount EFI partition to S:.

Query BCD settings:

cmd
     bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum

2. Re-link BCD Device Variables to Correct Drive Letter:

Execute commands to re-map load paths directly to the OS drive letter (typically C: within WinPE):

cmd
     bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {default} device partition=C:
     bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {default} osdevice partition=C:
     bcdedit /store S:\EFI\Microsoft\Boot\BCD /set {bootmgr} device partition=S:

3. Verify Integrity and Reboot:

Re-verify entries by re-running /enum and confirm paths point to partition=C: and partition=S:.

# Prevention & Long-Term Monitoring:

Avoid keeping both source and target drives plugged in simultaneously during initial boot up to prevent volume path confusion.

What underlying legacy setting or drive signature issue is causing the boot halt?

Motherboard BIOS is configured in CSM/Legacy mode while cloned drive is GPT formatted.
Both original and cloned drives are installed simultaneously, causing a Disk ID Collision.

Reconfiguring BIOS Firmware CSM/UEFI Execution Modes

Solution:

Root Cause: CSM/UEFI Mode Mismatch in System Firmware

When a GPT-partitioned drive is cloned, it requires the motherboard Compatibility Support Module (CSM) to be disabled so UEFI native boot drivers handle OS handoff. If BIOS settings default to 'CSM Enabled' or 'Legacy Only', the system attempts to read Master Boot Record execution code from Sector 0, hanging on a black screen with a blinking cursor.

# Diagnostic Verification:

Access BIOS setup screens during power-on.

Check option: Boot Mode, CSM Parameters, or Storage Option Control.

# Step-by-Step Fix:

1. Adjust CSM and Secure Boot Settings:

Enter BIOS setup (F2, F12, or Del).

Navigate to Boot or Security menu.

Set CSM (Compatibility Support Module) to Disabled.

Set Boot Mode Select to UEFI.

Set OS Type to Windows UEFI Mode.

2. Verify Storage Controller Configuration:

Navigate to Advanced > Storage Configuration.

Ensure controller mode is set to AHCI or NVMe / RAID matching the source installation.

3. Save and Exit:

Save changes (F10) and restart system.

# Prevention & Long-Term Monitoring:

Ensure system BIOS is updated to the latest stable release prior to disk upgrades to maintain option compatibility.

Resolving Disk Identifier (Signature) Collisions in Windows

Solution:

Root Cause: Windows I/O Subsystem Disk Identifier Collision

Every hard disk drive contains a unique 32-bit Signature (MBR) or GUID (GPT) written into header sectors. Sector-by-sector disk cloning creates an exact duplicate of this signature on the destination drive. If both original and cloned drives remain physically connected when booting Windows, the Operating System detects two identical storage GUIDs on the PCI bus, offline-mounts one drive, and drops driver handles, freezing execution.

# Diagnostic Verification:

System hangs on boot if both old and new drives are attached, but boots fine if either drive is connected independently.

# Step-by-Step Fix:

1. Physically Isolate the Cloned Drive:

Power off PC and physically disconnect the old source drive.

Attempt to boot using only the new cloned drive. If it boots successfully, format or alter the signature of the old drive.

2. Change Signature on Secondary Drive via WinPE:

Connect the old drive via an external USB adapter after booting, or use WinPE Command Prompt.

Launch diskpart:

cmd
     diskpart
     list disk
     select disk 1  # Select the secondary/old drive
     uniqueid disk  # View current signature
     uniqueid disk id=A1B2C3D4  # Assign new random hexadecimal ID
     exit

3. Online the Secondary Drive:

Open Windows Disk Management (diskmgmt.msc) in main OS and set the secondary disk to Online.

# Prevention & Long-Term Monitoring:

Always disconnect source storage media immediately following completion of disk imaging or cloning procedures.

What storage mode and AHCI/NVMe/RAID driver issue is triggering the kernel panic?

Storage controller mode was changed (e.g., AHCI to RAID/VMD) during installation on the target system.
System was cloned to an NVMe drive, but lacks required boot-phase storage controller drivers.

Injecting AHCI / Intel RST VMD Storage Controller Drivers into Windows Offline Image

Solution:

Root Cause: Missing Boot-Critical Storage Controller Driver (`storahci.sys` / `iaStorAC.sys`)

During initial Windows initialization, the kernel loads critical boot-start drivers required to communicate with storage bus hardware. If the destination motherboard uses Intel RST VMD or RAID mode while the cloned OS installation has those drivers disabled in favor of standard AHCI, the kernel fails to mount the root file system, producing an INACCESSIBLE_BOOT_DEVICE blue screen.

# Diagnostic Verification:

Windows splash screen appears for a few seconds before crashing with Stop Code INACCESSIBLE_BOOT_DEVICE.

# Step-by-Step Fix:

1. Force Safe Mode Start via BCD:

Boot into Windows Installation USB, open Command Prompt (Shift + F10).

Enable Safe Mode boot flag:

cmd
     bcdedit /set {default} safeboot minimal

Reboot system into Safe Mode. Safe Mode forces Windows kernel to re-scan storage buses and load default AHCI/RAID storage drivers.

Once in Safe Mode, open Command Prompt as Admin and remove the flag:

cmd
     bcdedit /deletevalue {default} safeboot

Restart normally.

2. Inject Storage Drivers manually via DISM (If Safe Mode fails):

Obtain .inf storage drivers (e.g., Intel RST VMD drivers) from motherboard vendor.

Extract drivers to USB media (e.g., D:\Drivers).

Inject driver into offline Windows image via WinPE:

cmd
     dism /Image:C:\ /Add-Driver /Driver:D:\Drivers /Recurse

# Prevention & Long-Term Monitoring:

Match target platform BIOS SATA/NVMe controller settings to source configuration prior to performing clones.

Enabling Boot-Start Registry Drivers for NVMe Storage Controllers

Solution:

Root Cause: Disabled NVMe Storage Bus Controller Start Type in Windows Registry

When cloning an OS from an older SATA SSD or HDD to a high-speed PCIe NVMe SSD, the native Windows NVMe driver (stornvme.sys) service start type in the offline registry hive might be set to 3 (Manual/Demand) or 4 (Disabled) instead of 0 (Boot Start). The kernel cannot mount the physical NVMe device during initial boot phase.

# Diagnostic Verification:

Target storage drive is a modern M.2 PCIe NVMe SSD migrated from a SATA drive.

System fails to boot with INACCESSIBLE_BOOT_DEVICE.

# Step-by-Step Fix:

1. Load Offline System Registry Hive:

Boot using WinPE media and open Command Prompt (Shift + F10).

Run regedit to launch Registry Editor.

Highlight HKEY_LOCAL_MACHINE on the left pane.

Click File > Load Hive... and navigate to C:\Windows\System32\config\SYSTEM.

Name the loaded hive OFFLINE_SYSTEM.

2. Modify Driver Start Configuration Keys:

Navigate to HKEY_LOCAL_MACHINE\OFFLINE_SYSTEM\ControlSet001\Services\stornvme.

Locate the Start DWORD value in the right-hand panel and double-click to edit.

Change value data from 3 or 4 to 0 (Hexadecimal).

Navigate to HKEY_LOCAL_MACHINE\OFFLINE_SYSTEM\ControlSet001\Services\storahci and set Start to 0.

3. Unload Hive and Save Changes:

Click on OFFLINE_SYSTEM folder under HKEY_LOCAL_MACHINE.

Click File > Unload Hive....

Close Registry Editor and restart system.

# Prevention & Long-Term Monitoring:

Enable generic NVMe controller drivers prior to executing drive migration tools across differing storage bus architectures.

Related Diagnostic Guides

Dual Monitor Mouse Gets Stuck: Alignment Fix

Printer Prints Gibberish: PCL vs PostScript

BIOS Update Failed: Recovery Without Brick

Embed Guide on Your Website