SFC meldet

Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und konnte einige der Dateien nicht reparieren.

Je nach Windows-Version lautet der Satz leicht anders, etwa „…gefunden, konnte jedoch einige nicht reparieren“. Auf einem englischen Windows heißt er: „Windows Resource Protection found corrupt files but was unable to fix some of them.“

// Kurz
  1. Lief vorher DISM /Online /Cleanup-Image /RestoreHealth ohne Fehler? Wenn nicht, zuerst das. Meist ist die Meldung danach weg.
  2. Die Problemzeilen aus der CBS.log auf den Desktop holen (Befehl unten).
  3. Die Zeilen mit dem Datum des letzten Laufs lesen. Bei Cannot repair member file steht der Dateiname.
  4. Je nach Befund: DISM mit ISO-Quelle, bekannten Fehlalarm abhaken, einzelne Datei ersetzen oder Windows über sich selbst installieren.

Was die Meldung bedeutet

SFC vergleicht jede geschützte Systemdatei mit ihrer Referenzkopie im Komponentenspeicher (C:\Windows\WinSxS). Weicht eine Datei ab, ersetzt SFC sie durch diese Kopie. „Konnte nicht reparieren“ heißt: Auch die Kopie ist beschädigt oder fehlt. SFC hat dann nichts, womit es ersetzen könnte.

Deshalb ist der erste Schritt fast immer derselbe: die Referenzkopien mit DISM reparieren, danach SFC erneut. Wie das geht, einschließlich der Reparatur aus einer ISO, steht im Ratgeber DISM oder SFC zuerst: die richtige Reihenfolge. Bleibt die Meldung danach, lohnt der Blick ins Protokoll.

Schritt 1: Die Problemzeilen herausholen

SFC schreibt in C:\Windows\Logs\CBS\CBS.log. Die Datei ist oft viele Megabyte groß und enthält auch alles, was Windows Update dort protokolliert. Die Zeilen von SFC tragen die Markierung [SR]. Ein einziger Lauf erzeugt davon allerdings Hunderte, fast alle Routine. Deshalb gleich nur die Zeilen herausfiltern, auf die es ankommt.

In der Eingabeaufforderung

Startmenü öffnen, cmd eingeben, „Als Administrator ausführen“. Dann:

Eingabeaufforderung (Administrator)
findstr /c:"Cannot repair" /c:"Repairing corrupted" /c:"also corrupted" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\sfcprobleme.txt"

In PowerShell oder im Terminal

Das Terminal, das Win+X öffnet, startet standardmäßig PowerShell. Dort werden %windir% und %userprofile% nicht aufgelöst, und der Befehl oben scheitert mit „kann nicht geöffnet werden“. Entweder vorher cmd eingeben, oder diese Fassung nehmen:

PowerShell (Administrator)
Select-String -Path "$env:windir\Logs\CBS\CBS.log" -SimpleMatch -Pattern 'Cannot repair','Repairing corrupted','also corrupted' | ForEach-Object Line | Out-File "$env:USERPROFILE\Desktop\sfcprobleme.txt"

Auf dem Desktop liegt danach sfcprobleme.txt. Mit dem Editor öffnen.

  • Die Einträge sind englisch, auch auf einem deutschen Windows. Das ist normal.
  • Die Datei ist leer: Entweder hat SFC im Protokoll nichts vermerkt, oder Windows hat ältere Teile der CBS.log bereits in CbsPersist_…-Dateien im selben Ordner ausgelagert. Dann sfc /scannow noch einmal laufen lassen und den Befehl direkt danach wiederholen.

Die Methode von Microsoft: alle [SR]-Zeilen

Microsoft selbst empfiehlt, alle Zeilen mit [SR] herauszuziehen:

Eingabeaufforderung (Administrator)
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

Das ist vollständig, aber lang: SFC prüft in Blöcken von rund hundert Komponenten und schreibt für jeden Block dieselben Routinezeilen. Der Filter aus Schritt 1 lässt diese Routine weg und zeigt nur die Zeilen, bei denen etwas gefunden wurde. Wer der Sache genauer nachgehen will, nimmt die vollständige Fassung.

Schritt 2: Nur den letzten Lauf betrachten

Die CBS.log enthält alle Läufe, die noch nicht ausgelagert sind, also womöglich auch ältere, deren Fehler längst behoben sind. Jede Zeile beginnt mit Datum und Uhrzeit:

CBS.log · Zeilenanfang
2026-09-24 21:46:19, Info  CSI  00000006 [SR] …

Maßgeblich sind nur die Zeilen mit dem Zeitpunkt, zu dem du SFC zuletzt gestartet hast. Die neuesten stehen am Ende der Datei. Ein Lauf ist in wenigen Minuten erledigt, seine Zeilen liegen also dicht beieinander.

Schritt 3: Die Zeilen lesen

Was die Zeilen in der CBS.log bedeuten
Zeile enthältBedeutung
Repairing corrupted file … from storeSFC hat eine beschädigte Datei gefunden und aus dem Komponentenspeicher ersetzt. Erledigt.
Repaired file … by copying from backupSFC hat die Datei aus einer internen Sicherungskopie ersetzt. Ebenfalls erledigt.
Cannot repair member fileDiese Datei konnte nicht ersetzt werden. Das ist die gesuchte Zeile.
source file in store is also corruptedDie Referenzkopie ist ebenfalls kaputt. Fall für DISM.
⚠ Laut Microsoft steht „Repairing corrupted file“ auch dann im Protokoll, wenn SFC nur geprüft hat, zum Beispiel mit sfc /verifyonly. Repariert wurde dabei nichts. Maßgeblich ist, ob der Lauf mit /scannow oder mit /verifyonly gestartet wurde.

Wer alle [SR]-Zeilen ansieht: Verifying … components, Beginning Verify and Repair transaction und Verify complete wiederholen sich für jeden Block von rund hundert Komponenten. Das ist Routine und sagt nichts über Fehler.

Eine „Cannot repair“-Zeile auseinandernehmen

So sieht eine solche Zeile ungefähr aus (gekürzt, Dateiname als Beispiel; je nach Windows-Version ist der Aufbau etwas anders):

CBS.log · Beispiel
[SR] Cannot repair member file [l:12]"beispiel.dll" of Microsoft-Windows-Beispiel,
version 10.0.26100.1, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}, type [l:0]"",
in the store, hash mismatch
  • "beispiel.dll" ist die betroffene Datei. Die Zahl davor ([l:12]) ist nur die Länge des Namens.
  • of Microsoft-Windows-… nennt die Windows-Komponente, zu der sie gehört. Daran erkennst du oft schon, worum es geht: Grafik, Defender, Netzwerk.
  • Das Ende sagt, was los ist: hash mismatch heißt, die Datei ist verändert. file is missing heißt, sie fehlt ganz.

Schreib dir die Dateinamen aus dem letzten Lauf heraus. Meist sind es nur ein oder zwei.

Schritt 4: Was tun, je nach Befund

Die Referenzkopie ist kaputt

Taucht source file in store is also corrupted auf oder lief DISM nie erfolgreich: DISM /Online /Cleanup-Image /RestoreHealth, bei Fehler 0x800f081f mit einer ISO als Quelle. Danach neu starten und sfc /scannow wiederholen. Die genauen Befehle stehen im Ratgeber Reparatur aus einer ISO.

Bekannte Fehlalarme

Manche Dateien meldet SFC, weil ein Treiber oder ein Update sie durch eine andere, rechtmäßige Fassung ersetzt hat. Microsoft hat zwei solche Fälle beschrieben:

  • opencl.dll unter Windows 10 im Ordner SysWOW64 (KB 3178332). In Foren wird als Auslöser meist die Installation von Grafiktreibern genannt, die eine eigene Fassung der Datei mitbringen.
  • Dateien des Defender-PowerShell-Moduls in System32\WindowsPowerShell\v1.0\Modules\Defender, gemeldet mit „Hashes for file member do not match“ (KB 4513240). Das betraf Defender-Versionen aus dem Jahr 2019 und ist seit Version 4.8.1908 behoben.

In beiden Fällen nennt Microsoft als Abhilfe DISM /Online /Cleanup-Image /RestoreHealth und danach sfc /scannow. Bleibt nur eine solche Datei übrig und läuft der Rechner sonst normal, ist das kein Grund für eine Neuinstallation. Bei anderen Dateien hilft eine Suche nach dem Dateinamen zusammen mit „sfc“.

Eine einzelne Datei bleibt übrig

Microsoft beschreibt einen Weg, eine einzelne Systemdatei von Hand zu ersetzen. Dafür brauchst du eine intakte Kopie aus exakt demselben Windows-Build, etwa von einem zweiten Rechner, auf dem winver dieselbe Buildnummer zeigt.

⚠ Eine Datei aus einer anderen Windows-Version kann Windows am Starten hindern.
Terminal (Administrator)
takeown /f C:\Windows\System32\beispiel.dll
icacls C:\Windows\System32\beispiel.dll /grant administrators:F
copy D:\intakt\beispiel.dll C:\Windows\System32\beispiel.dll

Pfad und Dateiname aus der CBS.log übernehmen, D:\intakt durch den Ort der intakten Kopie ersetzen. Danach neu starten und sfc /verifyonly laufen lassen. Dieser Weg lohnt sich nur bei einer einzelnen Datei. Bei mehreren ist der nächste Abschnitt einfacher.

Nichts davon hilft

Dann ist ein Inplace-Upgrade der sauberste Weg: die Windows-ISO in derselben Version einbinden, setup.exe im laufenden Windows starten und „Persönliche Dateien und Apps behalten“ wählen. Windows spielt alle Systemdateien neu auf, Programme und Daten bleiben. Eine Datensicherung vorher ist trotzdem Pflicht. Ausführlich, mit dem einfacheren Weg über Windows Update: Windows über sich selbst installieren.

SFC im abgesicherten Modus

Der abgesicherte Modus hilft vor allem bei einer anderen Meldung: „Der Windows-Ressourcenschutz konnte den angeforderten Vorgang nicht ausführen.“ Dann läuft SFC gar nicht erst durch. Bei „konnte einige nicht reparieren“ ändert er meist nichts, denn die Ursache liegt im Komponentenspeicher, nicht in einem laufenden Programm.

So kommst du hinein: Einstellungen → System → Wiederherstellung → „Erweiterter Start“ → „Jetzt neu starten“, dann „Problembehandlung“ → „Erweiterte Optionen“ → „Starteinstellungen“ → „Neu starten“ und die Taste 4. Dort sfc /scannow in einer Eingabeaufforderung als Administrator ausführen.

Die Fehler kommen immer wieder

Repariert SFC Dateien erfolgreich und meldet beim nächsten Lauf neue, liegt die Ursache selten in Windows. Häufiger ist es die Hardware: fehlerhafter Arbeitsspeicher (mdsched prüft ihn beim nächsten Start) oder ein defekter Datenträger (Diagnosewerkzeug des Herstellers bzw. SMART-Werte; bei einer herkömmlichen Festplatte mit Lesefehlern chkdsk C: /r). Solange die Ursache bleibt, repariert jede Software nur Symptome.

Quellen

// UCE

Was UCE dabei übernimmt

Das Windows-Reparatur-Tool UCE wertet nach jedem SFC-Lauf die CBS.log aus und fasst das Ergebnis auf der Health-Seite in Klartext zusammen. Es führt DISM und SFC in der richtigen Reihenfolge aus und prüft mit einem zweiten SFC-Lauf nach.

Welche Dateien genau betroffen sind, zeigt UCE nicht einzeln an. Dafür bleibt die Anleitung oben der Weg.

Kostenlos: die Diagnose, also DISM-Prüfung, SFC im Nur-Lesen-Modus und Datenträgerprüfung, dazu einmal ein kompletter Reparaturlauf zum Ausprobieren. Pro, einmalig 29 €: die Reparatur, so oft du sie brauchst.