Cloned SSD does not boot

TechnoMax

Honorable Member
Joined
Dec 9, 2018
Messages
10
I was unable to boot a restored Windows backup. So I reinstalled Windows and installed the necessary programs. Then I wanted to switch from this working 1TB SSD to a better, faster, and larger SSD, so I cloned the Windows SSD to another 2TB NVMe drive in the PC. However, the clone cannot be booted, even when I choose it in the boot drive selector at start up. (I had put it as first boot drive in BIOS already)
I then resorted to my usual helper for boot problems, a USB boot stick with Macrium Reflect. However, it couldn't restore the boot files either because it couldn't find an active partition on the larger SSD (“can be any primary partition on the boot drive”). But how can I fix this on a UEFI computer with GPT drives?
 

Short answer: on UEFI+GPT you don’t use an “active” flag — you need a valid EFI System Partition (ESP, small FAT32 partition) with the Windows boot files (\EFI\Microsoft\Boot... and a UEFI boot entry. Your clone most likely doesn’t have an ESP, or the ESP is present but empty / wrong type / missing boot files. The fix is to either copy/restore the ESP from the source disk or create an ESP and recreate the boot files with bcdboot. Below are safe, step‑by‑step ways to check and fix it.
Important warning
  • Don’t delete or repartition anything until you’ve backed up important files or have a full image. If you’re unsure, post the disk/volume listing (instructions below) before deleting.
1) Boot into a rescue environment
  • Boot the PC from your Windows install USB or from the Macrium Reflect rescue USB. When booted to the PE environment open a command prompt (Shift+F10 with Windows installer, or “Command Prompt” in Macrium).
2) Identify the disks and volumes (paste these results if you want me to check)
Run:
diskpart
list disk
select disk X (replace X with the disk number of the new NVMe)
list partition
list volume
exit
What to look for:
  • A small FAT32 partition ~100–300 MB → that’s the ESP.
  • A partition with the Windows files (large NTFS, contains \Windows).
If you do NOT see a FAT32 ESP on the NVMe, continue to step 3. If you see an ESP but it’s empty or lacks the Microsoft folder, skip to step 4.
3) Create an EFI System Partition (if missing)
(Only do this if there is room — creating a 260 MB partition is safe. If your clone used all space you may need to shrink Windows partition slightly first; ask if you need help.
At the command prompt:
diskpart
select disk X
create partition efi size=260
format quick fs=fat32 label=System
assign letter=S
exit
Now you have an ESP mounted as S:.
4) Recreate the boot files with bcdboot
Find which letter Windows is on in the rescue environment:
  • Try DIR C:\Windows, D:\Windows, etc., or run diskpart list vol to see which volume is the Windows partition and note its letter (assign a letter if it has none).
Then run (replace letters as needed):
bcdboot C:\Windows /s S: /f UEFI
Expected result: “Boot files successfully created.” This copies \EFI\Microsoft\Boot\bootmgfw.efi and creates the BCD store on the ESP.
If bcdboot errors:
  • If Windows is BitLocker encrypted, you must unlock or suspend BitLocker first.
  • If you get ACCESS DENIED or similar, check that S: is FAT32 and writable.
5) Remove assigned letter and reboot
(Optional cleanup)
diskpart
select volume <number of S:>
remove letter=S
exit
Reboot, enter UEFI setup and make sure the NVMe’s “Windows Boot Manager” entry is first (sometimes appears as “Windows Boot Manager (your NVMe model)”). If it does not appear, try the UEFI boot menu — the newly created boot entry should show.
Alternative if ESP exists but no boot entry
  • If ESP contains \EFI\Microsoft\Boot\bootmgfw.efi but the UEFI entry is missing, you can recreate the entry with efibootmgr (Linux) or use EasyUEFI in Windows, or simply run bcdboot as above — it usually creates the firmware entry.
If cloning didn’t copy the ESP at all
  • When you cloned, some cloning tools skip small system partitions by default. If you still have the original drive, the safest is to copy the ESP from the original to the new drive (byte-copy the 100–260 MB FAT32 partition) or recreate it and use bcdboot.
If Macrium “Fix Boot Problems” complains about “active partition”
  • That message is generic (older MBR phrasing). On GPT/UEFI the tool still expects a usable ESP. The correct action is creating/restoring the ESP and running bcdboot as above.
If you prefer a GUI method inside Windows
  • Boot the cloned disk via the rescue environment, install/run EasyUEFI or use Windows’ Disk Management to check partitions, then use EasyUEFI to add a boot entry pointing to \EFI\Microsoft\Boot\bootmgfw.efi on the ESP.
What I need from you if it still fails
  • Paste the output of:
    diskpart -> list disk -> select disk X -> list partition -> list volume
  • Or a screenshot of Disk Management showing partitions for both the source and the cloned NVMe.
I can then give exact commands (which partition to select, whether it’s safe to delete/recreate the ESP, or steps to copy the ESP).
 

Thanks, this detailed, exact step by step helped me solve my problem!

As I already had an EFI partition on the big SSD I "only" had to run the command "bcdboot C:\Windows /s S: /f UEFI" with H for the Windows partition and E for the EFI partition.
Now my last wish is to be able to boot a restored Windows backup before I installed it anew. I have still another empty SSD in my PC that is big enough for the restore. When it will not boot again because of a bad BCD, can I simply copy the EFI partition of my running Windows over to the restored Windows SSD?
 

Nice — glad the bcdboot fix got you back up, TechnoMax.
Short answer: yes, you can copy the EFI partition from your running Windows to the restored SSD, but the safest and most reliable method is not to blindly copy the BCD raw file — instead create (or mount) an ESP on the restored drive and run bcdboot to populate a correct EFI store. bcdboot will create the correct files and register a UEFI boot entry for that specific Windows installation; this avoids GUID/volume‑reference problems that can occur if you simply copy the BCD store.
Two safe ways (step‑by‑step)
A — Recommended: create/ensure an ESP and run bcdboot (best practice)
  • Boot WinPE / Macrium Rescue / Windows install USB and open an elevated Command Prompt.
  • Use diskpart to identify disks/volumes:
    diskpart
    list disk
    select disk X (X = restored SSD)
    list partition
    list volume
    exit
  • If the restored SSD has no ESP, create one (260 MB is fine):
    diskpart
    select disk X
    create partition efi size=260
    format quick fs=fat32 label=ESP
    assign letter=S
    exit
  • Assign a letter to the restored Windows partition if WinPE hasn’t already (example H:). Confirm by dir H:\Windows.
  • Run bcdboot to create boot files and register the firmware entry:
    bcdboot H:\Windows /s S: /f UEFI
    Expect “Boot files successfully created.” This both copies the files into S:\EFI... and creates the UEFI boot manager entry.
  • Remove any temporary drive letters (diskpart → select vol → remove letter=S) and reboot; set the new drive’s “Windows Boot Manager” first in UEFI if needed.
Notes: if the restored Windows is BitLocker encrypted unlock or suspend it first in WinPE; otherwise bcdboot can fail.
B — Alternative: copy the ESP contents then repair BCD (when you must copy)
  • Mount source ESP (assign letter, e.g. R:) and target ESP (assign S:).
  • Copy all files from R:\ to S:\ (use robocopy /E or xcopy /E /H /K) — this copies \EFI and other folders.
  • After copying, don’t rely on the copied BCD alone — run bcdboot H:\Windows /s S: /f UEFI to regenerate a correct BCD and register the boot entry. Simply copying files without running bcdboot can leave firmware/BCD entries pointing at the wrong disk/IDs.
Additional practical tips and cautions
  • Always confirm the correct disk number before using diskpart — selecting the wrong disk can destroy data.
  • If you see duplicate UEFI entries afterward you can clean them with EasyUEFI in Windows or with efibootmgr from Linux; bcdboot normally creates a proper entry.
  • If bcdboot reports “access denied,” check that the ESP is FAT32, writable, and not marked read‑only (diskpart → attributes disk clear readonly).
If you like, tell me:
  • the disk numbers / list volume output from WinPE (paste diskpart’s list disk and list vol), and I’ll give the exact commands you should run for your restored SSD step‑by‑step.
 

Must I boot WinPE / Macrium Rescue / Windows install USB or can I either boot one of my identical internal Windows installs or a bootable copy of it on an external SSD (made by DiskGenius System migration)?
 

Short answer: you can use another full Windows (internal or an external bootable copy) to repair a restored Windows drive, but using WinPE/Macrium/Windows install media is safer and simpler — it keeps the target installation offline, avoids drive‑letter confusion and locked files, and reduces the risk of accidentally touching the wrong disk.
Why rescue media is recommended
  • It runs a minimal WinPE environment that doesn’t auto‑mount/manage the installed OS, so the restored Windows partition won’t be “live” or locked.
  • Volume letters are predictable in WinPE (you can check them and assign as needed).
  • Tools like bcdboot, diskpart and bootrec behave the same but with less chance of user error wrecking the currently running Windows.
  • If BitLocker is present, WinPE makes it obvious you must unlock the target volume before repairing.
When using a full Windows (internal or external) — what to watch for
  • NEVER boot the Windows that lives on the disk you want to repair. Boot a different Windows (internal or external) and run the repair from there.
  • Make absolutely sure you identify the correct disk number in diskpart. The biggest risk is selecting the wrong disk.
  • A running Windows may auto‑mount the target disk and assign different drive letters than WinPE would — double‑check the Windows folder path (dir X:\Windows) before running bcdboot.
  • If the target Windows is BitLocker‑protected, unlock it first (manage-bde or the Recovery Key) before running bcdboot.
  • Using an external bootable copy (DiskGenius migration) is possible but ensure it was booted in UEFI mode (not Legacy/CSM) and that any NVMe drivers required are available.
Exact safe sequence (works in WinPE or from another running Windows — same commands)
1) Open an elevated Command Prompt.
2) Identify disks/volumes:
diskpart
list disk
select disk X (X = the restored SSD — confirm by size)
list volume
exit
3) If no EFI partition exists on the restored SSD, create one (only if you have space):
diskpart
select disk X
create partition efi size=260
format quick fs=fat32 label=ESP
assign letter=S
exit
4) Assign a letter to the restored Windows partition if needed and confirm it contains \Windows (example H:):
dir H:\Windows
5) Run:
bcdboot H:\Windows /s S: /f UEFI
— expect “Boot files successfully created.”
6) Remove temporary letters (optional) and reboot. Set firmware to boot the new drive’s Windows Boot Manager.
Extra checks/notes
  • If you get “Access denied,” check ESP is FAT32 and not read‑only (diskpart -> attributes disk clear readonly).
  • If BitLocker is used, unlock/suspend before writing boot files.
  • If you want to avoid any chance of confusing the firmware entries, use WinPE for the operation — it’s the least risky.
If you want, tell me which of these you prefer (WinPE / Macrium Rescue / Windows install USB vs. an internal Windows or external bootable copy), and paste the output of diskpart’s list disk and list volume (from whatever environment you plan to use). I’ll give the exact disk/volume numbers and the precise commands to run.
 

Now that I have *three* bootable windows installations on my machine, can I for restoring system backups restore only the pure System partition from a backup into one of the workable Windows versions to be on the safe side for booting from this restored Windows?
 

Short answer: yes — but with caveats. The “pure System partition” on a UEFI/GPT PC is the small FAT32 EFI System Partition (ESP). Restoring only that partition can make a restored Windows image bootable, but the safest and most reliable approach is to either (A) restore the OS partition and then run bcdboot to build a fresh, correct EFI store for that installation, or (B) restore the ESP and immediately run bcdboot to regenerate the BCD for the restored Windows. Blindly copying a BCD/ESP from one live installation over another can produce wrong boot entries or break the currently working installs.
Why bcdboot is recommended
  • The ESP contains firmware‑used files plus a BCD store that may reference volume GUIDs or device paths specific to the source install. bcdboot rebuilds the EFI files and makes a UEFI boot entry that correctly points to the restored Windows, avoiding GUID mismatches.
Safe workflows (pick one)
Workflow A — Recommended (most robust)
  • Restore the Windows partition (and any MSR/other data partitions) to the target SSD.
  • Boot WinPE / Macrium Rescue / Windows install USB (so the restored Windows is offline).
  • Create or mount an ESP on that disk if it doesn’t exist (create partition efi size=260; format quick fs=fat32; assign letter=S).
  • Assign the restored Windows partition a drive letter (e.g. H:) and confirm H:\Windows exists.
  • Run:
    bcdboot H:\Windows /s S: /f UEFI
    You should see “Boot files successfully created.” This copies \EFI\Microsoft\Boot and creates a correct BCD and firmware entry.
Workflow B — If you prefer to restore only the ESP from your backup
  • Restore the ESP image into the ESP partition on the restored SSD (do not overwrite the ESP of the currently running Windows).
  • Still from WinPE, assign letters to the restored ESP (S:) and to the restored Windows partition (H:).
  • Run bcdboot H:\Windows /s S: /f UEFI to regenerate the BCD and ensure the firmware entry is correct. Copying files alone without bcdboot may leave wrong entries or point to the wrong disk.
What NOT to do
  • Don’t overwrite the ESP of a working Windows installation while that Windows is running — you can break that install’s boot. If you must use a running Windows to prepare a different disk, make sure you target the other disk’s ESP (mount it as a separate letter) and do not replace the running system’s ESP.
  • If the restored Windows is BitLocker-encrypted, unlock or suspend BitLocker first before running bcdboot; otherwise the repair will fail.
Extra tips
  • You can keep one ESP per disk (preferred) so each disk has its own Windows Boot Manager entry in firmware; or use a single shared ESP — both work, but per‑disk ESPs reduce accidental cross‑over.
  • Macrium and other imaging tools can restore the ESP partition; afterward run bcdboot as above to be safe.
If you want, I can:
  • Give the exact commands to restore only the ESP with Macrium (or to mount it safely), or
  • Review your disks’ partition layout (paste diskpart -> list disk -> select disk N -> list partition -> list volume output) and tell you the exact, safe sequence for your configuration.
Which would you prefer?
 

My question was a bit vague: With "pure system partition" I did not mean the small EFI partition at the start of the drive but the big OS partition "C:\Windows". If I restore only this partition back to a working Windows drive, will it still work, will it still boot successfully?
 

Short answer, TechnoMax: yes — restoring only the large OS partition (the C:\Windows NTFS volume) can work and boot, but only if the disk also has a valid EFI System Partition (ESP) and correct boot registrations (and the restored Windows has the right storage drivers/unlocked BitLocker). The safe, reliable flow is to restore the C: partition and then recreate/populate the ESP and BCD for that restored installation (don’t just copy a BCD blindly).
Why it’s not guaranteed
  • On UEFI/GPT the firmware boots the EFI files from the small FAT32 ESP, not from C:. If the target disk has no ESP (or the ESP points to a different Windows), the restored C: won’t be bootable until the ESP/BCD are fixed.
  • The BCD in the ESP may reference volume identifiers or paths that don’t match the restored image — bcdboot is the supported way to build a correct EFI store for the restored OS. Copying an ESP/BCD from another live Windows can leave wrong entries.
  • If Windows needs a specific NVMe/storage driver early in the boot, a restored image might BSOD INACCESSIBLE_BOOT_DEVICE until that driver is present/loaded.
  • BitLocker: if the restored image was encrypted you must unlock or suspend BitLocker before repairing or booting.
Recommended, safe workflows
Workflow A — Recommended (restore C: then rebuild the ESP)
  • Restore the large OS partition (C:) to the target disk (using your imaging tool).
  • Boot WinPE / Macrium Rescue / Windows install USB (so the restored Windows is offline).
  • Confirm disk is GPT and find volumes:
  • diskpart → list disk → select disk X → list volume.
  • If there’s no ESP on that disk, create one (e.g. 260 MB FAT32) and assign a letter (S:):
  • diskpart → select disk X → create partition efi size=260 → format quick fs=fat32 → assign letter=S.
  • Assign a letter to the restored Windows partition (H:) if needed and verify H:\Windows exists.
  • Recreate the boot files and firmware entry:
  • bcdboot H:\Windows /s S: /f UEFI
    Expect “Boot files successfully created.” This both populates S:\EFI\Microsoft\Boot and registers a correct UEFI entry.
  • Remove temporary letters and reboot; set the disk’s “Windows Boot Manager” first if needed.
Workflow B — If you restore only the ESP (less common)
  • You can restore the ESP from a backup, but after restoring you should still run bcdboot H:\Windows /s S: /f UEFI to rebuild a correct BCD for that Windows (copying files alone may leave firmware entries pointing at the wrong disk).
Extra safety steps and notes
  • Always image the disk before making changes. Don’t run diskpart on the wrong disk.
  • If bcdboot returns “Access denied,” ensure the ESP is FAT32 and writable and clear disk read‑only attributes first.
  • If the restored image was MBR/legacy, you’ll need to convert to GPT and create an ESP (mbr2gpt or gdisk) or boot it in legacy mode — but mixing legacy/UEFI modes can be messy.
  • Restoring only C: can leave application shortcuts or registry entries that referred to other drive letters or partitions in the original system — when the restored Windows becomes the booted OS it will normally take C: at boot, but some apps that referenced absolute paths on other partitions can misbehave (this is why restoring the whole set of system-related partitions is cleaner in many cases). Historical forum cases show program pointers and drive-letter issues after partial restores.
  • Also restore or recreate MSR/Recovery partitions if your imaging tool included them — Windows setup and updates sometimes expect those. You can create MSR with DiskPart if needed.
If you want I’ll give the exact commands tailored to your disks — paste the output of (from WinPE or any environment you’ll use):
diskpart → list disk → select disk X (your target) → list partition → list volume
I’ll then produce a precise, copy‑paste sequence (create ESP if needed, assign letters, run bcdboot, cleanup) so the restored C: boots cleanly.
 

No, Macrium Reflect does not automatically do the right stuff. The safe way indeed is the "bcdboot H:\Windows /s S: /f UEFI" command with the correct partition letters.
 

Exactly — spot on, TechnoMax. Macrium’s GUI/restore will get partitions and files back, but it doesn’t always rebuild a correct UEFI boot store (ESP + BCD) for the restored OS. Running bcdboot against the restored Windows is the straightforward, reliable step that actually makes the firmware-aware boot entry for that installation.
Quick checklist you can copy/paste (run from WinPE / your Macrium Rescue or any other offline Windows environment)
1) Identify disks/volumes
  • Open elevated command prompt and run:
    Code:
    diskpart
    list disk
    select disk X (replace X with the restored SSD number — confirm by size)
    list volume
    exit
    Note the volume letter for the restored Windows partition (H: in your examples) and whether there is an ESP (small FAT32 volume).
2) If the disk has no ESP, create one (safe: 260 MB)
Code:
 diskpart select disk X create partition efi size=260 format quick fs=fat32 label=ESP assign letter=S exit
3) Make sure the restored Windows partition has a drive letter and contains \Windows:
dir H:\Windows
4) Populate the EFI and create the UEFI entry:
bcdboot H:\Windows /s S: /f UEFI
Expect: “Boot files successfully created.”
5) Cleanup (optional)
  • Remove the temporary letter for the ESP:
    Code:
    diskpart
    select volume <# of S:>
    remove letter=S
    exit
  • Reboot and set the new disk’s “Windows Boot Manager” first in UEFI.
Important caveats
  • BitLocker: unlock or suspend protectors for the restored OS volume before running bcdboot, otherwise it can fail. Example to suspend in a running Windows: manage-bde -protectors -disable C:. From WinPE you must unlock the volume with the recovery key.
  • Be extremely careful with disk/volume numbers in diskpart — selecting the wrong disk will destroy data.
  • If bcdboot reports “Access denied,” verify the ESP is FAT32 and writable and clear any disk readonly attributes (diskpart → select disk X → attributes disk clear readonly).
  • If the restored Windows was originally Legacy/MBR, you’ll need to convert to GPT (mbr2gpt or gdisk) or boot it in legacy mode — mixing modes may complicate things.
If you want, paste the output of:
Code:
diskpart
list disk
select disk X (pick the restored SSD)
list partition
list volume
exit
I’ll give you the exact disk/volume numbers and a one‑shot command sequence tailored for your machine.
 

Back
Top