Die VHDX kann doch einfach über den [i][b]wbAdmin.exe[/b][/i] command erstellt werden. Damit sie bootet, müssen lediglich die übernommenen "[i]MountPoints[/i]" in der Registry gelöscht werden.
>> reg delete HKLM\OFFLINE\MountedDevices

DISKPART> list part

  Partition ###  Typ               Größe    Offset
  -------------  ----------------  -------  -------
  Partition 1    System             100 MB  1024 KB
  Partition 2    Reserviert          16 MB   101 MB
  Partition 3    Primär             126 GB   117 MB
  Partition 4    Wiederherstellun  1025 MB   126 GB

  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
* Datenträger 2    Online          128 GB      0 B        *

Gerade mal getestet. disk2vhd64 erdstellt mir ein 1:1 Abbild der Host-SSD in der .vhdx:

[code]DISKPART> list part

Partition ### Typ Größe Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserviert 16 MB 101 MB
Partition 3 Primär 126 GB 117 MB
Partition 4 Wiederherstellun 1025 MB 126 GB[/code]

Die besagte $MSR ist vorhanden und das Abbild ist auch mit GPT:

[code] Datenträger ### Status Größe Frei Dyn GPT
--------------- ------------- ------- ------- --- ---
* Datenträger 2 Online 128 GB 0 B *[/code]

Ob die jetzt in Hyper-V Gen2 bootet, kann ich nicht sagen, da ich Hyper-V nicht verwende. Müsste mal jemand mit Hyper-V testen. Ich sehe da im Moment keinen Grund, dass das nicht klappen sollte.

Der Unterschied zwischen DISM und Disk2VHD ist mir durchaus bewußt, ich arbeite mit beiden Tools.
Ich habe lediglich angemerkt, daß eine fehlende MSR ein System/Backup nicht unbootbar macht.

[quote=g-force post_id=460108 time=1783384963 user_id=37652]
"Nicht bootbar" und "fehlende MSR" decken sich nicht mit meinen Erfahrungen. Auch andere Tools wie das Windows-eigene DISM ignorieren in bestimmten Situationen die MSR beim Backup. Beim Restore stellt das aber kein Problem dar, Windows bootet ohne Probleme auch ohne die MSR.
[/quote]
Du unterstellst die Funktionsgleichheit von disk2vhd(64) und DISM und ziehst daraus einen falschen Schluss.

"Nicht bootbar" und "fehlende MSR" decken sich nicht mit meinen Erfahrungen. Auch andere Tools wie das Windows-eigene DISM ignorieren in bestimmten Situationen die MSR beim Backup. Beim Restore stellt das aber kein Problem dar, Windows bootet ohne Probleme auch ohne die MSR.

Natürlich gibt es einen Standardweg, um ein bootbares VHD(X)-Image von einer Windows 10 UEFI-Installation herzustellen. Das ist kompliziert. Würde ich nie machen.
Früher - zu "MBR-Zeiten" - habe ich ein VHD-Imge oft mit disk2vhd(64) hergestellt, wenn ich sowas für Virtualdisk gebraucht habe.
Das funktioniert allerdings mit einer UEFI-Installation nicht mehr: das erzeugte VHD(X)-Image ist nicht bootbar.
Der Grund: disk2vhd(64) ignoriert die 16MB RAW-Partition. Sie fehlt dann im VHD(X)-Image.
Was nun?
Also wie oben: Sergei Strelecs Reparatur-ISO starten. Das mit disk2vhd(64) erzeugte (und fehlerhafte!) vhdx-Image in der Datenträgerverwaltung als virtuelle Festplatte anfügen und dann wie oben mit Paragon reparieren. Dieses intelligente Tool fügt die fehlende 16MB RAW-Partition in das Partitionslayout ein und macht das VHDX-Image bootbar.
Voilà!

Interessant; nicht mal Testdisk kommt damit klar, aber Third Party schon....

System: W10 mit GPT-Partitionierung, Asus Z97M-PLUS, 16GB RAM, Samsung SSD 860 EVO 500GB, Zustand lt. CrystalDiskinfo: Gut: 96%.

Fehler: SSD ist nicht bootbar und erscheint nicht mehr im F8-Bootmenü.

Eine probeweise in den 2. Slot meines 2,5-Zoll-SATA-Wechselrahmens eingeschobene W10-SSD, ebenfalls mit GPT-Partitionen, bootet und wird im F8-Boot-Menü angezeigt.

Im Festplattenmanager der gebooteten 2. SSD erscheint nun die nicht bootbare 1. SSD als nicht initialisiert, mit der Aufforderung sie zu initialislieren - was bekanntenmaßen zur Zerstörung der Partitionsdaten führen würde.

Ich starte also die Sergei Strelec Reparatur-ISO auf dem Ventoy-Stick und prüfe zuerst, was testdisk zu beiden SSDs sagt: nur die bootbare 2. SSD wird überhaupt erkannt.
Testdisk ist bekanntermaßen das Tool was "alles" erkennt: vor allem durcheinander geratene Partitionstabellen können repariert werden, aber hier wurde bei der 1. SSD überhaupt nichts angezeigt.
Die Rettung: Reparatur mit dem Paragon Harddisk Manager 17 Business auf der Sergei Selec-ISO.
Überraschend war, dass schon vor der Reparatur das Partitions-Layout der 1. SSD - wie im Screenshot - richtig angezeigt wurde.
Die Anwendung der gekennzeichnete Funktion führte dann dazu, dass die SSD wieder normal funktionierte. "[attachment=0]Correct boot_2026-6-15 11-11-12.png[/attachment]