SFC CBS.log auswerten: Windows Fehler beheben

Der Befehl sfc /scannow meldet beschädigte Windows Systemdateien, zeigt im Windows Terminal aber nur ein kurzes Ergebnis. Die wichtigen Details stehen in der CBS.log. In dieser Anleitung erklären wir genau, wie Du die SFC CBS.log auswerten kannst, wie Du die wichtigen Einträge herausfilterst und woran Du erkennst, ob Windows eine Datei repariert hat oder ob ggf. weitere Maßnahmen nötig sind.

SFC CBS.log auswerten: Das Wichtigste in Kürze

Die Datei C:\Windows\Logs\CBS\CBS.log ist ein gemeinsames Wartungsprotokoll von Windows. SFC kennzeichnet seine eigenen Protokollzeilen mit [SR]. Deshalb solltest Du nicht die komplette CBS.log Zeile für Zeile lesen, sondern zuerst nur diese Einträge in eine separate Textdatei exportieren.

findstr /c:"[SR]" "%windir%\Logs\CBS\CBS.log" > "%userprofile%\Desktop\SFC-Details.txt"

Die erzeugte Datei enthält alle noch in der aktuellen CBS.log vorhandenen SFC Einträge. Dazu können auch ältere Prüfläufe gehören. Prüfe deshalb immer Datum und Uhrzeit. Eine Meldung wie Cannot repair member file weist auf eine Datei hin, die SFC in diesem Lauf nicht reparieren konnte. Eine Zeile wie Repaired file dokumentiert dagegen eine ausgeführte Reparatur. Verlässlich bestätigt wird der Erfolg durch die Abschlussmeldung von SFC und einen anschließenden Kontrolllauf ohne Integritätsverletzungen.

Was ist die CBS.log in Windows?

CBS steht für Component Based Servicing. Dahinter steckt die komponentenbasierte Wartung von Windows. Sie verwaltet unter anderem Systemkomponenten, optionale Windows Features, Updates und Reparaturvorgänge. Das zugehörige Protokoll liegt standardmäßig in folgendem Ordner:

C:\Windows\Logs\CBS\CBS.log

Die CBS.log ist keine reine SFC Logdatei. Auch andere Wartungsvorgänge schreiben dort Einträge hinein. Dazu gehören Aktivitäten des Windows Modules Installer, Installationen von Komponenten und Teile der Windows Update Verarbeitung. Dadurch kann die Datei sehr groß und unübersichtlich wirken.

Der System File Checker prüft geschützte Windows Systemdateien anhand der erwarteten Komponentenversionen. Erkennt SFC eine fehlende oder veränderte Datei, versucht Windows eine intakte Kopie aus dem Komponentenspeicher bereitzustellen. Eine ausführliche Einführung findest Du in unserem Beitrag zu SFC /scannow und der Windows Systemdateiprüfung. Ergänzende technische Hinweise findest Du in der ausführlichen Beschreibung der Systemdateiprüfung.

Welche Bedeutung hat das Kennzeichen [SR]?

Jede von SFC erzeugte Zeile in der CBS.log trägt das Kennzeichen [SR]. Genau dieses Merkmal macht die Auswertung beherrschbar. Andere CBS Einträge ohne [SR] können für Windows Updates oder den Komponentenspeicher wichtig sein, gehören aber nicht unmittelbar zum SFC Prüfergebnis.

Vor dem Kennzeichen stehen meistens Datum, Uhrzeit, Protokollstufe, die Komponente CSI und eine laufende Kennung. Danach folgt die eigentliche SFC Meldung. Ein typischer, gekürzter Aufbau sieht so aus:

2026-08-18 19:31:22, Info CSI 00000123 [SR] Cannot repair member file ...

Auch ein problematischer Eintrag kann mit Info beginnen. Die Protokollstufe allein entscheidet daher nicht, ob ein Fehler vorliegt. Wichtiger ist der Text hinter [SR].

Wann solltest Du die SFC CBS.log auswerten?

Eine Auswertung ist besonders sinnvoll, wenn sfc /scannow beschädigte Dateien meldet oder einige Dateien nicht reparieren kann. Auch nach einer erfolgreichen Reparatur kann die CBS.log zeigen, welche Windows Komponenten betroffen waren.

• SFC hat beschädigte Dateien gefunden und nur teilweise repariert.
• Die gleiche SFC Meldung erscheint nach jedem Neustart erneut.
• Windows Update, Systemfunktionen oder integrierte Apps arbeiten weiterhin fehlerhaft.
• Du möchtest prüfen, welche Datei SFC ersetzt oder beanstandet hat.
• Der Windows Ressourcenschutz konnte den angeforderten Vorgang nicht ausführen.

Die CBS.log liefert jedoch nicht automatisch die vollständige Ursache eines Problems. Sie zeigt zunächst, welche geschützte Datei oder welche Komponente bei der Prüfung auffällig war. Ob dahinter ein beschädigter Komponentenspeicher, ein unterbrochenes Update, ein Dateisystemfehler oder eine andere Ursache steckt, ergibt sich erst aus dem Zusammenhang.

Vorbereitung für eine saubere CBS.log Auswertung

Administratorrechte verwenden

SFC, DISM und der Zugriff auf die Windows Protokollordner benötigen erhöhte Rechte. Starte deshalb die Eingabeaufforderung oder das Windows Terminal als Administrator. Die passenden Wege zeigen wir in den Anleitungen CMD als Administrator ausführen und Windows Terminal als Administrator starten.

Offene Updates abschließen und Windows neu starten

Ein ausstehender Neustart kann die Bewertung erschweren, weil Dateien noch für ein Update vorgemerkt sind. Schließe bereits begonnene Updateinstallationen ab, starte Windows neu und beginne danach mit der kontrollierten Prüfung. Falls Updates wiederholt scheitern, hilft die Anleitung zum Reparieren von Windows Update.

Zeitpunkt des SFC Laufs notieren

Notiere Dir vor dem Start die aktuelle Uhrzeit. Das ist wichtig, weil eine exportierte SFC Details Datei auch Einträge früherer Prüfungen enthalten kann. Bei mehreren Läufen am selben Tag reicht das Datum allein nicht aus.

Vor manuellen Eingriffen eine Sicherung anlegen

Das reine Lesen und Filtern der CBS.log verändert Windows nicht. Vor einer Reparaturinstallation, dem Austausch geschützter Dateien oder Änderungen an Berechtigungen solltest Du jedoch Deine Daten sichern. Zusätzlich kann ein Wiederherstellungspunkt hilfreich sein. Wie Du ihn nutzt, zeigt die Anleitung zur Windows Systemwiederherstellung.

Schritt für Schritt die SFC CBS.log auswerten

Schritt 1: Windows Terminal als Administrator öffnen

1. Klicke mit der rechten Maustaste auf das Windows Startsymbol.
2. Wähle Terminal (Administrator) aus.
3. Bestätige die Abfrage der Benutzerkontensteuerung.
4. Öffne bei Bedarf über den Pfeil in der Titelleiste ein Profil für die Eingabeaufforderung.

Die folgenden CMD Befehle funktionieren in einem Eingabeaufforderungsprofil. In PowerShell kann die Umleitung ebenfalls funktionieren, die PowerShell Variante weiter unten ist jedoch eindeutiger.

Schritt 2: Den Komponentenspeicher mit DISM reparieren

Für einen neuen, kontrollierten Prüflauf solltest Du zuerst den Windows Komponentenspeicher reparieren. SFC benötigt diesen Speicher als Quelle für intakte Systemdateien. Führe folgenden Befehl aus:

DISM.exe /Online /Cleanup-Image /RestoreHealth

Schließe das Fenster nicht, auch wenn die Fortschrittsanzeige längere Zeit bei einem Wert stehen bleibt. Warte auf die Abschlussmeldung. Mehr zu den Funktionen und Parametern findest Du in unserer Anleitung zum DISM Tool unter Windows.

Hast Du bereits einen fehlgeschlagenen SFC Lauf durchgeführt und möchtest genau dessen Ergebnis untersuchen, exportiere die SFC Einträge zuerst. Ein weiterer Wartungslauf fügt neue Zeilen hinzu und kann die zeitliche Zuordnung erschweren.

Schritt 3: SFC vollständig durchlaufen lassen

Starte anschließend die Systemdateiprüfung:

sfc /scannow

Diese Vorgang sieht dann in einer Eingabeaufforderung mit Administrator Rechten wie folgt aus:

Warte bitte, bis die Überprüfung 100 Prozent erreicht hat. Schließe das Terminal währenddessen nicht. Notiere die genaue Abschlussmeldung, denn sie ist für die Bewertung genauso wichtig wie einzelne Zeilen in der CBS.log.

Schritt 4: Nur die SFC Einträge aus der CBS.log exportieren

Führe direkt nach dem SFC Lauf diesen Befehl aus:

findstr /c:"[SR]" "%windir%\Logs\CBS\CBS.log" > "%userprofile%\Desktop\SFC-Details.txt"

Der Befehl sucht nach dem wörtlichen Kennzeichen [SR] und schreibt alle passenden Zeilen in die Datei SFC-Details.txt auf Deinem Desktop. Die originale CBS.log bleibt unverändert. Im Terminal erscheint bei erfolgreicher Ausführung normalerweise keine zusätzliche Meldung.

Liegt Dein Desktop durch eine Ordnerumleitung an einem anderen Speicherort oder meldet der Befehl, dass der Pfad nicht gefunden wurde, kannst Du stattdessen einen neutralen Ordner verwenden:

mkdir C:\Temp 2>nul
findstr /c:"[SR]" "%windir%\Logs\CBS\CBS.log" > "C:\Temp\SFC-Details.txt"

Schritt 5: SFC Einträge mit PowerShell exportieren

Alternativ kannst Du die relevanten Zeilen mit PowerShell auslesen. Diese Variante ermittelt den tatsächlichen Desktop Ordner und schreibt nur den Inhalt der gefundenen Zeilen in die Textdatei:

$Ziel = Join-Path ([Environment]::GetFolderPath('Desktop')) 'SFC-Details.txt'
Select-String -Path "$env:windir\Logs\CBS\CBS.log" -SimpleMatch '[SR]' |
    ForEach-Object { $_.Line } |
    Set-Content -Path $Ziel -Encoding utf8

Öffne die erzeugte Datei anschließend mit dem Editor. Nutze die Suchfunktion mit Strg + F, um gezielt nach auffälligen Begriffen zu suchen.

Schritt 6: Den letzten SFC Lauf zeitlich eingrenzen

Beginne nicht automatisch am Anfang der Datei. Suche nach dem Datum und der Uhrzeit Deines letzten Prüflaufs. Berücksichtige nur Einträge, die während dieses Zeitfensters entstanden sind. Das ist einer der wichtigsten Schritte bei der SFC CBS.log Auswertung.

Ein Export kann beispielsweise Fehler von morgens und einen erfolgreichen Kontrolllauf am Nachmittag enthalten. Ohne den Zeitvergleich würdest Du alte Probleme fälschlich als aktuell bewerten. Sortiere die Datei nicht neu, denn die chronologische Reihenfolge hilft bei der Zuordnung.

Schritt 7: Nach den entscheidenden Meldungen suchen

Suche nacheinander nach diesen Texten:

• Cannot repair member file
• Repairing corrupted file
• Repaired file
• file is missing
• hashes for file member do not match

Beurteile nie nur eine einzelne Trefferzeile. Lies auch die unmittelbar davor und danach stehenden SFC Einträge. Dort können die betroffene Komponente, die Version, die Architektur und der weitere Reparaturverlauf stehen.

Wichtige CBS.log Meldungen in der Übersicht

SFC Eintrag	Bedeutung	Sinnvolle Reaktion
Verifying 100 ... components	SFC prüft einen Block von Komponenten. Die Meldung ist normal und kein Fehler.	Keine Maßnahme erforderlich.
Beginning Verify and Repair transaction	Eine Prüftransaktion beginnt. Auch diese Zeile ist zunächst nur ein Ablaufhinweis.	Die nachfolgenden Meldungen lesen.
Verify complete	Ein Prüfblock wurde abgeschlossen. Die Zeile bestätigt nicht zwingend den Erfolg des gesamten SFC Laufs.	Die Abschlussmeldung im Terminal und weitere Einträge beachten.
Repairing corrupted file ... from store	SFC hat eine auffällige Datei erkannt und verwendet den Komponentenspeicher für die Reparatur. Die Zeile allein ist noch kein endgültiger Erfolgsnachweis.	Nach weiteren Reparaturmeldungen suchen und danach SFC erneut ausführen.
Repaired file ... by copying from backup	Eine Reparatur durch Kopieren einer intakten Fassung wurde protokolliert.	Windows neu starten und einen Kontrolllauf durchführen.
Cannot repair member file	Die Datei stimmt nicht mit der erwarteten Windows Komponente überein und konnte in diesem Lauf nicht repariert werden.	DISM ausführen, neu starten und SFC wiederholen.
file is missing	Eine erwartete geschützte Datei fehlt im geprüften Komponentenbestand oder am Zielort.	DISM und danach SFC ausführen. Bei Wiederholung Komponente und Dateipfad genauer prüfen.
hashes for file member do not match	Der berechnete Dateihash entspricht nicht dem erwarteten Wert. Das kann auf eine veränderte Datei oder einen inkonsistenten Komponentenspeicher hinweisen.	Komponentenspeicher mit DISM reparieren und anschließend kontrollieren.

Warum Repairing nicht automatisch repariert bedeutet

Die Formulierung Repairing corrupted file klingt eindeutig, sollte aber nicht isoliert bewertet werden. Sie zeigt, dass SFC die Datei für eine Reparatur vorgesehen oder einen Reparaturvorgang eingeleitet hat. Ob der gesamte Vorgang erfolgreich abgeschlossen wurde, erkennst Du an weiteren Logzeilen, der SFC Abschlussmeldung und einem zweiten Prüflauf.

Der zuverlässigste Nachweis ist ein erneuter Lauf von sfc /scannow, der keine Integritätsverletzungen mehr findet. Bleibt die gleiche Datei weiterhin unter Cannot repair member file stehen, war die Reparatur nicht nachhaltig erfolgreich.

Warum ein Info Eintrag trotzdem wichtig sein kann

In der CBS.log steht vor vielen SFC Meldungen die Stufe Info. Auch Cannot repair member file kann als Info protokolliert werden. Suche daher nicht ausschließlich nach Zeilen mit Error. Für die SFC Auswertung sind der Text hinter [SR] und der zeitliche Zusammenhang entscheidend.

Beispiel: Cannot repair member file auswerten

Eine gekürzte Zeile kann folgendermaßen aussehen:

2026-08-18 10:31:22, Info CSI 00000123 [SR] Cannot repair member file ... "Beispiel.dll" ...

Du kannst daraus mehrere Informationen ableiten:

1. Datum und Uhrzeit zeigen, zu welchem Prüflauf der Eintrag gehört.
2. [SR] bestätigt, dass die Meldung von SFC stammt.
3. Cannot repair member file bedeutet, dass diese Datei in diesem Lauf nicht repariert werden konnte.
4. Der Dateiname allein reicht nicht für einen manuellen Austausch. Zusätzlich müssen Komponente, Version, Architektur, Sprache und Windows Build passen.

Suche nach weiteren Vorkommen desselben Dateinamens im zeitlich passenden Abschnitt. Häufig folgen zusätzliche Zeilen, aus denen hervorgeht, ob die Datei später doch aus dem Komponentenspeicher wiederhergestellt wurde. Prüfe danach die SFC Abschlussmeldung.

Die vier SFC Abschlussmeldungen richtig bewerten

Ergebnis von SFC	Bedeutung	Nächster Schritt
Keine Integritätsverletzungen gefunden	Die geprüften geschützten Systemdateien entsprechen dem erwarteten Zustand.	Für SFC ist keine Reparatur nötig. Besteht das eigentliche Problem weiter, liegt die Ursache möglicherweise an anderer Stelle.
Beschädigte Dateien gefunden und erfolgreich repariert	SFC konnte erkannte Abweichungen beheben.	Windows neu starten und SFC zur Kontrolle noch einmal ausführen.
Beschädigte Dateien gefunden, einige konnten nicht repariert werden	Mindestens eine geschützte Datei blieb fehlerhaft oder die benötigte Reparaturquelle war nicht nutzbar.	SFC Einträge exportieren, DISM ausführen und danach SFC wiederholen.
Der angeforderte Vorgang konnte nicht ausgeführt werden	SFC konnte die Prüfung nicht ordnungsgemäß abschließen. Mögliche Ursachen sind ausstehende Wartungsvorgänge, Zugriffsprobleme oder Dateisystemfehler.	Windows neu starten, den abgesicherten Modus testen und bei Verdacht das Dateisystem prüfen.

Was tun, wenn SFC Dateien nicht reparieren kann?

1. DISM RestoreHealth ausführen

Repariert SFC eine Datei nicht, ist häufig die lokale Reparaturquelle im Windows Komponentenspeicher unvollständig oder inkonsistent. Führe in einem administrativen Terminal erneut folgenden Befehl aus:

DISM.exe /Online /Cleanup-Image /RestoreHealth

Danach startest Du Windows neu und führst sfc /scannow erneut aus. Diese Reihenfolge ist wichtig: DISM repariert den Komponentenbestand, SFC verwendet ihn anschließend zur Wiederherstellung geschützter Systemdateien.

2. DISM Fehler 0x800f081f richtig behandeln

Erscheint bei DISM der Fehler 0x800f081f, wurden die erforderlichen Quelldateien nicht gefunden. In diesem Fall benötigst Du eventuell ein passendes Windows Installationsmedium als Reparaturquelle. Edition, Sprache, Architektur und Versionsstand müssen zum installierten Windows passen. Die notwendigen Schritte erklären wir ausführlich im Beitrag zum Windows Fehlercode 0x800f081f.

3. Fehler 0x80073712 und beschädigten Komponentenspeicher prüfen

Der Fehler 0x80073712 weist häufig auf fehlende oder beschädigte Komponenten hin. In diesem Fall solltest Du nicht einzelne Dateien aus unbekannten Quellen kopieren. Repariere zuerst den Komponentenspeicher und arbeite danach mit SFC weiter. Eine passende Fehleranalyse findest Du in der Anleitung zu 0x80073712 bei Windows Update.

4. SFC im abgesicherten Modus erneut starten

Kann der Windows Ressourcenschutz den Vorgang nicht ausführen, teste SFC im abgesicherten Modus. Dort laufen weniger Treiber, Dienste und Hintergrundprogramme. Dadurch sind weniger Systemdateien durch zusätzliche Prozesse belegt. Die Startmöglichkeiten zeigt die Anleitung zum abgesicherten Modus von Windows 11.

5. Das Dateisystem nur bei konkretem Verdacht prüfen

Wiederholen sich beschädigte Dateien trotz erfolgreicher Reparatur, treten Lesefehler auf oder kann SFC seine Prüfung nicht abschließen, solltest Du auch das Dateisystem kontrollieren. Verwende CHKDSK nicht routinemäßig ohne Anlass, sondern bei passenden Symptomen. Eine sichere Vorgehensweise findest Du im Beitrag zum Prüfen und Reparieren einer Festplatte.

6. Reparaturinstallation als letzte saubere Eskalationsstufe

Bleiben SFC und DISM erfolglos, ist eine Reparaturinstallation meist sinnvoller als das manuelle Ersetzen mehrerer Systemdateien. Dabei wird Windows über die vorhandene Installation installiert, während persönliche Dateien und installierte Programme bei der passenden Auswahl erhalten bleiben können. Sichere Deine Daten trotzdem vorher. Die Unterschiede zwischen Reparatur, Zurücksetzen und Neuinstallation erklärt unsere Anleitung Windows neu installieren.

Warum Du Systemdateien nicht vorschnell manuell ersetzen solltest

Die CBS.log nennt häufig einen konkreten Dateinamen. Das verleitet dazu, die Datei aus einem anderen PC oder aus einem Download zu übernehmen. Davon solltest Du ohne genaue Versionsprüfung absehen. Eine gleichnamige DLL kann zu einer anderen Windows Build, einer anderen Architektur oder einem anderen Update Stand gehören.

Ein falscher Austausch kann neue Startprobleme, Fehler bei Windows Update oder inkonsistente Komponenten verursachen. Außerdem besitzen geschützte Systemdateien besondere Besitzer und Zugriffsrechte. Änderungen mit Besitzübernahme und Vollzugriff können die Windows Wartung beeinträchtigen.

Die empfohlene Reihenfolge lautet deshalb:

1. DISM ausführen.
2. SFC erneut ausführen.
3. Windows Update und ausstehende Neustarts prüfen.
4. Bei Bedarf den abgesicherten Modus verwenden.
5. Eine Reparaturinstallation durchführen.
6. Eine Datei nur als letzte Maßnahme und mit exakt passender Quelle manuell ersetzen.

CBS.log und DISM.log: Was ist der Unterschied?

Protokoll	Standardpfad	Hauptzweck
CBS.log	C:\Windows\Logs\CBS\CBS.log	Komponentenbasierte Windows Wartung, Updates, Features und SFC Einträge mit [SR].
DISM.log	C:\Windows\Logs\DISM\dism.log	Ablauf und Fehler von DISM Befehlen, einschließlich der Reparatur des Windows Images.

Wenn sfc /scannow fehlschlägt, wertest Du zuerst die [SR] Einträge in der CBS.log aus. Scheitert anschließend DISM /RestoreHealth, prüfst Du zusätzlich die DISM.log. Bei Updatefehlern können wiederum weitere CBS Einträge ohne [SR] relevant sein.

Was tun, wenn in der CBS.log keine aktuellen SFC Einträge stehen?

Prüfe zuerst, ob der SFC Lauf wirklich beendet wurde und ob Du die richtige Windows Installation untersuchst. Nach einem aktuellen Lauf sollten die Einträge normalerweise in C:\Windows\Logs\CBS\CBS.log stehen.

Windows archiviert ältere CBS Protokolle im gleichen Ordner. Dort können Dateien mit Namen wie CbsPersist_*.log oder CbsPersist_*.cab liegen. Für eine aktuelle Fehlersuche ist es meistens einfacher, SFC erneut kontrolliert auszuführen und direkt danach die [SR] Zeilen aus der aktuellen CBS.log zu exportieren.

Lösche den CBS Ordner nicht, um die Übersicht zu verbessern. Dadurch gehen wichtige Diagnoseinformationen verloren. Erstelle stattdessen eine gefilterte Arbeitskopie.

Typische Fehler bei der SFC CBS.log Auswertung

Alte und neue Prüfläufe vermischen

Die Datei SFC-Details.txt enthält nicht automatisch nur den letzten Lauf. Vergleiche Datum und Uhrzeit und bewerte ausschließlich das passende Zeitfenster.

Nur nach Error suchen

Viele relevante SFC Meldungen stehen unter der Protokollstufe Info. Suche immer nach [SR] und den konkreten Meldungstexten.

Repairing mit erfolgreich repariert gleichsetzen

Eine Reparaturzeile allein ist kein abschließender Beweis. Entscheidend sind der weitere Ablauf, die SFC Abschlussmeldung und der Kontrolllauf.

Die gesamte CBS.log anstelle der SFC Einträge lesen

Ohne Filter siehst Du zahlreiche Meldungen zu Updates, Features und Komponenten. Das erschwert die Suche und erhöht die Gefahr einer falschen Zuordnung.

Eine einzelne DLL ohne Kontext ersetzen

Der Dateiname reicht nicht aus. Windows Version, Build, Architektur, Sprache, Komponentenversion und Wartungsstand müssen zusammenpassen. Nutze daher zuerst die integrierten Reparaturwege.

SFC als universelle Fehlerdiagnose verwenden

Ein sauberer SFC Lauf beweist nur, dass die geprüften geschützten Systemdateien keinen erkannten Integritätsfehler aufweisen. Treiberfehler, defekte Benutzerprofile, Hardwareprobleme und Fehler einzelner Programme können trotzdem bestehen. Bei einem beschädigten Benutzerkonto hilft beispielsweise eher die Anleitung zum Reparieren eines Windows Profils.

Aus der Administratorpraxis: So bleibt die Analyse nachvollziehbar

Bewährt hat sich ein klarer Ablauf mit dokumentierten Zeitpunkten. Notiere vor jedem Befehl Uhrzeit und Zweck. Speichere die gefilterte Datei mit Datum im Namen, zum Beispiel SFC-Details-2026-08-18.txt. So kannst Du einen Lauf vor der Reparatur mit dem Kontrolllauf danach vergleichen.

Prüfe zuerst die Abschlussmeldung, danach nur die zeitlich passenden [SR] Zeilen. Suche nach nicht reparierbaren Dateien und fasse gleiche Dateinamen zusammen. Ein mehrfach genannter Dateiname bedeutet nicht automatisch mehrere verschiedene Schäden. Oft protokolliert SFC denselben Vorgang in mehreren aufeinanderfolgenden Zeilen.

Bei wiederkehrenden Fehlern solltest Du zusätzlich festhalten, ob das Problem direkt nach einem Update, einem Stromausfall, einer Datenträgerstörung oder einer Softwareinstallation begonnen hat. Diese zeitliche Einordnung ist oft hilfreicher als eine isolierte Logzeile.

Praxistipp: Vorher und nachher vergleichen

Erstelle nach einem fehlgeschlagenen Lauf eine erste gefilterte Datei. Führe danach DISM, einen Neustart und SFC erneut aus. Exportiere die neuen Einträge unter einem anderen Dateinamen. Vergleiche anschließend nur die jeweils passenden Zeitbereiche.

Verschwindet Cannot repair member file und meldet der zweite SFC Lauf keine Integritätsverletzungen, ist die Reparatur plausibel abgeschlossen. Bleibt derselbe Fehler bestehen, solltest Du nicht immer wieder identische Befehle ausführen. Wechsle dann zur nächsten sinnvollen Stufe, etwa einer passenden DISM Quelle oder einer Windows Reparaturinstallation. Einen Gesamtüberblick bietet die Anleitung Windows reparieren.

FAQ zum Auswerten der SFC CBS.log

Fazit: SFC CBS.log gezielt statt vollständig lesen

Um die SFC CBS.log auszuwerten, brauchst Du nicht das gesamte Windows Wartungsprotokoll zu entschlüsseln. Filtere am besten die Zeilen mit [SR], grenze den letzten Prüflauf über Datum und Uhrzeit ein und suche anschließend nach eindeutigen Meldungen wie Cannot repair member file, Repairing corrupted file und Repaired file.

Bewerte anschließend die einzelnen Zeilen immer zusammen mit der SFC Abschlussmeldung. Wenn SFC Dateien nicht reparieren kann, dann führst Du zuerst DISM aus und wiederholst danach die Systemdateiprüfung. Bleibt derselbe Fehler bestehen, sind eine passende Reparaturquelle oder eine Windows Reparaturinstallation meist sicherer als das manuelle Austauschen geschützter Windows Systemdateien.