Was SFC und DISM tatsächlich prüfen
SFC: geschützte Windows-Systemdateien
SFC prüft geschützte Systemdateien und kann beschädigte Dateien durch eine zwischengespeicherte Kopie ersetzen. Persönliche Dokumente sind nicht sein Prüfobjekt. Ein unauffälliges Ergebnis sagt deshalb nichts über die Vollständigkeit deiner Fotos oder Arbeitsdateien aus.
DISM: der Windows-Komponentenspeicher
DISM besitzt verschiedene Funktionen zur Wartung von Windows-Abbildern. Hier geht es ausschliesslich um /Cleanup-Image: den Zustand des Komponentenspeichers prüfen und gegebenenfalls reparieren. Ein geeigneter Komponentenbestand ist die Grundlage für die anschliessende Systemdateireparatur.
Unterschiede auf einen Blick
- SFC: geschützte Systemdateien prüfen;
/scannowkann dabei reparieren. Kein Test für RAM, SSD oder sämtliche Programme. - DISM: Komponentenbestand prüfen oder reparieren – abhängig vom gewählten Befehl. Kein Nachweis, dass ein bestimmter App-Absturz dadurch behoben wird.
- /Online: bezeichnet das gerade laufende Windows, nicht einen Internetmodus. Ob eine Verbindung benötigt wird, hängt unter anderem von der Reparaturquelle ab.
Die Microsoft-Befehlsreferenzen unterscheiden Prüf- und Reparaturoptionen; diese Unterscheidung ist auch für die Ergebnisbewertung wichtig.
Wann DISM und SFC sinnvoll sind – und wann nicht
Hinweise auf beschädigte Windows-Komponenten
Eine Prüfung ist nachvollziehbar, wenn Windows-Funktionen wiederholt ausfallen oder eine konkrete Meldung beschädigte Systemdateien beziehungsweise Komponenten nennt. Ein Updatefehler allein beweist das nicht. Notiere zuerst Fehlercode, betroffene Funktion und Zeitpunkt; für einen fehlgeschlagenen KB-Eintrag hilft die gezielte Windows-Update-Diagnose.
Hardware, einzelne Apps und Kontoprobleme getrennt prüfen
Klickgeräusche, SMART-Warnungen, instabiler RAM oder Überhitzung verlangen eine andere Diagnose. Sichere wichtige Daten, soweit das gefahrlos möglich ist, und kläre zuerst Laufwerkswarnungen beziehungsweise konkrete Hinweise auf Arbeitsspeicherfehler. Eine Systemdateireparatur ersetzt keine Hardwareprüfung.
Passende Vertiefung: Laufwerkswarnungen einordnen oder Arbeitsspeicher gezielt prüfen.
Stürzt nur eine App ab, sind deren Version, Fehlermodul und Absturzzeitpunkt wichtige Ausgangspunkte. Auch Malware-, Anmelde- und Benutzerprofilprobleme werden durch einen erfolgreichen SFC-Lauf nicht ausgeschlossen. Bei Bluescreens führt die belegorientierte Absturzdiagnose weiter.
Windows startet nicht oder wird zentral verwaltet
Die Online-Befehle dieser Seite gehören in das laufende Windows. Übertrage sie nicht unverändert in die Wiederherstellungsumgebung und rate keine Laufwerksbuchstaben. Nutze bei Startproblemen die Wiederherstellungsentscheidung. Auf verwalteten Geräten entscheidet die zuständige IT über Rechte, Richtlinien und Reparaturquellen.
Vor dem Start: Voraussetzungen und Sicherheit
Daten, Sitzung und Berechtigungen
- Speichere offene Dateien und sichere wichtige Daten vor einer Reparatur.
- Öffne Terminal oder Eingabeaufforderung ausdrücklich als Administrator.
- Sorge für stabile Stromversorgung. Unterbrich keine laufende Updateinstallation; beachte einen angeforderten Neustart.
- Führe Befehle einzeln aus und lies jeweils die Abschlussmeldung. Schliesse das Fenster nicht während einer laufenden SFC-Prüfung.
Windows-Version und Reparaturquelle
Diese Anleitung richtet sich an ein bedienbares Windows-11-Desktop-System, nicht an Server- oder Offline-Image-Wartung. Technisch verfügbare Befehle ersetzen keine Prüfung des Supportstatus einer älteren Windows-Version.
Windows Update ist normalerweise die Reparaturquelle, sofern die Richtlinien dies erlauben. Kläre bei Firmenrechnern zuerst die vorgesehene Quelle. Keine feste Laufzeit oder pauschale Mindestmenge freien Speichers garantiert einen erfolgreichen Lauf.
Befehle und Reihenfolge verstehen
Optional prüfen: CheckHealth und ScanHealth
DISM /Online /Cleanup-Image /CheckHealth
Fragt den bereits erfassten Beschädigungsstatus ab; ersetzt keinen neuen vollständigen Scan.
DISM /Online /Cleanup-Image /ScanHealth
Untersucht den Komponentenspeicher auf Beschädigungen. Diese beiden Optionen reparieren nicht. Sie sind Diagnosemöglichkeiten, keine zwingenden Vorstufen jedes Reparaturlaufs.
Reparieren: RestoreHealth, danach SFC
DISM /Online /Cleanup-Image /RestoreHealth
Prüft den Komponentenbestand und versucht eine Reparatur. Warte den Abschluss ab; bei einem Fehler erst Meldung und Quelle klären.
sfc /scannow
Microsoft empfiehlt im kombinierten Reparaturweg zunächst DISM, danach SFC. So steht die reparierte Grundlage vor der Systemdateiprüfung bereit. Daraus folgt nicht, dass eine eigenständige SFC-Prüfung grundsätzlich unzulässig wäre.
Geführte Durchführung im Reparaturcenter
Wenn du die Schritte mit Kopierfunktionen und Fortschrittsanzeige durchgehen möchtest, nutze DISM und SFC im Reparaturcenter. Die folgende Auswertung hilft dir anschliessend, den Befund einzuordnen.
Ergebnisse lesen: Was ist jetzt tatsächlich bewiesen?
Die folgenden Gruppen sind sinngemässe Zusammenfassungen, keine garantierten wortgleichen Windows-Meldungen.
DISM: Zustand und Abschlussmeldung
- Unauffälliger Status: kein gemeldeter Komponentenbefund. Bei CheckHealth fehlt damit weiterhin ein neuer Scan; notiere die verwendete Option.
- Reparierbarer Befund: eine Reparatur ist vorgesehen, aber noch nicht nachgewiesen. Prüfe Voraussetzungen und führe gegebenenfalls RestoreHealth aus.
- Reparatur erfolgreich abgeschlossen: der Vorgang meldet Erfolg. Danach SFC und das ursprüngliche Symptom prüfen.
- Nicht reparierbar: nicht dieselbe Befehlsfolge endlos wiederholen. Datenlage sichern und einen passenden Wiederherstellungsweg abklären.
SFC: vier Ergebnisgruppen
- Keine Integritätsverletzung: kein entsprechender Befund im Prüfumfang. Das ursprüngliche Problem gesondert untersuchen.
- Beschädigte Dateien repariert: Reparatur gemeldet. Nach einem geeigneten Neustart das Ausgangssymptom erneut testen.
- Nicht alle Dateien repariert: unvollständiges Ergebnis. Den passenden CBS-Protokollausschnitt prüfen.
- Vorgang nicht ausführbar: keine abgeschlossene Integritätsprüfung. Fehlermeldung und Ausführungsumgebung klären.
Werkzeug erfolgreich, Problem weiterhin vorhanden
Trenne im eigenen Fehlerprotokoll zwei Aussagen: «Werkzeug meldet Erfolg» und «Mein Problem tritt nicht mehr auf». Nur der erneute Symptomtest kann die zweite Aussage stützen. Zusätzliche Reparaturen ohne neuen Befund machen die Ursache nicht klarer.
Wenn die Prüfung scheitert: Fehler und Protokolle einordnen
Quelldateien fehlen: Kontext und passende Quelle prüfen
0x800F081F gehört zum Quellenkontext. Notiere auch den Befehl und die vollständige Fehlermeldung; der Code allein bestimmt keine geeignete ISO. Prüfe, ob Windows Update erreichbar und als Quelle zugelassen ist. Weitere Codes kannst du in der Windows-Fehlercode-Datenbank einordnen.
Eine alternative Quelle muss zur Installation passen. Microsoft nennt insbesondere einen geeigneten Wartungsstand und die benötigten Sprachkomponenten. Ein neuerer Wartungsstand des Zielsystems als der Quelle kann die Reparatur scheitern lassen. Deshalb hier kein pauschaler /Source-Befehl mit geratenem Pfad oder Image-Index: Quelle und Ziel zuerst fachlich abgleichen.
Keine Administratorrechte oder scheinbarer Stillstand
Bei einer Berechtigungsmeldung zuerst kontrollieren, ob das Terminal erhöht gestartet wurde. Eine lange unveränderte Prozentanzeige allein beweist keinen Stillstand. Notiere Startzeit, letzte Ausgabe und eine allfällige Fehlermeldung; schiesse den Prozess nicht allein aufgrund eines Prozentwerts ab. Bei Unsicherheit vor einem Eingriff Unterstützung holen.
CBS- und DISM-Protokolle zeitlich zuordnen
SFC-Details stehen im CBS-Protokoll unter %WINDIR%\Logs\CBS\CBS.log; die Markierung [SR] hilft beim Zuordnen. Vergleiche Datum und Uhrzeit mit deinem Lauf, statt einen alten Treffer als aktuellen Fehler zu behandeln.
DISM verwendet standardmässig %WINDIR%\Logs\DISM\dism.log; eine explizite Logkonfiguration kann davon abweichen. Bewahre den Zusammenhang zwischen ausgeführtem Befehl, Zeitpunkt und Abschlussmeldung.
Teile nur den relevanten Ausschnitt und entferne Benutzernamen, Rechnernamen und andere persönliche Angaben. Die lokale Berichtsanalyse kann Hinweise einordnen, ersetzt aber keinen Nachweis der Ursache.
Gleicher Fehler nach erneutem Versuch
Wiederhole einen Lauf nur mit begründet geänderter Ausgangslage, etwa einer korrigierten Quelle. Bleibt derselbe Befund bestehen, sichere die Ergebnisse und prüfe die passende Wiederherstellung oder hole Fachsupport. Diese Basisanleitung empfiehlt weder manuelles Ersetzen von Systemdateien noch Rechteübernahmen oder das Löschen von WinSxS-Inhalten.
Reparatur überprüfen: ein Ergebnis ist noch keine gelöste Ursache
Dasselbe Symptom unter denselben Bedingungen testen
- Abschlussmeldungen sichern und den PC bei Bedarf beziehungsweise angefordert kontrolliert neu starten.
- Das ursprüngliche Problem unter denselben Bedingungen testen.
- Neue Ereignisse zum Testzeitpunkt im Zuverlässigkeitsverlauf einordnen.
- Nur eine weitere Änderung gleichzeitig vornehmen und deren Wirkung getrennt festhalten.
Lernbeispiel: SFC repariert Dateien, die App stürzt weiter ab
Fiktives Beispiel: SFC meldet reparierte Dateien. Nach dem Neustart stürzt dasselbe Programm beim Öffnen derselben Datei erneut ab. Der Reparaturlauf war laut Meldung erfolgreich, hat dieses beobachtete Problem aber nicht beseitigt.
Der nächste sinnvolle Beleg ist nun der neue Absturz: Programmversion, Zeitpunkt und gegebenenfalls Fehlermodul erfassen. Nicht einfach weitere SFC-Läufe als Lösung voraussetzen. Erst der zusätzliche Befund entscheidet, ob die App, ihre Umgebung oder eine andere Diagnose weiterhilft.
Quellen und passende nächste Schritte
Microsoft-Dokumentation zu Befehlen und Reparaturquellen
- Microsoft: empfohlener DISM-/SFC-Reparaturweg
- Microsoft: Windows-Abbild prüfen und reparieren
- Microsoft: geeignete Reparaturquellen
- Microsoft: Cleanup-Image-Befehlsoptionen
- Microsoft: SFC-Ergebnisse und CBS-Protokoll
- Microsoft: Online-Kontext und DISM-Protokollpfad
Gezielt weiter: ausführen, einordnen oder wiederherstellen
Reparaturcenter: den gewählten Systemdateiweg geführt ausführen. Berichtsanalyse: einen passenden Protokollausschnitt lokal einordnen. Wiederherstellungsentscheidung: bei nicht sinnvoll reparierbarem Zustand Auswirkungen und Alternativen abwägen.