Wie fast alle Befehle in der Konsole geht das mit "Strg+C". Eventuell mehrmals drücken. Die Ausführung wird dann abgebrochen.

Aber habe es auch noch einmal in der VM getestet: Nach Neustart läuft sfc wie gewohnt schnell durch. Ohne Neustart dauert das ja Ewigkeiten.

Ich kann bestätigen, dass wenn nach der Datenträgerbereinigung zuerst ein Neustart durchgeführt wird, sowohl DISM als auch SFC fehlerfrei und schnell durchlaufen.
Kannst Du mir bitte sagen, wie mit welchem Befehl Du sfc /scannow abgebrochen hast. Ich habe dazu im Netz nichts konkretes gefunden.

sfc /scannow hatte ich auch gestartet. Es lief quälend langsam und hätte sicherlich Stunden gedauert. Habe es dann abgebrochen und den PC mit "shutdown -g -t 0 " neu gestartet. Danach sfc /scannow erneut ausgeführt und innerhalb von wenigen Minuten war alles gelaufen.
Warum dies alles so seltsam ist kann ich nicht sagen. MS das unbekannte Wesen.

Das kann auch am KB4592438 gelegen haben, zumal der Fehler mit SFC trat auch direkt nach einer Neuinstallation auf, ohne das jemals die Update-Bereinigung ausgeführt wurde. Und da nichts verwertbares in der CBS.log stand, keine Ahnung, warum und wieso. Aber mit KB4598242 scheint alles in Ordnung zu sein.

Was die Laufzeit von SFC angeht, der erste Lauf nach Installation von KB4598242 mit anschließender Update-Bereinigung dauerte ungewöhnlich lange. Der zweite Lauf ging wieder wie gewohnt schnell. Aber beides mal ohne Vorkommnisses beendet.

Update 12.01.
Nach Installation des KB4598242 auf die Build 19041.746 zeigte die Datenträgerbereinigung erneut einen großen Bereinigungsbedarf von
> 4 GB bei den Windows-Updates.

Im Gegensatz zum Dezember Patchday meldeten nach der Datenträgerbereinigung weder Dism /Online /Cleanup-Image /ScanHealth
noch sfc /scannow Komponentenbeschädigungen bzw. Integritätsverletzungen. Auffällig war jedoch die Länge der sfc Prüfung mit > 2,5 Stunden.

Es scheint so, als ob der von mir gemeldete Fehler in der Datenträgerbereinigung am heutigen Patchday korregiert wurde.

Gibt es jemand hier im Forum, der die Thematik im Microsoft TechForum plazieren kann?

Ist bloß die Frage, warum sie das macht und warum nicht bei allen? Auf dem Tablet und Laptop ist Windows 2004 (19041.1) seit Dezember 2019 installiert und seit dem alle Updates problemlos installiert bekommen und ebenfalls immer Update-Bereinigung ausgeführt. Das mit [i]sfc[/i] ist jetzt die erste Unstimmigkeit, die ich überall feststelle, also Hardware und VM. Aber habe da echt keine Ahnung, was der Grund ist, dass da bei einigen Installationen Sachen verschwinden und man dadurch die Fehler 0x800f0988 bzw. 0x800f081f bekommt.

Von daher habe ich zwar die Update-Bereinigung in Verdacht, egal ob automatisch bei der Installation eines Updates, klassische Datenträgerbereinigung, Einstellungen/System/Speicher oder DISM. Irgendwo klemmt da etwas. Aber reproduzieren konnte ich es bislang nicht.

ich werde auch vorerst keine Datenträgerbereinigung mehr laufen lassen. Nach der letzten Bereinigung musste ich wieder auf 2 Maschinen das Skript von Ben in Anspruch nehmen. Danach habe ich keine Bereinigung mehr durchgeführt. Das hier angesprochene Kumulative Update ist nun auf all meinen 5 Geräten anstandslos installiert worden. Für mich steht fest, das die Datenträgerbereinigung Daten löscht, die sie nicht löschen sollte.

Ja, kann da aber auch im Moment nicht wirklich beurteilen, ob das zu einem Problem beim nächsten Update wird. Beim 2. Lauf von sfc ist ja alles in Ordnung und dism mit RestoreHealth sagt auch, dass alles in Ordnung ist, also belasse ich es erst einmal dabei. Das nächste kumulative Update kommt ja regulär erst im Januar. Also solange muss ich mich da jetzt gedulden.

Danke für die Info. Ich habe für mich entschieden, die Datenträgerbereinigung im Moment nicht mehr zu verwenden, auch wenn
sfc /scannow anscheinend keine Fehler korrigiert. Warten wir mal ab, ob Microsoft dieses Verhalten offiziell als "Problem" deklariert.

Scheint aber auch aufzutreten, wenn nur KB4592438 installiert ist und die Bereinigung ausgeführt wurde. Hatte das mit einer ISO mit der 19042.685 getestet (Ohne .Net Update, bereinigt) und direkt nach der Neuinstallation was der Fehler schon da.

Konnte also doch an der Bereinigung liegen oder an irgendetwas anderem.

Vielen Dank für's Nachprüfen!

Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und erfolgreich repariert.
Bei Onlinereparaturen finden Sie Details in der CBS-Protokolldatei unter
windir\Logs\CBS\CBS.log. Beispiel C:\Windows\Logs\CBS\CBS.log. Bei Offlinereparaturen
finden Sie Details in der durch das /OFFLOGFILE-Kennzeichen angegebenen Protokolldatei.

Das müsste ich morgen testen. Muss dazu auch erst das Backup der VM zurückspielen.

Aber schon seltsam das Verhalten, vor allem, weil in der Log nichts steht, was repariert wurde. Da steht eigentlich, es wurde nichts repariert.

[hr][/hr]

Zwar nicht in der VM getestet, aber auf dem Tablet. Installiert war:

20H2 (19042.662), .Net Update 3.5 und 4.8 Preview (KB4586876) und Update-Bereinigung, KB4592438 noch nicht installiert.

Selbes Verhalten:

[code]Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und erfolgreich repariert.
Bei Onlinereparaturen finden Sie Details in der CBS-Protokolldatei unter
windir\Logs\CBS\CBS.log. Beispiel C:\Windows\Logs\CBS\CBS.log. Bei Offlinereparaturen
finden Sie Details in der durch das /OFFLOGFILE-Kennzeichen angegebenen Protokolldatei.[/code]

Könnte also wirklich am .Net Update liegen (KB4586876).

Erstmal Danke für die Infos. Dism /Online /Cleanup-Image /ScanHealth war bei mir ebenfalls fehlerfrei.

Habe gerade etwas mit einem älteren Backup getestet, da ich die Datenträgerbereinigung schon etwas länger nicht benutzt hatte.

Der Fehler tritt bei mir bereits nach dem Vorschau-Update (KB4586876) für .NET Framework 3.5 und 4.8 auf. Scheint also nicht Dezember Update (KB4592438) spezifisch zu sein!

Kannst Du das mal in der VM prüfen?

2020-12-08 21:14:30, Info                  CSI    000002bb [SR] Verify complete
2020-12-08 21:14:30, Info                  CSI    000002bc [SR] Repairing 0 components
2020-12-08 21:14:30, Info                  CSI    000002bd [SR] Beginning Verify and Repair transaction
2020-12-08 21:14:30, Info                  CSI    000002be [SR] Repair complete

sfc /scannow beginnt bei dem Eintrag in der Log:

[i]TiWorker: Client requests SFP repair object.[/i]

Aber da steht bei mir nicht aufschlussreiches drin.

[i]dism /online /Cleanup-Image /RestoreHealth[/i] sagt, dass im Komponentenspeicher alles in Ordnung ist.

Lasse das gerade mal in der VM laufen. Mal schauen, ob das da auch so ist.

Das interessante ist ja auch der Abschluss von sfc /scannow:

[code]2020-12-08 21:14:30, Info CSI 000002bb [SR] Verify complete
2020-12-08 21:14:30, Info CSI 000002bc [SR] Repairing 0 components
2020-12-08 21:14:30, Info CSI 000002bd [SR] Beginning Verify and Repair transaction
2020-12-08 21:14:30, Info CSI 000002be [SR] Repair complete[/code]
Wurden 0 Komponenten repariert. Sehr verwirrend gerade.

OK. In der VM (Referenz-Installation) selbes Ergebnis. Wurden beschädigte Dateien repariert, aber erscheinen nicht im Log.
Zweiter Lauf von sfc, alles in Ordnung.