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.“
- Lief vorher
DISM /Online /Cleanup-Image /RestoreHealthohne Fehler? Wenn nicht, zuerst das. Meist ist die Meldung danach weg. - Die Problemzeilen aus der CBS.log auf den Desktop holen (Befehl unten).
- Die Zeilen mit dem Datum des letzten Laufs lesen. Bei
Cannot repair member filesteht der Dateiname. - 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:
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:
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. Dannsfc /scannownoch einmal laufen lassen und den Befehl direkt danach wiederholen.
Die Methode von Microsoft: alle [SR]-Zeilen
Microsoft selbst empfiehlt, alle Zeilen mit [SR] herauszuziehen:
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:
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
| Zeile enthält | Bedeutung |
|---|---|
Repairing corrupted file … from store | SFC hat eine beschädigte Datei gefunden und aus dem Komponentenspeicher ersetzt. Erledigt. |
Repaired file … by copying from backup | SFC hat die Datei aus einer internen Sicherungskopie ersetzt. Ebenfalls erledigt. |
Cannot repair member file | Diese Datei konnte nicht ersetzt werden. Das ist die gesuchte Zeile. |
source file in store is also corrupted | Die Referenzkopie ist ebenfalls kaputt. Fall für DISM. |
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):
[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 mismatchheißt, die Datei ist verändert.file is missingheiß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.dllunter Windows 10 im OrdnerSysWOW64(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.
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
- Microsoft Learn: Analyze log file entries that SFC.exe generates (KB 928228; [SR]-Zeilen, Bedeutung der Einträge; englisch)
- Microsoft Support: Verwenden der Systemdateiprüfung (Meldungen, einzelne Datei ersetzen)
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.