Die Wiederherstellung soll ja bei Problemen das Zurücksetzen von Windows auf einen Wiederherstellungspunkt ermöglichen. Gelegentlich streikt die Systemwiederherstellung oder die Windows-Sicherung (Backup) und gibt einen Fehler 0x81000101 aus. Nachdem ich diesen Fehler jetzt auf einen System erhielt, habe ich etwas gewühlt. Nachfolgend findet sich eine Diagnose- und Reparaturanleitung für diesen Notfall.
Anzeige
Fehlerbild, auf die Schnelle
Der Fehler tritt gar nicht mal so selten auf, wie man an der Linkliste [1 bis 8] sehen kann. Doof ist auch, dass der Fehler sowohl bei der Windows-Sicherung (Backup) als auch beim Anlegen von Wiederherstellungspunkten auftreten kann. Als ich vor ein paar Tagen unter [1] auf den Fehler traf, konnte ich nur ein paar allgemeine Lösungsvorschläge aus der Lameng machen.
Aber dann hat es mich auch getroffen – nach einer missglückten Connectify-Installation – da hing es bei der VC 2008-Installation, wollte ich das System über die Systemwiederherstellung in einen sauberen Zustand zurücksetzen. Pustekuchen, keine Wiederherstellungspunkte mehr da.
Also versucht, über die Eigenschaften des Systems den Computerschutz aufzurufen und einen Wiederherstellungspunkt zu erstellen. Nachdem ich die in obiger Abbildung sichtbare Schaltfläche Erstellen angeklickt hatte, erschien zwar die Fortschrittsanzeige. Aber es tat sich lange nichts.
Und irgendwann kam dann das nachfolgende Dialogfeld mit der Fehlermeldung "Bei der Erstellung einer Schattenkopie ist eine Zeitüberschreitung aufgetreten. Wiederholen Sie diesen Vorgang. (0x81000101)".
Bingo, das war der Zeitpunkt, wo ich geflucht habe, weil ich ein Problem hatte. Andererseits war es auch eine wunderbare Gelegenheit, ein paar Diagnose- und Reparaturansätze zu testen.
Triviale Ansätze zur Reparatur
An diesem Punkt ist es wichtig, mittels einer Systemdateiprüfung ein beschädigtes System auszuschließen. Wie so etwas überprüft wird, haben ich in [a] beschrieben. Auf meinem System lieferte diese Prüfung jedoch ein unbeschädigtes System.
Anzeige
In einem weiteren Schritt habe ich dann den Ansatz verfolgt, die Systemwiederherstellung für das betreffende Laufwerk auszuschalten und Systemwiederherstellungspunkte zu löschen. Wichtig ist dabei, das betroffene Laufwerk vorher auszuwählen. Wie man die Wiederherstellung deaktiviert, habe ich unter [c] erläutert und unter [b] gibt es auch noch Hinweise. Bei einigen Leuten hat das geholfen, weil der Volumenschattenkopiendienst wegen fehlerhafter Wiederherstellungspunkte streikte. Ich hatte jedoch kein Glück.
Den unter [12] adressierten Ansatz, den Timeout für den VSS-Writer zu erhöhen, habe ich mir geschenkt. Es dauerte eh recht lange, bis der Timeout-Fehler gemeldet wurde.
Dienste überprüfen
Als weitere Maßnahme habe ich Dienste im Suchfeld des Startmenüs eingetippt und dann im Dienste-Manager kontrolliert, ob der Dienst Volumenschattenkopie startbar ist und ob die Abhängigkeiten erfüllt sind. Standardmäßig steht der Dienst auf "Manuell" und wird bei Bedarf aufgerufen. Hier war alles in Ordnung.
Dann habe ich noch den Dienst Windows-Sicherung geprüft. Dieser war jedoch gestartet und auch dort konnten keine Auffälligkeiten festgestellt werden.
Diagnose mit VSSAdmin
Nach diesen erfolglosen Schritten habe ich dann cmd im Suchfeld des Startmenüs eingegeben und dann die Tastenkombination Shift+Alt+Eingabe gedrückt. Nach Bestätigung der Benutzerkontensteuerung öffnet sich die mit administrativen Berechtigungen laufende Eingabeaufforderung. In dieser lässt sich über den Befehl VSSAdmin der Volumenschattenkopien-Dienst ansprechen.
Mit VSSAdmin erhält man eine Hilfeseite angezeigt. Der Befehl:
VSSAdmin List Providers
lieferte mir auch einen Hinweis auf den Provider. Aber der Befehl:
VSSAdmin List Writers
sollte eigentlich die VSS-Writer anzeigen. Bei mir tat sich aber nichts und nach einer langen Wartezeit kam wieder der obige Fehlerdialog. Irgend ein VSS-Writer machte also Probleme – fehlender VSS-Speicher oder kaputte Wiederherstellungspunkte konnte ich nach den obigen Diagnoseschritten ausschließen. Also war ich so weit wie vorher.
Ereignisanzeige prüfen – Quelle: VSS ID 8193
An diesem Punkt blieb nur noch, einen Blick in die Ereignisanzeige zu werfen. Viel Hoffnung hatte ich zwar nicht, da ich dort maximal einen Eintrag mit obigem Fehlercode erwartete. Nachdem ich im Suchfeld des Startmenüs Ereignis eingetippt und die Ereignisanzeige über Als Administrator ausführen (zum ggf. erforderlichen Löschen der Ereignisse) aufgerufen hatte, ging es an die Analyse.
Im Zweig Windows Protokolle –> Anwendung wurde ich schnell fündig, wie die obige Abbildung zeigt. Die Quelle VSS hatte das Ereignis mit der ID 8193 mehrfach eingetragen. Ein Doppelklick auf den Fehlereintrag zeigte die nachfolgenden Details.
Der Text "Volumenschattenkopie-Dienstfehler: Beim Aufrufen von Routine "ConvertStringSidToSid(S-1-5-21…-101.bak)" ist ein unerwarteter Fehler aufgetreten. hr = 0x80070539, Die Struktur der Sicherheitskennung ist unzulässig." brachte mich ein Stück weiter.
Reparaturansätze gefällig?
Nachdem Fehlerdetails vorlagen, habe ich nach VSS ID 8193 gesucht und wurde fündig. Der Blog-Beitrag unter [10] befasst sich zwar mit einem ganz anderen Problem, nämlich der Überführung eines physischen Systems in eine VHD. Aber der Volumenschattenkopien-Writer hat ein Problem beim Zugriff auf eine SID. Der Artikel führt aus, dass der Benutzer unter einem temporären Profil angemeldet wird und gibt folgenden Tipp:
- Den Registrierungs-Editor regedit über den Kontextmenübefehl Als Administrator ausführen öffnen.
- Dann zum folgenden Schlüssel navigieren:'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT
\CurrentVersion\ProfileList' - Im Schlüssel ProfileList sind dann alle Unterschlüssel zu löschen, die irgendwie mit SID.bak benannt sind.
Die Buchstabenkombination SID steht hier als Plactzhalter für die Sicherheits-ID (SID) des Benutzerkontos mit dem Problem. Der SID.bak-Unterschlüssel sollte einen ProfileImagePath-Eintrag aufweisen, der auf den Original-Profilordner des Benutzerkontos verweist, welches Probleme macht.
Der obige Ansatz lässt sich sicherlich in Betracht ziehen. Da ich aber keine temporäre Anmeldung auf meinem System feststellen konnte, habe ich diese Reparaturmöglichkeit nicht weiter betrachtet. Vielmehr kam mir der Gedanke, das ein VSS-Writer nicht mehr korrekt registriert sei. Und hier wurde ich unter [8] in einem Symantec-Dokument fündig. Auch dieser Beitrag geht eigentlich auf andere Probleme ein, enthält aber Hinweise, um die Volumen-Schattenkopien-Provider neu zu registrieren.
Ich habe dann den Ansatz in einer Art Tabula Rasa-Manier abgewandelt und die betreffenden Anweisungen aus dem Dokument per Windows-Editor in eine .bat-Datei übertragen. Hier ist der Inhalt meiner VSS-Repair.bat.
REM Repariere VSS-Dienst
Net stop vss
Net stop swprv
: Auf System
cd C:\windows\system32
: neu registrieren
regsvr32 ole32.dll
regsvr32 vss_ps.dll
vssvc /Register
regsvr32 /i swprv.dll
regsvr32 /i eventcls.dll
regsvr32 es.dll
regsvr32 stdprov.dll
regsvr32 vssui.dll
regsvr32 msxml.dll
regsvr32 msxml3.dll
regsvr32 msxml4.dll
: Launch dienste
Net Start vss
Net Start swprv
Ich habe absichtlich nicht mit @Echo off gearbeitet, um bei der Ausführung die Befehle sehen zu können. Die Batch-Datei beendet Dienste, versucht diverse Dlls neu zu registrieren und startet denn wieder die Dienste.
Hierzu ist die Datei VSS-Repair.bat mit der rechten Maustaste anzuklicken und über den Kontextmenübefehl Als Administrator ausführen zu starten. Die regsvr-Anweisungen bewirken die Registrierung der angegebenen Komponente. Dies wird im Erfolgsfall mit einem Dialogfeld abgeschlossen. Sie müssen dieses über die OK-Schaltfläche schließen.
Die Batch-Datei enthält aber ein paar Anweisungen, die unter Windows 7 nicht ausführbar sind (z. B. msxml4.dll registrieren). Diese lösen einen Fehlerdialog aus, den der Anwender schließen muss. Das ist aber kein wirkliches Problem, weil dabei nichts kaputt gehen kann. Bei Bedarf kann man ja die nicht funktionierenden Befehle in obiger Batch-Datei durch voranstellen eines Doppelpunkts : auskommentieren.
Heureka – Et löppt wieeeda …
Nach Ausführung der VSS-Repair.bat konnte ich in einer administrativen Eingabeaufforderung wieder den Befehl:
VSSAdmin List Writers
ausführen. Und im Nachgang ließen sich erneut Wiederherstellungspunkte anlegen. Problem also gelöst! Muss nicht in jedem Fall so ausgehen. Trotzdem hoffe ich, mit den Ausführungen in diesem Beitrag ein paar Anregungen gegeben zu haben, um VSS-Probleme zu lösen.
Die Ursache für den Fehler ist mir nicht ganz klar – das betreffende Netbook wurde für Softwaretests benutzt. Neben der bereits erwähnten, verunglückten Softwareinstallation gab es das Problem, dass ein Grafikprogramm wohl beschädigt war und beim Aufruf hängen blieb. Dies führte dazu, dass das Netbook nicht immer sauber heruntergefahren wurde und vom Stromnetz getrennt werden musste. Vielleicht ist dabei irgendwann etwas in der Registrierung kaputt gegangen …
Blog-Beiträge:
a: System auf beschädigte Systemdateien prüfen
b: Systemwiederherstellungspunkte verschwinden …
c: Die Systemwiederherstellung funktioniert nicht
Links:
1: Fehlerdiskussion bei MS Answers
2: Fehlerdiskussion bei MS Answers
3: Fehlerdiskussion bei MS Answers
4: Fehlerdiskussion bei MS Answers (Englisch)
5: Forendiskussion bei Dr. Windows
6: Diskussion bei CNet (Englisch)
7: Diskussion bei sevenforums.com (Englisch)
8: Diskussion bei Symantec (Englisch) Lösung
9: Diskussion bei Technet (Englisch)
10: Blog-Eintrag mit einer Lösung (Englisch)
11: Weitere Forendiskussion
12: Timeout für VSS-Snapshot erhöhen (Englisch)
2015
Hi,
hatte genau die gleiche Fehlermeldung . Bin hier im Forum auf den ein oder andern Hinweis gestossen, welche aber nicht zu einer Behebung des Problems geführt haben. Deshalb hier für Suchende ein Weg der auf meinem System Win 7 S1 & MS Security Essentials (MSSE) geholfen hat.
Beim nachgehen der Hinweise und wiederholtem Start der Sicherung viel mir zwischen duch ein Popupfenster von Selcurity-Essentials auf. Sinngemäß: Problem erkannt, beseitigt, machen sie sich keine Sorgen). Der Scanner hat zwei Dateien unter QUARANTÄNE gestellt Exploit: Java/CVE2012.0507.AGX und Java/CVE2012.0507.ATK Nach einem vollständigen SCAN, habe ich diese entfernen lassen und jetzt funktioniert die Systemsicherung wieder einwandfrei.
PS: Diese beiden Dateien erscheinen immer dann, wenn ich von der Orignal Oracle u/o Chip Download die Java-Software neu oder ein Update installiere. Im "laufenden Betrieb" kommen die nicht vor, auch nicht beim Scan des Systems. Als Andwender (nicht Administrator) frage ich mich natürlich: "Ist das normal?". Bei Oracle habe ich jetzt einen Hinweis gefunden, dass diese Zugriffsgefahr nur bei Versionen Java 7.2 oder früher zutrifft und auch nur in eingeschränkten Umfang (Sandbox mit limitierten Privilegien so freie Übersetzung) Ich habe aber 7.9
PPS: die Links
http://www.java.com/de/download/
Die VSS-Reparatur hilft auch beim Update Fehler 80244FFF (siehe).
Pingback: Anonymous
Pingback: Systemwiederherstellung
Hallo Günter,
vielen Dank für diesen baumstarken Blog-Beitrag aus 2012, der mir nun (vier Jahre später) aus einer misslichen Lage geholfen hat, als ich nach langem Suchen Infos zum Fehlercode '0x81000101' ergooglete.
Ausgangspunkt war Anfang 2016 die Anschaffung eines neuen Medion AKOYA P5118D Midi-PCs mit vorinstalliertem Windows 7 Professional SP1 (64bit).
Nach erfolgreicher Aktivierung und Aktualisierung des Betriebssystems mittels Installation von 66 wichtigen und 16 (von insg. 21) empfohlenen Windows Updates ging ich dazu über, die Software für einen via LAN verbundenen Canon PIXMA MX850 Multifunktionsdrucker aufzuspielen. Die Originalsoftware vom Drucker wollte ich per Stick über einen der frontseitigen USB-3.0-Ports auf den AKOYA kopieren. Zu meiner Verwunderung wurde aber abgesehen von Laufwerk G: (für den Multi-Card-Reader) kein Wechseldatenträger im Explorer angezeigt. Stattdessen ging die Systemperformanz merklich in den Keller. Ein Auswerfen des Sticks über das 'Hardware sicher entfernen'-Symbol war nicht möglich. Die von mir initiierte Abmeldung vom System musste ich nach ca. 20 min Wartezeit durch hartes Ausschalten abbrechen, nachdem auch die Festplatte hörbar ihren Betrieb eingestellt hatte.
Der nächste Kopiervorgang im Abgesicherten Modus gelang via nun sichtbarem Laufwerk H:, doch der erste Installationsversuch per Canon-Setup war nur ein Teilerfolg, weil die original 'MP Drivers for Network' als inkompatibel zu Windows 7 gemeldet wurden. Bei den darauffolgenden Mühen mit der widerspenstigen Über-/De- und Re-Installation des beim Hersteller heruntergeladenen, aktuellen 'MX850 series Mini Master Setups' durchlief mein Rechner mehrere Neustarts und Systemhänger beim Herunterfahren (Bug Check 9f, 4, 258, …), eine Systemwiederherstellung auf den letzten von drei systemseitig angelegten Wiederherstellungspunkten, die Wiederholung von noch 8 + 16 Windows Updates und zuletzt die Deinstallation der 30-Tage-Testversion von 'McAfee LiveSafe – Internet Security', welches sich partout nicht allumfassend inaktiv schalten lassen wollte und wohl besser gleich von der Platte geputzt hätte werden sollen. Als die Druckersoftware endlich ordnungsgemäß aufgespielt war, legte ich vorsichtshalber einen zusätzlichen Wiederherstellungspunkt an und setzte mit der Installation von Office 2016 fort. Es folgten allerdings weitere scheinbar unmotivierte Systemhänger beim Herunterfahren mit und ohne abschließenden BlueScreen (DRIVER_POWER_STATE_FAILURE).
Ein Tage später ausgeführtes Cleanup mit der bei McAfee heruntergeladenen MCPR.exe änderte daran auch nichts. Die Analyse der Memory-Dumps half nicht wirklich weiter (Crash-Auslöser fvevol.sys oder volmgr.sys? – eher unwahrscheinlich!). Laut Ereignisprotokoll bestanden schon seit Aufsetzen des Betriebssystems im März 2015 durch Medion Probleme mit einer fehlenden system32\Rtlihvs.dll und mit dem Laden von Driver\WUDFRd.sys, die ich jedoch beide ausräumen konnte. Nach längeren Recherchen zu anderen möglichen Treiberproblemen spielte ich mit dem Gedanken, zur weiteren Analyse den Driver Verifier zu aktivieren, der dann aber doch nicht mehr zum Einsatz kam.
Ein manuell gestartetes Windows Update hängte sich mitten in der Erstellung eines Wiederherstellungspunkts auf. Zu meiner Überraschung waren danach sämtliche (!) Wiederherstellungspunkte verschwunden. Ein neuer ließ sich weder manuell noch per Windows Update erstellen. Mit 'sfc /scannow' und 'chkdsk /F' waren allerdings keine Inkonsistenzen feststellbar. Im Anwendunsprotokoll entdeckte ich dann vereinzelte Einträge zum VSS, die mich schließlich zu Deinem Blog führten. Als ich schon fürchtete, dass der Rechner gar nicht mehr aus der Absturzschleife beim Herunterfahren würde ausbrechen können, rettete mir dieser Beitrag buchstäblich das Wochenende.
Nach mehrmaligem Ausführen des VSS-Repair-Scripts, der vssadmin-Kommandos und zwischenzeitlichem Abschießen des VSSVC-Prozesses konnte Windows endlich wieder einen Wiederherstellungspunkt erstellen. Der nächste Neustart blieb nicht mehr beim quälend langandauernden Abmelden resp. Herunterfahren hängen und war schon nach wenigen Sekunden erledigt. Der Bann war damit gebrochen und ich konnte der eigentlichen Ursache des USB-Problems zu Leibe rücken.
Der AKOYA P5118D wurde offenbar mit einem zumindest teilweise infunktionalen Treiber (iusb3hub.sys) mit Stand von März 2013 ausgeliefert. Zu dumm, dass davon die reibungslose Funktionalität von so unverzichtbaren Komponenten wie Tastatur, Maus, Wechseldatenträgern und übrigens auch dem vom Hersteller hinten aufgesteckten Wifi-Dongle abhängen. Prompt schlug auch hier die erste Installation des aktuellen Treiberpakets für den 'Intel USB 3.0 eXtensible Hostcontroller' aus Juni 2015 fehl, wonach ich mich – im Anschluss an den im Abgesicherten Modus ausgeführten Installationsversuch Zwei und obligatorischen Neustart – mit einem Windows-Anmeldeschirm ohne Möglichkeit einer Interaktion per Maus oder Tasteneingabe konfrontiert sah. Kein USB-Gerät schien noch zu funktionieren und PS/2-Anschlüsse gibt es am P5118D auch nicht. Jeder Neustart brachte mich direkt in den Fortsetzungsbildschirm vom Windows-Login zurück. Glücklicherweise hatte ich mir ganz zu Beginn der Inbetriebnahme des AKOYA die Recovery-DVD gebrannt, über die ich wieder in den Abgesicherten Modus verzweigen konnte. Nach Entfernung eines 'Unbekannten Geräts' aus dem Geräte-Manager und eine erneute Ausführung des Intel-Setups klappte zu guter Letzt die USB-Initialisierung auch im Standard-Modus und das System arbeitet nun endlich zuverlässig. VSS-Problem (hoffentlich) endgültig gelöst.
Hallo Herr Born,
vielen Dank für ausführlichen Hinweise, das Problem zu lösen. Ich habe die Bat-Datei durchlaufen lassen, doch leider bekam ich viele Fehlermeldungen. Gerne hätte ich diese mit kleinen Pics angehängt, denn u.U. folgt hier ein Fehler dem anderen. Was tun ?
Besten Dank vorab
René
Bitte um Verständnis, wenn ich hier keine Einzeldiagnose geben kann und auch nicht wild auf angehängte Screenshots bin. Die Fehlermeldungen könnte man ja auswerten und die Essenz als Kommentar posten.