← Archive

What to Do When a PC Shows a Recovery Screen After a Drive Clone

I’ll help you diagnose why a cloned Windows drive opens a recovery screen, from UEFI and partition mismatches to missing boot files and duplicate identifiers, while protecting the original installation and your cloned data during recovery.

A recovery screen after cloning a drive doesn’t necessarily mean the clone failed. The new drive may contain all your files and still be unable to start Windows because the firmware is using the wrong boot mode, the boot files point to the wrong partition, or the cloning process left the disk with an identifier problem.

The safest approach is to treat the original drive as your reference and the clone as the system you’re diagnosing. Don’t erase, reformat, or repeatedly “repair” both drives at once. First determine whether the computer can see the clone, whether the clone contains the expected partitions, and whether Windows is failing before or after the boot manager starts.

Protect the original before changing anything

Shut the computer down fully and label the original and cloned drives. If possible, disconnect the original drive for the first boot attempt from the clone. This isn’t because the original is defective; it prevents the firmware or Windows recovery tools from selecting boot files on one drive while loading Windows from the other.

If the clone is an external USB drive, move it to the intended internal connection before judging the result. Some computers can boot from USB, but the firmware may assign different drive paths or omit a USB device from the normal Windows Boot Manager sequence. For a replacement internal drive, connect it to the slot or port where it will normally operate.

Keep the original untouched until the clone has booted successfully and you’ve checked important files and applications. If the original uses BitLocker or another full-disk encryption system, locate the recovery key before making hardware or firmware changes. A firmware setting change, motherboard replacement, or altered boot configuration can sometimes trigger an encryption recovery prompt even when the data itself is intact.

Confirm your recovery tools and key first: Before changing partitions or running repair commands, make sure you have access to the Windows installation or recovery media for the installed Windows version, the computer’s firmware documentation, and any BitLocker recovery key associated with the original drive.

Identify which kind of recovery failure you’re seeing

The wording on the screen gives you a useful starting point. A message such as “No boot device,” “Operating system not found,” or a firmware prompt usually means the computer hasn't found a usable boot manager. A blue recovery screen with an error code such as INACCESSIBLE_BOOT_DEVICE means Windows has started loading but can't access the system volume or required storage path. Automatic Repair, Startup Repair, or a boot configuration error points more directly toward damaged or missing boot files.

A recovery screen can also be caused by a simple boot-order mistake. Enter the firmware setup, commonly by pressing a key such as Delete, F2, F10, or F12 during startup, and check whether the cloned drive is detected. The exact key and menu names vary by manufacturer, so use the computer or motherboard documentation if the usual keys don’t work.

Look for a boot option named Windows Boot Manager followed by the cloned drive. On a UEFI system, selecting the physical drive alone may not be enough; the firmware normally starts the EFI System Partition through the Windows Boot Manager entry. If both the original and clone are connected, there may be two similarly named entries, which is another reason to test with the original disconnected.

Check UEFI, Legacy, GPT, and MBR compatibility

The clone needs to be booted in a mode compatible with how Windows was installed. Most modern systems use UEFI firmware with a GPT system disk. Older installations may use Legacy BIOS or Compatibility Support Module mode with an MBR disk. A clone can reproduce the partitions correctly while the computer still fails because the firmware is set to the other mode.

If the original booted using UEFI, keep the replacement system in UEFI mode and select its Windows Boot Manager entry. If the original used Legacy or CSM, switching to UEFI without converting the installation can make the disk appear unbootable. Conversely, changing a modern GPT installation to Legacy mode usually won’t provide a valid boot path.

You can check the disk layout from Windows recovery tools. Choose Troubleshoot, then Advanced options, and open Command Prompt. Drive letters in the recovery environment may not match the letters you see in normal Windows, so don’t assume that C: is the Windows partition.

At the prompt, you can inspect the disks with:

diskpart
list disk
list volume
list partition
exit

A GPT disk is commonly marked with an asterisk in the GPT column of list disk. A UEFI Windows installation generally has a small FAT32 EFI System Partition, a Microsoft Reserved partition that may not have a drive letter, the main NTFS Windows partition, and possibly a recovery partition. An MBR installation may instead have a small active system partition and no EFI System Partition.

The layout is evidence, not a reason to delete anything. If the clone is missing the EFI System Partition, the active system partition, or the recovery partition, the cloning job may have copied only the main Windows volume rather than the entire disk. Repeating the clone as a disk-to-disk clone, rather than copying only a selected partition, is often safer than trying to recreate a complex layout manually.

Make sure the clone contains the right Windows installation

In the recovery Command Prompt, use dir to look for the Windows folder on likely volumes:

dir C:\Windows
dir D:\Windows
dir E:\Windows

The correct volume should contain folders such as System32, Boot, and Users. Drive letters can differ in recovery mode, and a small EFI or recovery partition won’t contain the full Windows installation.

If the expected Windows folder isn’t present, stop and reassess the clone. The drive may be connected through the wrong adapter, the partition may be offline, or the cloning software may have copied a different source volume. If the files are present but Windows still doesn’t boot, rebuilding the boot files may solve the problem.

Before using repair commands, note the letters assigned to the Windows partition and the EFI System Partition. In DiskPart, you can assign a temporary letter to a visible partition, but select the volume carefully. For example:

diskpart
list volume
select volume <number>
assign letter=S
exit

Replace <number> with the actual volume number. Don’t use a guessed number, and don’t format the volume. If the EFI partition is already assigned a letter, use that letter instead of assigning another one.

Rebuild boot files on a UEFI clone

Once you have confirmed the Windows partition and EFI partition, bcdboot can copy fresh boot files from the Windows installation to the EFI partition. The general form is:

bcdboot D:\Windows /s S: /f UEFI

Here, D:\Windows is an example of the Windows directory and S: is an example of the EFI System Partition. Use the letters you identified in your own recovery environment. A successful result should report that the boot files were created, though the wording can vary by Windows version and recovery environment.

Restart, enter the firmware setup if necessary, and select the Windows Boot Manager entry for the cloned drive. If the entry is still missing, the firmware may need to rediscover it, or the cloning tool may not have copied the EFI partition correctly. Rebuilding boot files can't repair a clone that lacks the required partition or contains unreadable data.

For an MBR and Legacy BIOS installation, the repair path is different. The system partition needs to be marked active and the boot code may need repair, but changing a partition’s active status incorrectly can make another installation unbootable. Because modern computers and Windows installations vary, use the recovery environment’s Startup Repair first and consult the storage or motherboard manufacturer’s current documentation before using commands such as bootrec or changing partition flags.

Consider duplicate disk identifiers and boot entries

A clone is a copy, so it can initially share identifiers with the original. Modern cloning applications often change or randomize the appropriate identifiers automatically, but behavior differs between tools and clone types. With both disks connected, the firmware, Windows, or a boot manager can select the wrong disk or become confused about which installation a boot entry represents.

This is why testing the clone by itself is valuable. Power down, disconnect the original, and boot only from the clone. If the clone starts normally alone but fails when both drives are connected, the problem is probably selection, duplicate identifiers, or a boot entry that still references the original. Reconnect the original only after you have confirmed the clone works independently.

Don’t change disk or partition identifiers casually. A forced identifier change can affect drive letters, mounted volumes, recovery configurations, backup jobs, and applications that expect a particular disk. Use the cloning software’s documented “make this disk bootable,” “resolve disk signature collision,” or equivalent option when available, and make a fresh backup before altering identifiers.

When Startup Repair helps—and when it doesn’t

Startup Repair is a reasonable low-risk first attempt when the clone is detected, the firmware mode is correct, and the Windows partition is present. It can address some boot configuration and startup problems, but it isn’t a universal fix for a damaged clone, a missing partition, a storage-controller problem, or a filesystem with significant corruption.

Run it with only the clone connected when possible. If it reports that it couldn’t repair the PC, record the message and avoid cycling through the same repair attempt indefinitely. From the Advanced options menu, you may also try System Restore if restore points exist, or uninstall a recent update if the recovery screen began after an update rather than immediately after cloning.

If the clone produces INACCESSIBLE_BOOT_DEVICE, check storage-controller settings in firmware. A change between modes such as AHCI and RAID can prevent Windows from loading the necessary storage driver. Return the setting to the one used by the original installation unless you have a specific migration plan and a verified backup. Also check whether the new drive uses a connection or controller that the older Windows installation can't access without updated firmware or drivers.

Decide whether to repair or reclone

Repair is worthwhile when the clone contains a complete, readable disk layout and the failure is limited to boot configuration. Recloning is usually the cleaner choice when the source was healthy, the clone omitted system partitions, the clone reports read errors, or several unrelated repairs have already been attempted.

If you reclone, choose the entire source disk rather than only the visible Windows partition. Confirm that the destination is at least as large as the data being copied and that the cloning application supports the source and destination partition styles. Read the application’s options carefully for proportional resizing, sector-by-sector copying, encryption handling, and post-clone identifier changes. The exact features and terminology can change between software versions, so check the tool’s current documentation rather than relying on an old tutorial.

After the second attempt, shut down and test the destination alone. Let Windows complete its first startup, then verify your user profile, documents, applications, activation status, encryption state, and essential files. Keep the original drive disconnected or safely stored until you have a current backup and confidence that the replacement is stable.

A recovery screen after cloning is usually a boot-path problem, not proof that every file on the new drive is gone. Work from the least destructive checks—drive detection, boot order, firmware mode, partition layout, and standalone testing—before rebuilding boot files. If those checks show that the clone is incomplete or unreadable, preserve the original and reclone instead of sacrificing the only known-good copy.