In Teil 1 hatte ich das Problem skizziert, dass nach dem Zurücklesen einer Systemabbildsicherung nach jedem Neustart immer ein Dialogfeld der Wiederherstellung erscheint, in dem gefragt wird, ob die Benutzerdateien wiederherzustellen sind. In Teil 2 und Teil 3 findet sich die Odyssee meiner Fehlerdiagnose. Nun kristallisiert sich so langsam eine Form heraus und es kommt Licht in die Problematik.
Anzeige
Diagnosehost: Einige Teilerkenntnisse auf dem Weg zum Ziel
Ein klitzekleines Stückchen bin ich wohl weitergekommen. Mein Thread im Technet-Forum [1] hat dazu geführt, dass sich Miya Yao (MSFT CSG – wohl Customer Service Group) des Problems angenommen hat und nun mit mir rumrätselt, wie man dem Thema beikommen könnte.
Eine Erkenntnis meiner Fehlersuche ist, dass ein Dienst Diagnosesystemhost wohl für die Meldung verantwortlich ist. Nur habe ich keine Ahnung, was das Teil intern alles veranstaltet. Zweite Erkenntnis, die mir heute Morgen gekommen ist und von Miya durch Analyse der Screenshots bestätigt wurde: Es laufen wohl keine "Schweinereien" hinter den Kulissen ab. Der Grund, warum ich weder Dateien noch Registrierungseinträge finde, ist einfach – diese Einträge werden wohl on-the-fly generiert und nach dem Start des Task auch sofort wieder gelöscht.
Anzeige
Das ist natürlich doppelt doof, denn dann habe ich als Administrator oder Supporter überhaupt keine Chance, hinter die Problemursache zu steigen. Auch eine Identifizierung des Task AfterRecovery in der Aufgabenplanung ist nicht möglich. Das Beste, was ich machen kann: Die Liste der aktiven Tasks öffnen und die Aufgabe abbrechen. Ein Export der Taskeigenschaften in eine XML-Datei zwecks Analyse der Aufrufparameter etc. ist so natürlich nicht möglich. Dies habe ich zwischenzeitlich mit Screenshots unter [1] dokumentiert.
Nun bleibt die spannende Frage, ob da noch ein paar Interna aus den Microsoft Entwickler-Labors zum Vorschein kommen oder nicht. Ich habe das Problem ja zwischenzeitlich recht weit getrackt und auf den Diagnosesystemhost runtergebrochen. Dort führen aber meine Recherchen ins Leere, weil über die ganzen Interna nichts veröffentlicht wurde. Und wenn ich im Internet nach der Problemursache suche, komme ich auf meine Threads und Technet-Diskussionen zurück. Ein Teufelskreis …
Backup-Probleme durch OEM-Partition?
Während der Diskussion im Technet-Forum [1] hatte ich den glücklichen Fall, dass im Process Monitor zufällig ein paar weitere Infos mit aufgezeichnet wurden. Die Angelegenheit ist ja etwas kniffelig, da ich den Process Monitor nach der Anmeldung zwar über Autostart aufrufe. Dann kommt aber die Benutzerkontensteuerung, in der ich die Task als Administrator freigeben muss. Nur wenn ich schnell genug bin, startet der Process Monitor vor dem Task des Diagnosehost und die Datei- sowie Registry-Zugriffe werden protokolliert.
Bei der Auswertung stieß ich dann auf Zugriffe auf den Pfad:
C:\windows\logs\Backup
die mich neugierig machten. Ich habe dann diesen Ordner inspiziert und fand Dateien wie SystemImage.0.etl und weitere Dateien in der Art Windows Backup.x.etl files (x = 1, 2, 3 …) mit unterschiedlichen Zeitstempel. Zwischenzeitlich habe ich einen weiteren Ordner SystemRestore in logs gefunden. Auch dieser enthält .etl-Dateien. Solche .etl-Dateien lassen sich in der Ereignisanzeige laden (einfach einen Zweig in der linken Spalte mit der rechten Maustaste anwählen, und den Kontextmenübefehl zum Öffnen anklicken).
Die Auswertung ergab, dass sowohl WindowsBackup als auch Restore Informationen in die Log-Dateien eintrugen, dass für bestimmte GUID-Datenträger keine Format-Informationen gefunden wurden. Ist natürlich mysteriös, da die Festplatte als MBR-Datenträger partitioniert wurde, so dass keine GUIDs verwendet werden.
Auch über BCDedit konnte ich keine entsprechenden GUIDs finden und meine Inspektion der MountDevices im Registrierungsschlüssel
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
führte bisher nicht weiter (in der Registrierung findet sich kein GUID-Wert, der mit den .etl-Dateien korrespondiert. Aber mir fiel dann ein, dass ich eine versteckte, vierte OEM-Partition auf dem MBR-Datenträger habe. In der Datenträgerverwaltung der Computerverwaltung war da nicht viel zu machen. Also die Eingabeaufforderung cmd über den Kontextmenübefehl Als Administrator ausführen gestartet und dann das Programm diskpart aufrufen. Als ich mir die Partitionen der disk 0 auflisten ließ, wurde die OEM-Partition angezeigt.
Eine Inspektion mittels diskpart [3] ergab mit den folgenden Befehlen:
details disk
details volume
dann folgende Informationen:
Die OEM-Partition taucht nicht als Volume auf und ist mit dem Disktyp 12 gekennzeichnet. Es handelt sich also um eine versteckte OEM-Partition. Laut Medion [4] enthält die OEM-Partition ein WinRE für die Recovery-Funktion.
Möglicherweise kann Windows über seine APIs auf diese Partition lesend zugreifen. Als ich meine Vermutungen im Technet-Forum [1] postete, tauchte ein zweiter Benutzer mit dem Problem auf, der auch eine OEM-Partition hatte. Dort fand er eine Datei Recovery.txt, die er löschte und damit das Problem behob. Auch unter [5] tauchte ein Benutzer auf, der eine OEM-Partition auf der Platte hatte. Nachdem dieser die Partition formatierte, war das Problem weg.
Aktuell kann ich nicht auf die OEM-Partition zugreifen, möchte diese jetzt aber auch nicht auf die Schnelle löschen (da ich noch einige Sachen analysieren will). Von daher werde ich die Tage wohl einen Partitionseditor auf dem System installieren und der OEM-Partition zu Leibe rücken. Gut möglich, dass da der "Hund begraben" liegt. Meine Diskussion im Technet-Forum hat aber dazu geführt, dass das Problem an die Entwickler weiter gemeldet wurde. Denn es "riecht" schon stark nach einem Bug, der mit dem SP1 in die Windows-Backup-Funktion Einzug hielt.
Weitere Erkenntnisse trage ich hier oder in Teil 5 nach …
… nun habe ich genügend Zeit mit dem Problem verbraten und muss mich dringend der Fertigstellung eines Buchmanuskripts widmen (bin schon eine Woche über den Termin – und daher fehlt mir auch etwas die Zeit zum Bloggen). Aber nächste Woche ist vielleicht etwas mehr Luft. Vielleicht kann ich es dann auflösen.
Links:
1: Diskussion im Technet-Forum (Englisch)
2: Diskpart Befehlszeilenoptionen (Englisch)
3: Diskpart Befehlszeilenoptionen (Deutsch)
4: Infos zu Medion OEM-Partition
5: Forendiskussion bei sevenforums (Englisch)
Artikel:
a: Meldung "Die Wiederherstellung wurde abgeschlossen" Teil 1
b: Meldung "Die Wiederherstellung wurde abgeschlossen" Teil 2
c: Meldung "Die Wiederherstellung wurde abgeschlossen" Teil 3
d: Meldung "Die Wiederherstellung wurde abgeschlossen" Teil 4
e: Meldung "Die Wiederherstellung wurde abgeschlossen" Teil 5
Anzeige