Windows Server Event 58 von partmgr (Die Signatur des Datenträgers …)

Problem

Dateisystems-Snapshots eines Windows-Gastsystems welche VSS nutzen (sollen) funktionieren nicht korrekt. Die jeweiligen VSS-Trigger geben eine wirre Fehlermeldung aus (vCenter Quiescence error/KVM Ruhelage fehler/Hyper-V Snapshot Abbruch). Das Gast-Windows zeigt im Ereignisprotokoll einen „Event 58“ von der Quelle „partmgr“. Der Inhalt lautet

Die Datenträgersignatur von Datenträger <foo> ist mit der Datenträgersignatur von Datenträger <bar> identisch.

Der Fehler im (zum Beispiel) vmware-Gastprotokoll lautet:

Beim Stilllegen der virtuellen Maschine ist ein Fehler aufgetreten.
Weitere Informationen finden Sie im Ereignisprotokoll der virtuellen Maschine.

Under den Details ergänzt sich dies noch um folgendes:

Das Gastbetriebssystem hat während der Stilllegung einen Fehler gemeldet.
Der Fehlercode lautet: 3 Die Fehlermeldung lautet: Error when notifying the sync provider.

Lösung(en)

Es gibt mehrere möglich Ursachen. Eine Lösung dieser Liste hat bei unseren Fehlern bisher immer geholfen, wenn das bei dir nicht helfen sollte, schreibe einen Kommentar. Wir sind neugierig was noch so gibt.

1. Doppelte SCSI-ID (vmware)

Eine Pfad-ID (nicht Disk-ID!) für ein virtuelles Laufwerk kann unter bestimmten, aber ziemlich wirschen, Bedingungen auch mehrfach vergeben werden. Zum Beispiel wenn eine Disk auf der ESX-Shell kopiert (Bit-Copy) oder via abgestürztem Transport-Proxy in Veeam gesichert werden sollte.

Lösung: Eine neue Pfad-ID erzeugen, indem das Laufwerk von der VM getrennt wird (nicht löschen!), das Fenster geschlossen und dann das Laufwerk mit einer neuen SCSI-ID wieder angehöngt wird. Dann gibt es es einen komplett neuen Pfad und Windows findet die Platte beim nächsten Reboot zuverlässig am „neuen“ Strang. Fehler behoben.

2. Doppelte Disk-ID

Es ist technisch möglich, das eine Disk-ID zweimal vergeben wird. Das passiert schon mal unbeabsichtigt bei P2V/V2V oder P2P vorgängen, oder wenn man den Haken bei „Volumenidentifizierung beibehalten“ setzt. In seltenen Fällen auch mal dazwischen, wenn dd im Spiel ist. Achtung: Unter Hyper-V und vmware betrifft das auch die Disk-ID von Remote-Laufwerken (SAN/NAS via FC und iSCSI, vor allem RAW) – also alles was der jeweilige Host „sehen“ kann.

Lösung: Eine neue Disk-ID vergeben. An einem Administrator-Prompt die passende Disk auswählen und mit uniqueid behandeln:

C:\>DISKPART
DISKPART> list disk
  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
  Datenträger 0    Online          949 GB  1024 KB
  Datenträger 1    Online         1965 GB  1024 KB
DISKPART> select disk 0
Datenträger 0 ist jetzt der gewählte Datenträger.
DISKPART> uniqueid disk
Datenträger-ID: 5044D2AF
DISKPART>

Um dise ID zu ändern:

UNIQUEID DISK ID=DEADBEEF

Möglicherweise bootet Windows danach nicht mehr freiwillig. Einfach von einem passenden Installationsdatenträger booten, die Kommandozeile öffnen und den BCD wieder auf die korrekte (neue) ID einschiessen lassen:

X:\SOURCES> bootrec /fixboot
X:\SOURCES> bootrec /scanos
X:\SOURCES> bootrec /rebuildbcd

Dann klappts auch wieder mit dem Windows.

3. Der Geist eines toten Volumens

Eventuell hängen im Gerätemanager („ausgebelndete Geräte anzeigen“) ja auch noch ein paar tote Volumen herum, die sich aber auch äußerst hartnäckig dem entfernen wiedersetzen. Diesen rückt man besten mit Microsoft DevNodeClean zuleibe. Seltsame Devices entfernen (lassen), Reboot und alles ist wieder gut.

1. DevNodeClean bei Microsoft herunterladen
2. An einer Administrativen Shell mit

   DevNodeClean /N

   die Devices auflisten (wenn nichts angezeigt wird, gibt es keine verwaisten Eintröge)

3. Wenn notwendig, direkt an der Shell mit

   DevNodeClean

   die Devices entfernen. Der Erfolg lässt sich mit /N kontrollieren.

4. Reboot, fertig 🙂