Korrupter Windows Server nach Windows Update

Wenn ein Windows Update fehlschlägt oder der Server während des Updateprozesses unerwartet ausgeschaltet wird, sollte die Gesundheit der Systemdateien anschließend mit Hilfe des Tools sfc /scannow oder DISM überprüft werden. Doch was ist zu tun, wenn das System nicht automatisch repariert werden kann?

Das Systemdatei-Überprüfungsprogramm (SFC.exe)

Microsoft empfiehlt die Verwendung des System File Checker Tools, um geschützte Windows Ressourcen zu scannen und gegebenenfalls zu reparieren. In unserem Beispiel wurde nach einem fehlgeschlagenen Update das gesamte System gescannt. Dazu wird eine Eingabeaufforderung (cmd) als Administrator geöffnet und folgender Befehl ausgeführt:

sfc /scannow

Dies ist nach 44% der Überprüfung mit der Meldung Windows Resource Protection could not perform the requested operation fehlgeschlagen.

Wenn diese Operation fehlschlägt, kann als nächstes das Tool DISM für die Überprüfung genutzt werden.

Das Tool „Abbildverwaltung für die Bereitstellung“ (DISM)

Seit Windows 8 bzw. Windows Server 2012 kann ebenfalls das Tool DISM genutzt werden, um Windows auf Beschädigungen von Systemdateien zu überprüfen. Insbesondere bei Problemen mit Windows Updates und Upgrades ist diese Überprüfung sinnvoll, da ein Update unter Umständen nicht installiert werden kann, wenn Systemdateien beschädigt sind.

Da wir in unserem Beispiel von einer Beschädigung ausgehen, die mit Hilfe von sfc nicht behoben werden konnte, führen wir DISM mit den Parametern Online, Cleanup-Image und Restorehealth aus, um das aktuelle laufende Windows System (Parameter Online) zu überprüfen und reparieren (Parameter Cleanup-Image). Der gesamte Befehl wird in einer Eingabeaufforderung (cmd) als Administrator ausgeführt:

DISM /Online /Cleanup-Image /Restorehalth

In unserem Fall schlug die Überprüfung mit folgender Meldung fehl:

Error: 1726
The remote procedure call failed.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

Das erwähnte Logfile hat in unserem Fall keine weiteren Erkenntnisse geliefert. Der zugehörige RPC Dienst war auf der Maschine ebenfalls gestartet. Die Firewall und Antivirus konnten als Fehlerquelle ausgeschlossen werden.

Ein weiteres wichtiges Logfile, das von DISM erstellt wird, ist das CBS.log. Es befindet sich unter %windir%/Logs/CBS/CBS.log. Hier wurden unter anderem folgende Probleme in der Zusammenfassung gelistet:

[…]
(p)          CBS Catalog Missing                                       Package_6757_for_
KB4480961~31bf3856ad364e35~amd64~~10.0.1.3
(p)          CBS Catalog Missing                                       Package_6758_for_
KB4480961~31bf3856ad364e35~amd64~~10.0.1.3

Summary:
Operation: Detect only
Operation result: 0x0
Last Successful Step: CSI store detection completes.
Total Detected Corruption:          118
                CBS Manifest Corruption:             118
                CBS Metadata Corruption:           0
                CSI Manifest Corruption:               0
                CSI Metadata Corruption:            0
                CSI Payload Corruption: 0
[…]

Es ist zu erkennen, dass insgesamt 118 CBS Manifest Corruptions gefunden wurden. Diese beziehen sich alle auf das Update KB4480961 (das Log wurde zur besseren Lesbarkeit abgeschnitten). Dieses Update wurde bereits einige Monate zuvor installiert. Wie kann man die fehlenden Dateien nun zum Windows Image hinzufügen?

Windows Update mit DISM einspielen

Da wir das problematische Windows Update erfolgreich identifizieren konnten, können wir es im nächsten Schritt vom Microsoft Update Catalogue herunterladen und installieren.

Das Update wird mit dem Namen windows10.0-kb4480961.msu im Ordner C:\temp gespeichert. Damit das Update hinzugefügt werden kann, muss es zunächst entpackt werden.

Expand -F:* windows10.0-kb4480961.msu C:\temp\4480961

Nach dem Entpacken kann die zugehörige cab-Datei mit DISM zu unserem Image hinzugefügt werden:

DISM /online /Add-Package /PackagePath:c:\temp\4480961\Windows10.0-kb4480961-x64.cab

Wenn diese Operation erfolgreich durchgeführt wurde, können wir den Status des Systems erneut überprüfen:

DISM /Online /Cleanup-Image /Scanhealth

Erfreulicherweise erhalten wir nun die Meldung, dass keine component store corruptions mehr erkannt wurden. Wir können also erneut die Überprüfung mit sfc starten:

sfc /scannow

Leider erhalten wir hierbei erneut dieselbe Fehlermeldung wie am Anfang. Ein anschließendes Reparieren mit Hilfe von DISM schlägt ebenfalls fehl:

DISM /Online /Cleanup-Image /Restorehealth

Wie können wir nun die letzten Beschädigungen des Systems ausfindig machen und beheben?

Die Ausgabe der in diesem Abschnitt beschriebenen Befehle sind in Abbildung 1 zu sehen.

Abbildung 1: Ausgabe der Befehle

Abbildung 1: Ausgabe der Befehle

Manuelles Ersetzen einer beschädigten Systemdatei

Da in unserem Fall die automatische Reparatur mit sfc nicht erfolgreich ist, müssen wir uns die beschädigten Dateien zunächst ausgeben lassen, bevor wir diese manuell ersetzen können:

sfc /verifyonly

Die hier aufgeführten Dateien unterscheiden sich je nach Problem, weshalb ich hier den Platzhalter Pfad_und_Dateiname verwende. Dieser muss entsprechend angepasst werden. Die Dateien müssen zum Schluss von einem funktionsfähigen System importiert werden. Damit dieser Vorgang erfolgreich durchgeführt werden kann, muss zunächst die Ownership geändert werden:

takeown /f Pfad_und_Dateiname

Anschließend geben wir den Administratoren Vollzugriff auf die Dateien:

icacls Pfad_und_Dateiname /GRANT ADMINISTRATORS:F

Im letzten Schritt können die beschädigten Dateien ausgetauscht werden.

Nach Austausch der Dateien ist unser System wieder in einem gesunden Status, was wir mit sfc überprüfen können.

Abbildung 2: Erfolgreiches sfc /scannow

Abbildung 2: Erfolgreiches sfc /scannow