Part of Software Development & Tools — the development stack: environments, APIs and tooling.
When Windows won’t boot after cloning, the usual advice is to rebuild the BCD. That advice is often wrong, because the most common cause is not a damaged boot record at all. A block-level clone reproduces the source disk exactly, including its GPT identifiers, so the firmware ends up with two disks it cannot tell apart. This article documents five distinct failures from a single real migration, each with the diagnostic command that identified it and the fix that resolved it.
- A cloned NTFS volume typically carries the dirty bit; run
chkdsk C: /fbefore resizing anything. - Firmware cannot distinguish two disks with identical EFI partition GUIDs, so boot order settings will not fix wrong-disk boots.
- A Recovery partition sitting between C: and the free space greys out Extend Volume; the fix is five steps, not a registry hack.
- A missing drive can mean a disabled controller: check whether the whole AHCI controller reports
Present = False. reagentc /enablecan report success while WinRE stays disabled, when ReAgent.xml holds a stale disk GUID.
Why cloned installs break in ways fresh installs do not
A clean installation writes new identifiers everywhere. Windows generates a fresh disk GUID, fresh partition GUIDs and a boot entry that points at exactly one EFI System Partition. Nothing else on the machine shares those values.
Cloning inverts that property deliberately. The whole point is byte-for-byte reproduction, so the copy inherits every identifier the original had. As a result you briefly own two disks that claim the same identity, and several Windows subsystems assume identities are unique.
Three subsystems care in particular. UEFI firmware locates the boot loader by partition GUID. The Windows volume manager tracks disk signatures to assign drive letters. Finally, the recovery environment stores the location of its image as a disk GUID plus a byte offset. Consequently a clone can confuse all three at once.
The scale of the migration behind this article was modest: 1 source disk of 447.13 GiB, 1 target disk of 1907.73 GiB, 4 partitions copied, and 425 GB of occupied data. Even so, it produced 5 separate failures across 24 hours, cost roughly 6 hours of diagnosis, and required 3 reboots that were not part of the plan. Small migrations are not safe migrations.
None of this is a defect in the cloning tool. Rescuezilla did its job correctly here, copying 446.2 GiB with zero read errors. The problems appear afterwards, during the first boots and the first partition changes.
The five failures at a glance
| Trap | Symptom | Diagnostic command | Fix |
|---|---|---|---|
| 1. Dirty bit | Volume reports Scan Needed; online repair fails | fsutil dirty query C: | chkdsk C: /f plus reboot |
| 2. Wrong disk boots | System starts, but from the old install | bcdedit /enum "{bootmgr}" | Isolate the source drive for the first boot |
| 3. Extend blocked | Extend Volume greyed out despite 1460 GiB free | Get-Partition -DiskNumber 0 | Relocate the Recovery partition, then extend |
| 4. Drive invisible | Disk absent from Disk Management entirely | Get-PnpDevice -Class DiskDrive | Re-enable the controller in BIOS |
| 5. WinRE disabled | /enable succeeds, status stays Disabled | reagentc /info | Delete ReAgent.xml, then /setreimage |
All five appeared on the same machine within 24 hours. Four of them produce no error message at all, which is precisely why they cost time. The sections below take each in turn, with the readings that identified it.
Trap 1: the NTFS dirty bit blocks every resize
The freshly cloned system booted normally and reported a healthy disk. However, Get-Volume told a different story:
Get-Volume -DriveLetter C
HealthStatus : Warning
OperationalStatus : Scan NeededThe underlying flag is visible only through fsutil, and an attempted online repair failed outright:
fsutil dirty query C:
Volume - C: is Dirty
Repair-Volume -DriveLetter C -Scan
A snapshot error occurred while scanning this drive.
Run an offline scan and fix.The dirty bit is a normal consequence of copying a filesystem at block level. It does not indicate damage. Nevertheless it matters enormously, because resizing a partition whose filesystem has never been verified is how a recoverable situation becomes an unrecoverable one.
The fix is one command plus a reboot:
chkdsk C: /fOn this machine the offline pass examined 3,830,272 file records in 3.11 minutes. It reported 0 bad sectors, 0 bad file records and 0 files recovered to lost-and-found. Only cosmetic cleanup occurred: instance tags on one file, plus 4,159 unused security descriptors. In short the clone was sound, and the flag was procedural rather than a symptom.
Trap 2: Windows boots the old drive, not the clone
This is the failure that produces the “Windows won’t boot after cloning” search, except the symptom is subtler. The machine boots perfectly — into the wrong Windows. Both installations look identical, so the mistake can go unnoticed for hours.
Why the boot order does not help
The obvious response is to promote the new drive in the BIOS boot order. On this workstation that had already been done, and the system still started from SATA. Inspecting the boot entry explains why:
Free ebook
Free AI Video, Generated Locally
Working scripts and measured benchmarks. Free.
No spam. Unsubscribe at any time.
bcdedit /enum "{bootmgr}"
identifier {bootmgr}
device partition=DeviceHarddiskVolume1
path EFIMicrosoftBootbootmgfw.efiFirmware resolves that entry through the EFI System Partition’s GPT identifier. After a clone both disks carry the same identifier and a byte-identical bootmgfw.efi. Therefore the firmware picks whichever enumerates first, and SATA generally enumerates ahead of NVMe. Boot order operates at a level above this, so it never gets consulted.
The only reliable fix
Rewriting the boot entry with bcdboot does not solve it either, because the replacement points at the same ambiguous identifier. Two approaches actually work. Either isolate the source drive for the first boot, or remove its EFI partition permanently.
Isolation can be physical or logical. Unplugging the SATA data cable works. Setting sSATA Controller = Disable in the BIOS works equally well and requires no tools. Once the clone has booted alone, Windows detects the collision and re-stamps the duplicate identifiers automatically.
That re-stamping is observable. Before reconnection, the new drive’s EFI partition carried GUID {4892bad4-dd46-483e-9ed3-8b324b0dccf0}. Afterwards the old drive held that value, while the clone had received a freshly generated {e5b7ebdd-924a-11f1-875b-84a93e735dfc}. Notably the Recovery partition kept its GUID, because it had been recreated during resizing and never collided.
Trap 3: Extend Volume is greyed out
Cloning a 447 GiB disk onto a 1907 GiB disk leaves roughly 1.4 TiB unallocated. Most guides then say “right-click C: and choose Extend Volume”. On a standard Windows 11 layout that option is unavailable, and the reason is positional:
Partition Type Size Offset
1 System 0.10 GiB 0.00 GiB
2 Reserved 0.02 GiB 0.10 GiB
3 C: 446.20 GiB 0.11 GiB
4 Recovery 0.81 GiB 446.32 GiB <- blocks the extend
1460.60 GiB unallocatedWindows extends a partition only into space that directly follows it. Because the Recovery partition sits between C: and the free space, the operation is impossible regardless of how much room exists.
Moving the Recovery partition safely
Deleting the Recovery partition outright costs you the recovery environment. Instead, relocate it. The documented sequence uses no third-party tools:
# 1. move the WinRE image out to C:
reagentc /disable
# 2. delete the now-empty Recovery partition
Remove-Partition -DiskNumber 0 -PartitionNumber 4 -Confirm:$false
# 3. extend C:, leaving room at the end
$max = (Get-PartitionSupportedSize -DiskNumber 0 -PartitionNumber 3).SizeMax
Resize-Partition -DiskNumber 0 -PartitionNumber 3 -Size ($max - 2GB)
# 4. recreate Recovery at the end, then set its GPT type and attributes
$p = New-Partition -DiskNumber 0 -UseMaximumSize
Format-Volume -Partition $p -FileSystem NTFS -NewFileSystemLabel Recovery -Confirm:$false
# diskpart: set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
# gpt attributes=0x8000000000000001
# 5. put WinRE back
reagentc /enableVerify after step 1 that C:WindowsSystem32RecoveryWinre.wim actually exists before deleting anything. On this machine the file measured 768,897,928 bytes. The final layout gave C: 1905.61 GiB and a 2 GiB Recovery partition, deliberately larger than the original 0.81 GiB.
Trap 4: the new drive is invisible in Windows
A drive that does not appear can mean poor seating, a dead module, or something far less obvious. Before touching hardware, check whether the disk is merely offline or genuinely absent:
Get-PnpDevice -Class DiskDrive | Select-Object Status, Present, FriendlyNameAn offline disk still appears in Get-Disk with IsOffline = True. A disk missing from that list entirely has not been enumerated at all. In this case the output was decisive:
Status Present FriendlyName
OK True KINGSTON SKC3000D2048G
Unknown False SSDSC2KB480G8L
Unknown False Standard SATA AHCI Controller <- whole controller goneThe missing item was not the drive but the entire AHCI controller. A BIOS comparison confirmed it: sSATA Controller had been switched from Enable to Disable. On HP business machines you can read and write those settings from Windows through the vendor WMI namespace rootHPInstrumentedBIOS, which avoids a reboot into setup just to look.
Trap 5: WinRE reports Disabled after partition work
Moving the Recovery partition can leave the recovery environment unregistered even when every file survived. The symptom is contradictory output:
reagentc /enable
REAGENTC.EXE: Operation Successful.
reagentc /info
Windows RE status: Disabled
Windows RE Version: 0.0.0.0The cause sits in C:WindowsSystem32RecoveryReAgent.xml. Its WinreLocation element stores a disk GUID plus a byte offset, and after the migration the two disagreed:
<WinreLocation path="RecoveryWindowsRE" offset="2046261460992"
guid="{ed326aa7-f9cd-4eb7-9acf-2b7bd123eb91}"/>The offset of 2,046,261,460,992 bytes equals 1905.73 GiB, which is correct for the 2 TB drive. However, the GUID belonged to the 447 GiB drive, where that offset does not exist. reagentc had written it while two disks with system structures were present, and the log recorded the confusion plainly: Error: System disks found.
Repeating /disable and /enable did not help, because the stale file kept steering the process. Deleting the configuration and re-registering explicitly did:
# mount the recovery partition temporarily, then
Remove-Item C:WindowsSystem32RecoveryReAgent.xml
reagentc /setreimage /path V:RecoveryWindowsRE /target C:Windows
reagentc /enableAfterwards the status read Enabled, version 10.0.26100.8971, with a regenerated WinreLocation pointing at the correct disk GUID.
A safety pattern that prevents all five
Every fix above was low-risk for one reason: the source drive still held an untouched, bootable system. That single fact converts irreversible operations into reversible ones.
Therefore keep the original drive intact until the clone has survived several reboots, a full Windows Update cycle and normal use of your applications. Do the partition surgery while the rollback exists, not afterwards. Format the old drive last, deliberately, as a separate decision.
A second habit helps as much. Before any destructive step, verify the target by more than one signal — serial number, bus type, capacity and boot flags together. Scripted guards that abort on a mismatch cost minutes to write and prevent the single mistake that has no recovery.
The guard used before wiping the old drive in this migration checked eight conditions: the disk was not the boot disk, not the system disk, not disk number 0, reported bus type SATA, matched model SSDSC2KB480G8L, matched serial BTYF910407K6480BGN, measured between 400 and 500 GiB, and did not host the running C: volume. Any single failure aborted the script before it touched anything.
That level of paranoia sounds excessive for a home upgrade. In practice it took about fifteen minutes to write and it survives copy-paste into the next migration. More importantly, running the same script in dry-run mode first prints exactly which disk it intends to erase, together with its partition list — a far better confirmation than a dialog box asking “are you sure?”.
Finally, record the numbers as you go. Capacities, serial numbers, GUIDs and command outputs cost nothing to capture and turn a confusing failure two days later into a five-minute comparison. Every diagnosis in this article came from that habit.
Frequently asked questions
Why does Windows boot the old drive after cloning?
Because both drives carry identical EFI partition GUIDs, firmware cannot distinguish them and loads whichever enumerates first. Disconnect the source drive or disable its controller for the first boot.
Should I rebuild the BCD when Windows won’t boot after cloning?
Usually not. Rebuild the BCD only after confirming the correct disk is actually being booted. In duplicate-identifier cases bcdboot rewrites the entry to the same ambiguous target.
Is the dirty bit after cloning a sign of corruption?
No. It marks the filesystem as unverified rather than damaged. Here chkdsk checked 3.8 million file records and found zero bad sectors and zero orphaned files.
Can I just delete the Recovery partition to extend C:?
You can, but you lose the recovery environment and Reset this PC. Relocating it takes five steps and keeps the functionality intact.
How large should the new Recovery partition be?
Allow at least 1 GiB, and 2 GiB is a comfortable choice. Undersized recovery partitions caused the widely reported KB5034441 update failures.
Why did reagentc report success while WinRE stayed disabled?
Because ReAgent.xml held a disk GUID that no longer matched any disk. The command succeeded at its own task while the stored location remained invalid.
How long should I keep the old drive before formatting it?
At least several days, and ideally past one full Windows Update cycle. Boot problems after cloning frequently surface on the second or third power cycle rather than the first.
Summary
Windows rarely fails to boot after cloning because the boot record broke. It fails because a clone duplicates identifiers that the firmware, the volume manager and the recovery environment all assume are unique. Recognising that changes the diagnosis entirely.
The five traps documented here — the dirty bit, the wrong-disk boot, the blocked extend, the disabled controller and the stale WinRE GUID — all appeared during one migration, and all were fixed without reinstalling anything. Keep the source drive untouched until the end, and every one of them stays reversible. For the migration procedure itself, see how to clone Windows to an NVMe SSD, and for choosing the hardware, the guide to SSD storage for local AI. Microsoft documents the recovery environment configuration in the Windows RE technical reference.
Free ebook
Free AI Video, Generated Locally
Run Wan 2.1 in ComfyUI on your own GPU — the scripts I use, measured times, sample clips. No cloud, no API keys.
No spam. Unsubscribe at any time.
Leave a Reply