[Windows 10/11] SFC meldet reparierte Fehler (wiederholt/reproduzierbar)

[s1ave77]

1. DER GLITCH​

Der System File Integrity Check aka sfc /scannow wird ja gern empfohlen. Leider wurde mit einem kumulative Update bei Win 10 ein kosmetischer Glitch implementiert, der immer noch vorhanden ist.

Der Glitch wird getriggert, wenn die Update-Bereinigung (normal reicht, kein /resetbase) via DISM oder die systemeigene Bereinigung gastartet wurde. Letztere läuft alle 30 Tage auch automatisiert im Hintergrund.

Daher lohnt es sich immer mal zu schauen, was da eigentlich gemeldet wurde. Kann wichtig sein, oder auch nicht.

Heißt aber nicht, daß dort wirklich ein Problem gelöst wurde und es jetzt laufen sollte .

Im admin CMD:

(findstr /i /c:"[SR]" "%windir%\Logs\CBS\CBS.log" | findstr /i /v /c:"verify")>>%userprofile%\desktop\check.txt

erstellt eine sfc.txt auf dem Desktop mit Fehler und Lösung. Das CBS Log ist 10.000 lang und dynamisch. Viel Spaß bei der manuellen Suche.

Wenn es sich um den Glitch handelt, sieht es so aus:

17:26:13 2024-07-13 17:26:12, Info                  CSI    000002a4 [SR] Repairing 0 components
17:26:13 2024-07-13 17:26:12, Info                  CSI    000002a6 [SR] Repair complete

Gehen sie bitte weiter, hier gibt es nicht zu sehen.

2. NICHT-DER-GLITCH, WIRKLICH FEHLER REPARIERT BEI SFC​

Interessant aber rein informativ.

3. FEHLER BEI SFC, REPARATUR SCHEITERT​

Hier kann eine Reparatur des Komponentenspeichers (WinSXS) helfen, via DISM.

Online:

Dism /Online /Cleanup-Image /RestoreHealth

Offline über WIM/ESD:
Dazu das Windows-ISO per Rechtsklick bereitstellen und:

::WIM
Dism /Online /Cleanup-Image /RestoreHealth /Source:wim:d:\sources\install.wim:1 /limitaccess
::ESD
Dism /Online /Cleanup-Image /RestoreHealth /Source:esd:d:\sources\install.esd:1 /limitaccess

d ist der Buchstabe des Mounts.

1 ist der Index in der WIM/ESD kann bei Multi-Index auch 2 sein für Pro, etc.

Danach nocheinmal den SFC starten. Der läuft dann mit repariertem Komponentenspeicher und sollte die Fehler beheben können.

Ob es hilft, ist eh immer so eine Sache. Viele Probleme sind eine Mischung aus Dateikorruprtion, Treiberproblemen und anderen Quirks. Da gibt's meist keine schnelle Lösung auf Knopfdruck. Da hilft nur das Problem zu verstehen, was naja wieder komplex ist ....

Wenn das nicht hilft, bleibt nur eine Reparatur via In-Place-Upgrade vom bereitgestellten ISO/USB-Stick, mit setup.exe.

Die ist mit Win 10 sehr stabil und zuverlässig geworden. Backup™ ist halt Eigenverantwortung, sollte klar sein.

 

[chainr3action]

Ok, und was genau ist jetzt der Glitch oder Fehler?

 

[s1ave77]

was genau

Die Leute bekommen den Tipp SFC laufen zu lassen, ist mit DISM der Standardtipp .

Dann sehen sie: es wurden Fehler gefunden aber repariert. Das suggeriert; Windows hatte ein Problem, welches damit gelöst wurde. Stimmt ertmal positiv.

Ist aber in dem Fall nichts wert. Da war ncichts kaputt, gab also nichts zu reparieren.

Das Problem desjenigen ist nicht gelöst, soviel steht fest.

DER GLITCH: Windows Updates installiert, Update Bereinigung läuft durch ... Glitch ist da.

Der gezeigte Output läßt sich reproduzieren. Damit keine Synchronizität (im Volksmund Zufall genannt).

Ergänzung (14. Juli 2024)

UUPSI: Gerade festgestellt, wichtiger Teil fehlt :doh:. SFC meldet korrupten Komponentenspeicher beim Reparaturversuch, DISM repariert ihn ...

... dann muß natürlich nochmal SFC ran, um mit funktionalem Komponentenspeicher zu reparieren diesmal.

Wenn man sich von anderm ablenken läßt .

 

[chainr3action]

Sorry, aber so wie das im Eingangspost steht, ergibt das keinen Sinn. Du hast ja jetzt auch nochmal einen Nachtrag gepostet und den aber nicht oben editiert.

Dein erster Teil mit Glitch endet damit, dass du ein Log zeigst, dass Null Komponenten repariert wurden und dein Fazit ist dann "Weitergehen, es gibt nichts zu sehen"??

Entweder fehlt da die essezielle Information oder es gibt eben doch einen Fehler, den sfc scannow nicht reparieren kann und den man im CBS Log suchen muss.

Mein Windows 10 ist auch auf dem aktuellsten Stand und bei mir arbeitet sfc /scannow korrekt.

 

[s1ave77]

Dein erster Teil mit Glitch endet damit, dass du ein Log zeigst, dass Null Komponenten repariert wurden und dein Fazit ist dann "Weitergehen, es gibt nichts zu sehen"??

Endet. Er stellt aber vor dem Check klar, dass im Falle, das sieht so aus wie gezeigt, schonmal nichts repariert wurde.

Also gibt es nichts zu sehen. Ist wie in Fall 2 informativ, mehr nicht. Fehler wurden repariert oder es gab keine, selbes Ergebnis.

Erst, wenn Fehler nicht repariert werden können, sollte man handeln.

Letztlich geht es darum festzustellen, ob ein Problem vorlag und repariert wurde oder der Glitch. Egal was SFC erzählt. Den hatten auch andere. Muß dich nicht immer betreffen. Geniesse es .

 

[Restart001]

"What he says!?" rofl

 

[s1ave77]

Ist in Ordnung, muß nicht jeder verstehen.

Sammelt den Glitch und DISM Repair, letzterer kann durchaus helfen, geht aber am besten mit den Original-Win-Dateien aus der WIM/ESD (richtiger Patchstand vorrausgesetzt).

Damit ich sowas nicht jedesmal erneut posten muß, laß es hier so offen rumliegen und füge notfall anderes hinzu .

Da reicht dann der Verweis hierher, bin auch manchmal faul.

 

[Opa Hermie]

Was ist denn Glitch? Wahrscheinlich bin ich zu alt und verstehe nur den deutschen Begriff.

Meine Erfahrung bei Problemen: sfc /scannow sowie /RestoreHealth sind in den seltensten Fällen zielführend; nur ellenlange Log-Dateien, aus denen kaum klare Informationen hervorgehen.
Selbst der Verweis bei /RestoreHealth auf den Windows-Ordner eines "baugleichen", aktuellen und funktionierenden Rechners (kann man kopieren oder per Netzwerk machen) funktioniert anscheinend nur im Labor.

Etwas höhere Reparaturchancen hat man mit der Inplace-Reparatur und muss sich nicht mit der Konsole abstottern.

 

[BFF]

Hier nur fuer Dich. @Opa Hermie

https://www.netzwelt.de/abkuerzung/180480-bedeutet-glitch-bedeutung-verwendung.html

 

[s1ave77]

sind in den seltensten Fällen zielführend;

Nicht so ganz. Kommt darauf an, was kaputt ist. Kaputter Komponentenspeicher kann Update-Probleme auslösen.

Ist nicht die einzige Ursache, daher kein Allheilmittel.

Bevor ich aber ein In-Place-Upgrade starte, lasse ich das doch mal laufen. Mit Gück, kann ich mir den Rest schenken. Viel verloren habe ich ansonsten auch nicht.

Selbst der Verweis bei /RestoreHealth auf den Windows-Ordner eines "baugleichen", aktuellen und funktionierenden Rechners (kann man kopieren oder per Netzwerk machen) funktioniert anscheinend nur im Labor.

Ist komplizierter. Ich habs oben gezeigt. Das mit der WIM/ESD funktioniert. Version und Patchstand müssen stimmen, sonst kann das nichts werden.

Man kann auch eine gemountete WIM nutzen. Ist aufwändig.

ESDs kann man nicht mounten, die müssen erst zur WIM entpackt werden. Das kostet richtig Leistung (12C/24T auf 100%) mit entsprechend RAM-Konsum.

Ergänzung (14. Juli 2024)

Übrigends: Mit dem Windows-Ordner ist kein laufendes Windows gemeint in dem Fall. Entweder als WIM/ESD, sind ja gepackte Windows-Ordner, oder die Entpackte Form als direkter Mount per DISM.

Sonst geht das nicht. Das ist mißverständlich von MS, wie so oft. Man muß auf die Details schauen, die versteckt sind .