Boot-Test nach Festplattenklon: Lässt sich Windows ohne das Quelllaufwerk starten?
A Boot-Test für Festplattenklon Prüft, ob das Zielsystem Windows ohne das Originallaufwerk startet. Außerdem wird überprüft, auf welchem physischen Laufwerk die Installation ausgeführt wird. Wenn jedoch der Desktop bei angeschlossenen Laufwerken erreicht wird, kann dies eine Abhängigkeit vom Quell-ESP verschleiern. Diese Anleitung nutzt ein berechnetes GPT-Layout und sechs bedingte Szenarien, um diese Abhängigkeit nachzuverfolgen. Daher kombiniert das Bestehenskriterium einen unabhängigen Startvorgang mit Überprüfungen der Zielidentität.
Inhaltsübersicht
Was wird bei diesem Boot-Test für Festplattenklone überprüft?
Dieser Boot-Test für Festplattenklone stellt eine Frage: Kann das kopierte Windows über die Boot-Dateien auf dem Ziellaufwerk starten? Das Referenzsystem verwendet beispielsweise Windows x64, UEFI und GPT auf demselben Computer. Außerdem wird die Konfiguration des Speichercontrollers unverändert beibehalten. Darüber hinaus wird die Verschlüsselung außerhalb des Referenzmodells behandelt und es wird davon ausgegangen, dass die Windows-Dateien lesbar sind und eine unterstützte interne Speicherverbindung vorliegt.
Beim zentralen Vergleich wird die Verfügbarkeit des Quelllaufwerks geändert, während die Partitionsgrenzen und der Windows-Inhalt des Ziellaufwerks unverändert bleiben. Bei einer anschließenden Rekonstruktion werden die Startdateien und Boot-Verweise des Ziellaufwerks geändert. Es handelt sich daher um bedingte Modellzustände mit berechneten Adressen; das nachstehend beschriebene Verfahren zum unabhängigen Start liefert die Kriterien zur Überprüfung eines physischen Klons.
Informationen zur grundlegenden Trennung zwischen Startdateien und Windows selbst finden Sie unter Wie die EFI-Systempartition den Windows-Start unterstützt.
Einrichtung und Referenzlayout für den Boot-Test eines Festplattenklons
Artikel | Referenzannahme |
Computer und Startmodus | Derselbe Computer; Windows x64; UEFI |
Quell- und Zielkapazität | jeweils 64 GiB; 68.719.476.736 Byte |
Logische Sektorgröße | 512 Byte |
Anordnung der Partitionen | GPT; ESP, MSR, Windows, Wiederherstellung |
Partitionskapazitäten | 300 MiB, 16 MiB, 60 GiB, 1.024 MiB |
Dateisysteme | FAT32 ESP; NTFS Windows und Wiederherstellung; MSR hat kein Dateisystem |
NTFS-Zuweisungseinheit | Angenommen: 4 KiB |
Voraussetzungen für den Start | Kompatible Treiber, akzeptierte Boot-Binärdateien, lesbare Windows-Dateien |
Das Referenzlayout sorgt dafür, dass sich der Boot-Test des Festplattenklons auf die Startabhängigkeiten konzentriert. Seine Kapazitäten dienen eher als Adressbeispiel und nicht als Hardware-Spezifikation. Allerdings lässt sich anhand der gewählten Kapazität der Wiederherstellungspartition ebenfalls nicht feststellen, ob ein bestimmtes angepasstes Windows-RE-Image darauf passt.
Microsofts Leitfaden zur UEFI/GPT-Bereitstellung trennt die ESP, die MSR, die Windows-Partition und die Wiederherstellungspartition voneinander. In diesem Layout beginnt die ESP beispielsweise bei LBA 2,048, und Windows beginnt bei LBA 649,216. Die berechneten Byte-Offsets lauten 1,048,576 und 332,398,592, bzw.
Der dargestellte Vergleich zeigt die vollständigen Partitionsgrenzen, wobei für jede Partition die Kapazitäten und Adressen explizit angegeben sind.
Verfahren zum Klon-Boot-Test: Szenarien S1–S6
Verwenden Sie die folgenden sechs Bedingungen für einen Boot-Test mit Festplattenklon. Setzen Sie jeden einzelnen Fall auf den angegebenen Ausgangszustand zurück. S2, S4 und S5 sind unabhängige Änderungen an S1; S3 weist einen Zustand mit angeschlossener Quelle und einen Zustand mit isolierter Quelle auf; S6 rekonstruiert den Ziel-Startpfad nach der Isolierung in S3. Bei den sechs Szenarien handelt es sich um Bedingungen und nicht um wiederholte Hardware-Tests.
S1 – Den gesamten Klon-Boot-Pfad
Definieren Sie alle vier Zielpartitionen, die verwendbaren ESP-Zieldateien sowie die Firmware- und BCD-Verweise, die auf das Ziel verweisen. Stellen Sie außerdem sicher, dass die Quelle nicht verfügbar ist. Das Boot-Testmodell für Festplattenklone kennzeichnet diesen Pfad als für eine Überprüfung des eigenständigen Starts geeignet.
S2 – Nur für Windows
Lassen Sie die ESP-, MSR- und Wiederherstellungspartitionen weg, behalten Sie dabei jedoch den Referenzpfad der kopierten Windows-Partition bei. Da die Quelle nicht verfügbar ist, fehlen auf dem Ziel daher die für diese UEFI-Konfiguration erforderlichen ESP-Startdateien. Somit ist das Weglassen der ESP der unmittelbare Grund für das Scheitern des Startvorgangs; die anderen Auslassungen spielen jeweils eine andere Rolle.
S3 – Verborgene ESP-Abhängigkeit der Quelle
Behalten Sie die vier Partitionseinträge des Ziels bei, legen Sie jedoch fest, dass dessen ESP keine brauchbaren Windows-Startdateien enthält. Stattdessen wählt die Firmware das Quell-ESP aus, dessen BCD auf das Ziel-Windows verweist. Vergleichen Sie für diesen Boot-Test des Festplattenklons dasselbe Ziel vor und nach der Quellisolierung. Gehen Sie davon aus, dass kein alternativer brauchbarer Startpfad vorhanden ist.
S4 – Klon-Boot-Test im falschen Firmware-Modus
Behalten Sie das Ziel-Layout und die Dateien von S1 bei, wählen Sie jedoch auf einem Rechner, der diesen Modus unterstützt, den Startmodus ’Nur Legacy“ aus. Daher kann der Standardpfad für Windows UEFI/GPT bei dieser Auswahl nicht ausgeführt werden.
S5 – Klon-Boot-Test mit einer veralteten Windows-Referenz
Halten Sie das Ziel-ESP erreichbar, legen Sie jedoch fest, dass dessen BCD-Windows-Geräteverweis auf eine nicht verfügbare alte Partitionskennung verweist. Gehen Sie davon aus, dass kein anderer gültiger Loader-Eintrag vorhanden ist. Infolgedessen wird die Kette vor der beabsichtigten Windows-Installation unterbrochen.
S6 – Den Ziel-Boot-Pfad neu erstellen
Beginnen Sie mit einem isolierten S3-Zustand, legen Sie die ESP-Startdateien des Zielsystems sowie die BCD-Verweise auf das Ziel-Windows fest und definieren Sie anschließend eine Firmware-Auswahl, die zu diesem ESP führt. Bewerten Sie den Abhängigkeitspfad erneut. Ein zulässiger Modellzustand erfordert jedoch weiterhin einen tatsächlichen isolierten Startvorgang, um das Bestehenskriterium zu erfüllen.
Verwenden Sie für eine physische Validierung ein gesichertes Migrationsziel oder ein Einweg-Testlaufwerk. Überprüfen Sie zunächst vor dem Kopieren oder der Reparatur die Quelle und das Ziel anhand der Geräte-ID und der Kapazität. Bewahren Sie das Originallaufwerk auf, bis das Ziel die unabhängige Startprüfung bestanden hat.
Ergebnisse des Boot-Tests für Festplattenklone: Vor und nach der Isolierung
Vergleichen Sie bei diesem Boot-Test mit Festplattenklon die ausgewählter ESP-Besitzer mit der unveränderten Windows-Partition. Die folgenden Abbildungen sind beispielsweise gerenderte Ansichten des bedingten Modells, bei denen dasselbe Ziel, dieselbe Feldreihenfolge und dieselben Adressbereiche verwendet wurden.
Vor der Isolierung: Ein erreichbarer Cross-Drive-Pfad
S3 vor der Isolierung: Die Quelle ESP stellt den Windows-Boot-Manager und die BCD bereit, während sich die Windows-Installation auf dem Ziel P3 befindet. Die modellierte Kette ist erreichbar, der Start hängt jedoch von der Quelle ab.
In diesem Fall besteht beim Aufrufen des Windows-Desktops weiterhin eine Abhängigkeit vom Quelllaufwerk. Bei einem Boot-Test mit einem Festplattenklon können daher bei einer Überprüfung von Windows allein die Startdateien des Quelllaufwerks übersehen werden.
Nach der Isolierung: Das gleiche Ziel verfügt über keinen verwertbaren Startpfad
S3 nach der Isolierung: Ziel P3 und dessen Grenzen bleiben unverändert. Die ausgewählte Quelle ESP ist nicht mehr verfügbar, und Ziel P1 verfügt über keine verwendbaren Startdateien, sodass die definierte Kette blockiert wird.
Die geänderte Eingabe ist die Verfügbarkeit der Quelle. Das Modell löscht Windows nicht und konvertiert dessen NTFS-Volume auch nicht in RAW. Stattdessen wird der Zugriff auf das ESP gesperrt, das den Startpfad bereitgestellt hat. Infolgedessen könnte ein entsprechendes physisches Symptom ein Firmware-Startauswahlbildschirm oder ein Startfehler sein; der genaue Wortlaut hängt von der Firmware und den verfügbaren Fallback-Einträgen ab.
Nach der Wiederherstellung: Die Startvoraussetzungen werden auf das Ziel abgestimmt
S6: Das Ziel-ESP stellt die Startdateien bereit, die Firmware-Auswahl erreicht Ziel P1 und BCD wird zu Ziel P3 aufgelöst. Der modellierte Pfad erfüllt die Voraussetzungen für eine Überprüfung auf unabhängigen Start.
Durch die Rekonstruktion ändern sich die Startabhängigkeiten, während der Speicherort der Windows-Partition beibehalten wird. Nutzen Sie den interaktiven Vergleich, um alle sechs Starttestszenarien für Festplattenklone und die berechneten Partitionsadressen zu überprüfen.
Interaktiver Vergleich von Clone-Boot-Tests
Vergleichen Sie die Szenarien und überprüfen Sie anschließend die Partitionsadressen.
S2 kopiert Windows, lässt dabei jedoch ESP, MSR und Recovery außer Acht.
Klicken Sie auf die Partitionen, um die Adressen anzuzeigen; wischen Sie auf schmalen Bildschirmen. Rot: fehlende Partitionen/Boot-Dateien. Grün: rekonstruiertes ESP.
Die Breiten sind schematisch dargestellt. Gestrichelte Lücken können zusammenfallen. GPT-Metadaten, Ausrichtungslücken und freier Speicherplatz am Ende (2,69 GiB) wurden weggelassen.
Partitionsadressen
| Partition | Kapazität | Format | Start-LBA | Ende LBA | Byte-Offset |
|---|---|---|---|---|---|
| P1 · ESP | 300 MiB | FAT32 | 2,048 | 616,447 | 1,048,576 |
| P2 · MSR | 16 MiB | Keine | 616,448 | 649,215 | 315,621,376 |
| P3 · Windows | 60 GiB | NTFS | 649,216 | 126,478,335 | 332,398,592 |
| P4 · Recovery | 1.024 MiB | NTFS | 126,478,336 | 128,575,487 | 64,756,908,032 |
Disk-absolute LBAs, inclusive. Offset=LBA×512. Last usable:134,217,694; tail:5,642,207 sectors. S3/S6 boundaries unchanged.
Szenarien
| Fall | Zustand | Modeled path |
|---|---|---|
| S1 | Full clone | Eligible |
| S2 | Windows only; no ESP | Blocked |
| S3 | Source ESP | Connected: reachable; isolated: blocked |
| S4 | Legacy mode | UEFI blocked |
| S5 | Stale BCD | Windows blocked |
| S6 | Rebuilt ESP | Eligible |
Eligible paths still require actual source-isolated startup and target identity checks.
Why a Cloned Disk Can Fail to Boot
A disk clone boot test checks several links in the startup chain. Firmware entries, ESP contents, and BCD configuration each play a separate role. First, firmware selects an EFI application. Next, Windows Boot Manager reads the boot configuration and starts the Windows loader. Therefore, an ESP partition can exist while its files are missing, or valid files can exist while the selected boot reference points elsewhere.
Die UEFI Boot Manager specification describes firmware boot options and their device paths. Copying disk contents does not, by itself, copy the motherboard’s NVRAM configuration.
Partition identity also matters. A partition’s type GUID identifies its role; its unique GUID identifies that partition. Amagicsoft’s GPT partition entry structure and GUID fields explain that distinction. If a migration changes identities, boot references must still resolve correctly. If cloning preserves identities, those copied GUIDs cannot distinguish the physical source from the target reliably.
Likewise, a valid GPT header and its checksums establish partition-metadata consistency, rather than a complete Windows startup path. S3 keeps the target layout fixed while changing whether its external startup dependency remains available.
How to Run an Independent Clone Boot Test
Therefore, the following disk clone boot test steps connect startup checks to the target’s physical identity.
Record the Target and Isolate the Source
- Record physical identity. Before shutdown, note the target’s model, serial number or device identifier, capacity, and connection location. In Windows,
Get-Disk | Format-List Number,FriendlyName,SerialNumber,UniqueId,Guid,Size,Location,IsBoot,IsSystemprovides useful fields. Cross-check identifiers because adapters can omit or alter what they expose. - Make the source unavailable to firmware. Shut down fully, then disconnect the source safely or use a documented firmware setting that actually removes its storage path. Remove recovery USB media and other drives that could supply startup files. The source must be unavailable to firmware during the disk clone boot test. Setting it offline inside Windows is insufficient because firmware runs earlier.
- Select the target startup path. Keep the appropriate UEFI mode and existing security policy. Next, choose the Windows Boot Manager entry associated with the target. An entry’s display name alone may not identify the physical device.
Verify Windows and Its Startup Partition
- Start Windows and map its partition. Verwenden Sie
Get-Partition -DriveLetter C | Get-Diskwhen the running Windows installation usesC:. Then, match the returned device to the recorded target. Adjust the letter if necessary; disk numbers and drive letters can change between environments. - Check the startup partition too. Prüfen
Get-Partition | Format-Table DiskNumber,PartitionNumber,DriveLetter,IsBoot,IsSystem. Windows terminology distinguishes the running Windows partition from the system partition containing startup files. With alternative startup drives unavailable, confirm both roles map to the intended target. - Check a further startup and representative files. Perform a restart and a full shutdown/startup with the source still unavailable. Also, open important documents and applications. Record startup verification and file checks separately, because a working boot path does not establish that every copied file is intact.
Microsoft documents the Get-Partition queries, partition status properties, und disk identity properties. Use those fields together with source isolation and the physical device record.
When a Clone Boot Test Points to Startup Repair
If Windows is readable but its ESP files or BCD need repair, Microsoft BCDBoot can rebuild the boot environment. First, identify the target Windows directory and its ESP. Drive letters in recovery mode can differ from normal Windows.
One detail matters when interpreting a repair: specifying BCDBoot’s /s option directs the system-partition destination but does not create a firmware NVRAM entry. A file-copy completion message therefore leaves firmware selection as a separate check. The S6 model includes both corrected target files and a working target firmware selection. After repair, repeat the disk clone boot test with the source still unavailable.
If the target instead appears RAW, has missing partitions, or reports read errors, reassess its layout, file-system state, and clone completeness before writing repairs. A missing boot entry alone does not explain a RAW Windows volume. Preserve recoverable files before further changes when the source or target is damaged.
Schlussfolgerung
Eine nützliche Boot-Test für Festplattenklon ends with an identified target starting Windows independently. The central comparison explains why that standard matters: Windows can occupy the target while the selected ESP remains on the source. Isolating the source exposes the dependency without changing the target’s Windows partition.
Judge the migration in stages. First check the target layout and startup files. Next make the source and alternative startup media unavailable. Then start Windows and verify the physical target and startup partition. Keep the original drive until those checks succeed, and validate important files separately. This distinguishes a complete copy operation, a coherent startup configuration, and a verified independent startup—three results that require different evidence. Complete the disk clone boot test before you erase or reuse the original drive.
Disk Clone Boot Test FAQ
Kann ein Klon auf ein anderes Motherboard übertragen werden?
Kann BitLocker den ersten Systemstart nach dem Klonen beeinträchtigen?
Ist für ein größeres Reiseziel ein anderer Test erforderlich?
Bedeutet das Fehlen von Windows RE, dass Windows nicht gestartet werden kann?
Sollte „Secure Boot“ für den Test deaktiviert werden?
Wird durch diesen Vorgang eine USB-Boot-Installation validiert?
