Kürzlich bin ich auf einem System beim Zurücklesen einer Systemabbildsicherung mit dem Fehler 0x80070057 konfrontiert worden. In Teil 1 habe ich mögliche Lösungen beschrieben, die bei mir aber (erwartungsgemäß) nichts gebracht haben. In Teil 2 möchte ich euch daher einen sauberen Diagnoseansatz und die für mich zutreffende Lösung aufzeigen.
Anzeige
Vorbemerkungen über Foren, Gott und die Welt
In Teil 1 habe ich ja die Lösungen beschrieben, die einem von Microsoft oder in Foren von Halbwissenden so als ultimative Lösungen an den Kopf geworfen werden. Wie bereits ausgeführt, hat keine der Lösungen bei mir (erwartungsgemäß) funktioniert. Um keine Zweifel aufkommen zu lassen – es ist gut, dass Microsoft KB-Artikel zu solchen Problemen publiziert und es hilft so manchem geplagten Anwender, wenn in einem Forum der Hinweise kommt: "das habe ich so gelöst". Was mich aber zunehmend nervt, ist die Qualität der Forenbeiträge ('musste einen schnelleren Rechner nehmen und siehste, was Du von Aldi-Schrott hast' – oder 'stelle das Format um, dann funktioniert es'). Gut, fairerweise muss ich gestehen, es gibt Forenpostings, da sagst Du vom Gefühl "das kann nur die und die Lösung sein, die hilft". Aber in der Regel muss man den Kontext berücksichtigen, wo der Fehler auftritt. Alles was zu Windows 7 mal Wahrheit war, ist in Bezug auf den Backup-Fehler 0x80070057 teilweise Makulatur (weil Microsoft nachgebessert hat).
Da ich in Teil 1 die schnelle Lösung wollte und dann länger brauchte, ist mir bewusst geworden, wie wenig manchmal Forenbeiträge taugen. Wer nach dem Backup-Fehler 0x80070057 sucht, wird quasi von Treffern erschlagen. Mehr als Anregungen können diese Fundstellen nicht liefern. Das war auch die Motivation für mich, in Teil 1 mal eine möglichst geschlossene Darstellung mit einen Hintergrundinformationen und Einschätzungen zu verfassen, obwohl ich genau wusste, dass es für meinen Fall nicht hilft. Und die Qualität der Screenshots bitte ich zu entschuldigen – ich musste unter Windows PE mit einer Kamera arbeiten, da Screenshots dort nicht möglich sind (mir ist nichts bekannt, was ich hätte auf die Schnelle einsetzen können).
Saubere Analyse ist gefragt …
Ich hatte ja am Ende von Teil 1 ausgeführt, dass ich zur Erkenntnis gelangt bin, dass nun nur die Trickkiste helfen konnte. Na ja, mit "klicke hier und hoffe da" war ich ja weniger erfolgreich. Also musste ein Diagnoseansatz her, mit dem ich ggf. mehr zum Fehler herausfinden konnte. Die Site Network Steve hat hier eine längliche Diskussion um den Backup-Fehler 0x80070057 unter Windows 7. Da sammelte auch ein Microsoft Mitarbeiter Informationen über den Backup-Fehler und ließ irgendwann im Thread die Info fallen, dass man den Inhalt von <<SystemDrive>>\Windows\Logs\WindowsBackup in ein ZIP-Archiv packen und ihm zusenden könne. Da der Thread bereits uralt war, hätte das nichts gebracht. Aber der Pfad zu den Log-Dateien war die Initialzündung für mich.
Leichter gesagt als getan – denn wie wertest Du Log-Dateien in Windows PE aus und gibt es dort überhaupt so etwas? Und hier kommen wir zur Trickkiste, die ich, zwar nicht aus dem Keller, sondern aus dem Hinterkopf, hervorgekramt habe.
Anzeige
1. Ich habe den Rechner in Windows PE gebootet, die Schritte zum Einspielen des Backup durchlaufen lassen und auf den Fehler 0x80070057 gewartet.
2. Beim Auftreten des Fehlers habe ich das Dialogfeld des Backup-Assistenten geschlossen und fiel wieder in die Windows PE-Umgebung mit den Optionen zurück.
3. Dort bin ich wieder über Erweiterte Optionen zu obiger Auswahl gegangen und habe die Eingabeaufforderung aufgerufen.
4. Dort habe ich den Befehl notepad eingetippt und die Eingabetaste gedrückt, um den Windows-Editor Notepad aufzurufen.
5. In Notepad habe ich dann im Menü Datei den Befehl Öffnen gewählt und im Dialogfeld Öffnen den Filter für den Dateityp auf "Alle Dateien" gestellt.
Damit hatte ich quasi einen Mini-Dateimanager, der mir alle Laufwerke und Dateien im Dialogfeld Öffnen anzeigt.
6. Anschließend bin ich zum Windows-Ordner der Windows PE-Umgebung navigiert und habe mir die Unterordner \Windows\Logs\ mal angeschaut.
Der Ordner sah wie im obigen Bild aus – da war zwar kein Unterordner Backup, aber zwei Ordner sahen verdammt gut aus. Also im "Mini-Dateimanager" des Öffnen-Dialogfelds in die Ordner geschaut – und tatsächlich waren dort zwei Log-Dateien – aber nicht im Textformat als .log, sondern als .etvx-Dateien der Windows Ereignisprotokollierung. Diese sind im Editor aber unlesbar.
Danach habe ich per Kontextmenü die Dateien aus den beiden Unterordnern im Öffnen-Dialogfeld auf die zweite Festplatte der Basiseinheit des Akoya P2212T kopiert. Danach wurde der Rechner wieder heruntergefahren und die Werksinstallation von Windows 8.1 erneut gebootet. Danach waren die Log-Dateien unter Windows PE natürlich weg, aber ich hatte die Kopien auf einer separaten Festplatte.
Und was sagt die Ereignisanzeige?
Jetzt folgt quasi eine Art Dreisprung. Nachdem ich die .etvx-Dateien auf der separaten Festplatte gesichert und danach Windows 8.1 neu gebootet habe, konnte ich die Ereignisanzeige zur Analyse einsetzen.
1. Rechtsklick auf die Start-Schaltfläche in der linken Ecke der Taskleiste des Windows-Desktop und den Befehl Ereignisanzeige im Schnellzugriffmenü wählen.
2. Über den oben gezeigten Kontextmenübefehl Gespeicherte Protokolldatei öffnen des Eintrags Benutzedefinierte Ereignisse ließ sich dann die .etvx-Datei auswählen und über folgendes Dialogfeld in der Ereignisanzeige einbinden.
Und in der dann in der Ereignisanzeige sichtbaren Seite kamen die Fehlereinträge zum Vorschein.
Per Doppelklick lässt sich ein Ereignis im Detail anzeigen und es wurde dann der folgende Fehler gemeldet.
Klasse, im Ereignis wurde mir gemeldet, dass keine Formatinformationen für das betreffende Speichermedium gefunden wurde. Ich bin dann die Treffer durchgegangen und habe überall diese Info gefunden. Da war irgendwie schon klar, dass da was faul war.
Formatierung unmöglich, Dateiprüfung verzögert, Partitionsstruktur kaputt
Mein Versuch, die Windows-Partition per diskpart in der Eingabeaufforderung von Windows PE zu löschen, hatte zwar in einem Durchlauf geklappt, aber keine Besserung gebracht. Als ich von einem USB-Stick mit den Windows 8.1-Installationsdateien bootete, den Setup-Assistenten durchlief und dann die Partition mit dem Windows-Laufwerk formatieren wollte, erhielt ich diese Meldung.
Ein Zurücklesen der Systemabbildsicherung endete irgendwann auch mit der folgenden Fehlermeldung.
Da musste was gravierenderes kaputt sein – auch wenn ich die Windows-Partition durch das Recovery frisch zurück geschrieben hatte. Ich hatte mir die Partitionsstruktur in der Datenträgerverwaltung angesehen und wusste, dass dort ein 190 MByte großer unpartitionierter Bereich auf der Festplatte vorlag.
Löschen der Boot-Partition mit Windows brachte nichts, beim Recovery blieb der unpartitionierte Bereich erhalten. Das Löschen der 499 MByte Wiederherstellungspartition hatte mich in Teufels Küche gebracht (siehe Teil 1). Die OEM- und UEFI-Partitionen konnte ich (erwartungsgemäß) in der Datenträgerverwaltung ebenfalls nicht löschen.
Ich wollte dann unter dem installierten Windows 8.1 eine Datenträgerprüfung ausführen (Rechtsklick auf das Laufwerk, Kontextmenübefehl Eigenschaften und unter Tools die Schaltfläche Prüfen wählen).
Als ich die obigen Dialogfelder (im Vordergrund) sah, wurde ich bereits stutzig. Microsoft hatte doch unter Windows 8 als große Innovation die Tatsache gefeiert, dass das Systemlaufwerk im laufenden Betrieb geprüft werden kann. In obigem Dialogfeld wurde mir gesagt, dass das Laufwerk nicht repariert werden könne und ich einen Neustart bräuchte. Nicht wirklich gut – denn mir war nicht bekannt, dass Microsoft die Online-Prüfung unter Windows 8.1 entfernt hatte.
Da war doch was: Partitionsänderung verunglückt
Da ich die Maschine kannte, kam mir ein Verdacht: Ich hatte von Paragon-Software bei einem Test den Paragon Diskmanager 2014 Free eingesetzt, um die Windows 8.1-Partition etwas am Anfang zu verkleinern. Daher stammten die unpartitionierten 190 MByte auf der SSD. Damals fiel mir bereits auf, dass die Free-Edition des Diskmanagers sehr langsam lief und irgendwie nicht richtig zu Potte kam. Aber ich hatte eine Partitionsänderung durchgeführt (wollte sehen, ob danach das Recovery noch funktioniert).
Also mal wieder die Free-Edition des Diskmanagers installiert und versucht, die Windows-Partion zurück zu schieben, um den unpartitionierten Bereich zu bereinigen. Das klappte aber nicht, die Free-Edition weigerte sich, irgend etwas zu tun. Dann habe ich die Paragon Festplattenmanager Suite 2014 in der 64-Bit-Version installiert (32 Bit läuft unter einem 64-Bit-Windows nicht) und dann eine Verschiebung der Windows-Partition veranlasst.
Das klappte auch wunderbar und wie erwartet. Nach der Partitionsgrößenänderung samt Verschieben lagen keine unpartitionierten Bereiche mehr vor.
Dirty-Bit der Disk gesetzt, USN-Journal read-only, Problembär gefangen
Als ich die Paragon Diskmanager Suite 2014 die Windows-Partition verschieben und vergrößern ließ, rappelte es gewaltig. Für den Vorgang bootet der Diskmanager in eine Linux-Umgebung und zeigt auch ein Protokoll diverser Prüfungen an.
Das Dirty-Bit des logischen Laufwerks war gesetzt und das USN Journal des Datenträgers stand auf Read-Only. Zudem lag es im Windows 7-Format vor. Die Festplattenmanager Suite 2014 bereinigte diese Fehler und bootete neu.
Dann habe ich unter Windows 8.1 die Partitionsstruktur im Festplattenmanager überprüft – da war alles in Ordnung. Im Anschluss habe ich unter Windows 8.1 den Neustart in den abgesicherten Modus eingeleitet (einfach die Umschalttaste gedrückt halten, wenn man im Menü zum Herunterfahren den Befehl Neustarten anwählen). In der Windows PE-Umgebung wurde der Vorgang zum Zurücklesen der Sicherung angestoßen. Ich konnte die Systemabbildsicherung auswählen und den Sicherungsvorgang laufen lassen.
Und man glaubt es kaum: Dieser Vorgang konnte erfolgreich und ohne Fehler abgeschlossen werden. Die beschädigte Partitionsstruktur mit dem Dirty-Bit des logischen Volumes hatte verhindert, dass Backup erfolgreich arbeiten konnte. Lange Rede, kurzer Sinn: Manchmal führen mehrere Wege nach Rom – und mit einer sauberen Analyse, wie oben beschrieben, wäre ich schneller zum Ziel gekommen. Der Blog-Beitrag ist nun etwas länger geworden. Ich dachte aber, schreib mal zusammen, wie Du prinzipiell vorgegangen bist, wie man eine Analyse betreibt und was für Möglichkeiten es sonst noch gibt. Vielleicht hilft es dem einen oder anderen Blog-Leser weiter oder gibt zumindest einige Anregungen.
Artikelreihe:
i: Troubleshoothing Windows-Backup-Fehler 0x80070057 – Teil 1
ii: Troubleshoothing Windows-Backup-Fehler 0x80070057 – Teil 2
Ähnliche Artikel:
a1: Windows-Backup Fehlerdiagnosen
a2: Windows-Fehler 0×80070057 beim Defragmentieren
a3: Windows 8.1 Update: Probleme und Troubleshooting
a4: Microsoft rollt Fix für Windows-Update-Corruption-Fehler aus
a5: Windows-Backup: Fehler 0×80040154
a6: Windows 8/8.1: Backup-Fehler 0x807800C5
a7: Windows: Backup-Fehler 0×80042412 beim Zurücklesen
a8: Windows 8-Backup: Mit Bordmitteln – Teil 1
a9: Backup-Lösungen für Windows 8
a10: SystemProfile: Backup-Fehler 0×80070002
a11: Windows 7 Backup-Error 0×81000019
a12: Windows-Backup: Befehlszeilenoptionen
a13: Meldung "Die Wiederherstellung wurde abgeschlossen" kommt immer Teil 1
b1: Disk-Doktor – Teil I
b2: USB-Stick wird als RAW angezeigt – Disk-Doktor II
b3: CD-/DVD-Laufwerke/-Medien testen – Disk-Doktor III
Anzeige
Für jemanden, der Fremdzeux immer wieder als Problem erkennt, kommt «Ich hatte von Paragon-Software bei einem Test den Paragon Diskmanager 2014 Free eingesetzt, um die Windows 8.1-Partition etwas am Anfang zu verkleinern.» natürlich etwas spät.
An anderer Stelle schrieb ich schon mal sinngemäß, dass man ein gründlich verpfuschtes System nicht sichert sondern wiederherstellt. Ich meine, Du hast eine Sicherung gemacht, als Dein System kaputt war und hättest erst mal einen Restore zu einem wirklich sauberen System gebraucht.
Dein über zwei Folgen ausgebreitetes Stochern ist aus meiner Sicht nicht wirklich hilfreich.
@Frank: Zum ersten Satz d'accord. Nur: Das war ein Testsystem – kein Produktivsystem (da wäre die Paragon Festplattenmanager 2014 Suite zum Einsatz gekommen). Von daher kann man meine Ausführen so oder so sehen – von meiner Planung war, da bestimmte Sachen testen und dann das System platt machen. Ist aus Gründen, die ich nicht mehr so genau auf die Reihe bekomme, nie passiert. Aber: Das ist die tägliche Praxis da draußen!
Zum letzten Satz: Da habe ich eine differenzierte und abweichende Meinung zu. Klar, ich hätte das Thema mit 3 Sätzen abfrühstücken können. "Backup neigt zu Fehlern. Nimm kein Fremdzeugs. Und wenn Backup failt, setze auf Recovery zurück." Aber ich habe die Gunst der Stunde genutzt, in Teil 1 einmal die möglichen "Abhilfen", die man in diesem weiten Netz finden kann, zu thematisieren und auch meine Einschätzung einzufügen, wo was helfen könnte. Und in Teil 2 geht es darum, ob und wie man durch Log-Analyse mehr herausfinden kann. Dass ich da noch aus dem Hinterkopf was zur vermutlichen Ursache zusteuern konnte, ist jetzt Zufall – hat aber mit dem Kern der Sache nix zu tun.
Ich lasse dir deine Sicht – ob es anderen Leuten hilft, müssen die beurteilen. Aber eine gewisse Freiheit als Blogger nehme ich mir schon heraus ;-). Nix für ungut.
Respekt, klasse dem Problem auf den Zahn gefühlt, so muss man das machen!
Ich hasse es, ständig Probleme nur zu verschieben und den Dingen nie auf den Grund zu gehen. Ist aber wohl leider ein Zeichen unserer Wegwerfgesellschaft.
Leider muss man sagen, dass selbst Microsoft kein Interesse mehr hat Fehler auf den Grund zu gehen, bzw. sind denen wahrscheinlich einfach die Leute mit dem entsprechenden Hintergrundwissen ausgegangen. Durch die neuen Desired State Configuration Möglichkeiten befürchte ich, wird dies alles noch schlimmer, weil dann in Zukunft noch schneller nicht funktionierende Konstellation abgeschossen werden und neu aufgesetzt, ohne dem eigentlichen Problem auf den Grund zu gehen. Die Maschine muss laufen, egal wie!
Was zudem nervt ist, die oft fehlende bzw. klare Dokumentation, man verbringt Stunden oder Tage mit dem Recherchieren und googeln um irgendwelche Dinge nachvollziehen zu können. Dabei dachte ich immer, Computer sollen einen produktiver machen, ha ha.
Also ich find diesen Artikel, wie viele andere hier, die sich aus dem Einheitsbrei der Internetsuppe durch tiefergehende Hintergrundinformationen, deutlich abheben einfach super! Nur durch diese Hintergrundinformationen können andere lernen mit solchen oder ähnlichen Problemen umzugehen. Danke dafür.
Hallo Günter,
das hast Du aber sauber herausbaldowert mit dem Dirty Bit des logischen Laufwerks und dem USN-Journal read-only.
Ich nehme mal an, dann kann ich mir weiteres erfolgloses Herumstochern in den Sprach und Regionseinstellungen sparen, den Registry Fix-It habe ich auch schon hinter mir und das Repository werde ich mir keinesfalls zerhacken, da könnte ich ja ebenso gut gleich das WINSXS-Verzeichnis löschen.
Was mich beschäftigt, wie komme ich dann aber nun an das Dirty Bit ran, wenn ich keinen Paragon Festplattenmanager habe ? Ich werde gleich mal meinen frisch erstellten bootable Linux USB-Stick mit GPart zum Einsatz bringen, auch als Parted Magic von mir gestern erwähnt, da aber noch von DVD und dann werde ich mal sehen, ob ich da was zum Korrigieren finde oder beim Linux-Boot einen Verweis auf das Dirty Bit sehe analog zu Deinem Screenshot.
Jedenfalls habe ich heute mal eine SSD bestellt und würde mir ungern den Fehler mit auf die neue Platte klonen, zum Stricken ist mir was Mechanisches lieber. Ich fahre übrigens Windows7 32 Bit mit schlappen 4 GB RAM und habe zwei primäre Partitionen auf meiner Platte, alles ganz übersichtlich. Vielleicht ist meine Startpartition ja tatsächlich dirty, nachdem ich auf der internen Platte gewerkelt habe, um sie clonegefügig für so eine alte 80 GB-HDD zu bekommen.
Vielen Dank für Deinen Blog. Die Lektüre war wie immer ein Vergnügen und deswegen auch auf keinen Fall zu lang.
Viele Grüße
Konstantin
ok, so geht´s:
In der Konsole (Start -> Ausführen -> cmd.exe (bei Vista + Win7: Rechtsklick, Als Administrator ausführen)) muss der Befehl fsutil dirty query x: (wobei x: durch das entsprechende Laufwerk ersetzt werden muss) gestartet werden. Bei der Ausgabe "Volume x: ist nicht fehlerhaft" wurde das Dirty-Bit erfolgreich entfernt.
Ansonsten ist folgendes Prozedere zu befolgen:
CHKDSK ausführen: In der mit Administratorrechten belassenen Konsole wird der Befehl chkdsk /F /R x: gestartet. Gegebenenfalls muss dazu das System neugestartet werden, da das Laufwerk ausgeklinkt wird und dies eine Systempartition verhindern kann.
Prüfung abschalten: Sollten die vorherigen Tipps noch nicht zum Ziel geführt haben, so kann man die Prüfung auf Dirty-Bits wie folgt abschalten: In der Konsole, die weiterhin Adminrechte besitzt wird chkntfs /X x: gestartet.
Das Dirty Bit ist bei mir nicht gesetzt, einen Systemreparaturdatenträger kann ich trotzdem nicht erstellen. Viel schlauer bin ich jetzt zwar nicht, aber viel gelernt habe ich trotzdem.