Recover INACCESSIBLE_BOOT_DEVICE after cloning or moving Windows

After a disk clone, image restore, move to another SATA/NVMe connection, or transfer to different hardware, Windows Boot Manager may find the installation but Windows loses access to the system volume during kernel startup. A clone can also omit the system partition, preserve stale BCD references, change a disk or partition identifier, or place Windows behind a storage controller for which the installation has no boot-critical driver. A clone that reaches the Windows logo and then black-screens with no code is a variation of this mechanism only when the source/target comparison demonstrates an incomplete clone, changed storage path, or missing payload; the black screen alone does not prove cloning caused it.

Searchable Windows error codes and exact messages

Use this procedure when the problem began immediately after cloning, imaging, restoring, changing the system disk, changing its port or slot, or moving the Windows installation to materially different hardware. The original disk or image should still be available as a rollback source.

Do not use it for a disk that disappears or fails diagnostics, a deleted ESP with no verified backup, a clean Windows installation that never booted, or a known RAID/VMD/IRST migration. Cross-hardware deployment and licensing can add requirements beyond boot repair.

The exact Windows build and clone application's internal method may remain unknown. The source and target disk identities, the target partition style, whether every required partition was copied, the new controller path, and whether the original installation still boots may not remain unknown.

• Windows Recovery Environment or current Windows 10/11 installation media
• The original disk or a verified restorable image
• A complete backup of irreplaceable data
• The target computer's supported storage/chipset driver when the hardware path differs
• Enough time to re-clone rather than improvising destructive partition changes

Disconnect the original system disk if testing the clone, but keep it unchanged and available. Disconnect unrelated disks so firmware cannot silently boot through an ESP on another drive. In WinRE, use W: only after detecting the Windows volume and S: only after detecting the intended system partition.

1. Record the full code, message, and named file.

2. Inspect disks and volumes:

   diskpart
   list disk
   list volume
   

3. Identify the target disk by model, capacity, and connection. Select the detected Windows volume and assign W if necessary:

   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   

4. Verify the installation:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\winload.*
   

5. Map that volume to its disk and inspect every partition:

   diskpart
   select volume <Windows-volume-number>
   detail volume
   select disk <target-disk-number>
   detail disk
   list partition
   

6. Compare the target with the source layout or image manifest. On a typical UEFI/GPT Windows disk, look for an EFI System Partition, Microsoft Reserved partition, Windows partition, and usually a Recovery partition. On BIOS/MBR, look for the intended active system partition plus Windows. Variations are legitimate; missing a required system partition is not.

7. Detect the boot architecture from the target disk:

   • GPT marked in list disk plus a small FAT32 ESP indicates UEFI.
   • MBR plus an NTFS active system partition indicates BIOS/MBR.
   • Do not change firmware architecture to compensate for an incomplete clone.

8. Assign S to the detected system partition and leave DiskPart:

   select partition <system-partition-number>
   detail partition
   assign letter=S
   exit
   

9. Preserve and inspect the existing BCD.

   UEFI/GPT:

   md W:\BootRepairBackup
   copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\BCD-after-clone-before-repair
   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v
   

   BIOS/MBR:

   md W:\BootRepairBackup
   copy S:\Boot\BCD W:\BootRepairBackup\BCD-after-clone-before-repair
   bcdedit /store S:\Boot\BCD /enum all /v
   

10. If the boot store is correct and the stop remains 0x7B, compare the target controller mode and hardware path with the source. A move from SATA to NVMe, one controller to another, or one computer to another can require a target-supported boot driver.

11. If the target disk or Windows volume is not consistently readable, stop. Re-cloning from a reliable source is safer than repairing an unstable target in place.

Branch A — Same computer, complete clone, stale or absent boot files

1. Confirm the correct Windows and system partitions as above.

2. Rebuild boot files from the cloned Windows installation.

   UEFI/GPT:

   bcdboot W:\Windows /s S: /f UEFI /v
   

   BIOS/MBR:

   bcdboot W:\Windows /s S: /f BIOS /v
   

3. If UEFI boot files are correct but firmware has no Windows Boot Manager entry, create or refresh the entry while preserving the existing order:

   bcdboot W:\Windows /p /v
   

4. Shut down, keep the source disk disconnected, and start the clone twice.

Branch B — Same computer, clone omitted or changed required partitions

1. Do not create or format partitions under this branch.

2. Preserve any new files from the target, then repeat the clone or image restore using a whole-disk or all required partitions option.

3. Verify the source image includes the system partition and Windows partition before overwriting the target.

4. After restoring, reconnect only the target and test it independently.

5. Use BCDBoot only if the complete target layout exists but its boot files are stale.

Branch C — The original installation still boots, but the target uses a different storage controller

1. Return the disk or image to the source configuration and boot the original installation.

2. Obtain the exact supported storage/chipset driver for the target hardware from the system, motherboard, or controller manufacturer.

3. Install or stage that driver while Windows is still running on the source configuration. Record the driver package and version.

4. Make a new image or clone after the target driver is staged.

5. Move or restore it to the target and test.

6. If the move is to substantially different hardware and is a planned deployment, create a verified image and use Sysprep with /generalize before capture according to Microsoft's deployment process. Generalization removes machine-specific state; it is not a casual repair command and can affect activation, provisioning, device state, and applications.

Branch D — The move already failed and the original does not boot on the target

1. Restore the original connection or original machine if possible.

2. If it starts, follow Branch C and create a new prepared clone.

3. If it cannot be returned, boot WinRE and use a matching, trusted driver package only when the new storage controller is precisely identified:

   dism /Image:W:\ /Add-Driver /Driver:<path-to-exact-driver.inf>
   

4. Record DISM's result. Do not use /Recurse against a mixed driver folder and do not force unsigned packages.

5. Restart once. If the identical 0x7B remains, stop and restore the verified source image rather than injecting more drivers.

• BCDBoot repairs the clone: The data partition was present; the boot partition or references were incomplete.
• A whole-disk re-clone starts: The first operation omitted or altered a required partition or identifier.
• The exact target storage driver resolves 0x7B: The cloned installation lacked a boot-capable path to the target controller.
• The clone starts only while the original disk is connected: Firmware is still using the original disk's system partition. Rebuild boot files on the target's verified system partition.
• Windows starts but activation changes: Hardware transfer and licensing are separate from the boot repair.
• The disk moved to a RAID/VMD/IRST path: Stop and use the platform-specific procedure; it is retained but deprioritized.

• Do not erase the original disk until the target cold-boots independently and its data is verified.
• Do not convert GPT to MBR or MBR to GPT merely to match a firmware setting.
• Do not clone only C: and assume that it contains the boot environment.
• Do not inject every driver from a vendor package.
• Do not run Sysprep /generalize without a verified image and an understood deployment plan.
• Do not repair BCD repeatedly when the stop code and evidence identify an inaccessible storage path.

Reconnect the unchanged original disk in its original port or restore the verified pre-move image. If only BCD was changed, copy the saved store back to its original system-partition path. Remove an injected driver only when its published name is known and the target can be safely serviced offline:

dism /Image:W:\ /Get-Drivers /Format:Table
dism /Image:W:\ /Remove-Driver /Driver:<oem-number.inf>

Do not remove an inbox or boot-critical storage driver as a speculative rollback.

• The target disk cold-boots twice with the original and unrelated disks disconnected.
• The intended target disk contains the boot files firmware actually uses.
• Device Manager shows the expected storage controller without an error.
• No 0x7B, 0xc0000225, or 0xc000000e returns.
• User data, applications, Windows edition, and activation state are recorded.
• The original disk or image remains available until the new installation passes backup verification.

Confidence is high when the first clone demonstrably omitted the system partition or when the target starts after its exact controller driver is staged. Confidence is moderate when BCDBoot repairs stale references but the clone method is unknown. Stop if either disk is unstable, the source cannot be preserved, the target controller is not precisely identified, cross-hardware generalization requirements are unknown, or RAID/VMD/IRST is involved.