[Update 16.Juli] Microsoft hat den Fehler nun bestätigt und darauf hingewiesen, dass er demnächst behoben wird. Solange kann man ihn durchaus ignorieren. Im Prinzip wurde nun das bestätigt, was auch wir und DK2000 in den Kommentaren schon festgestellt hatten.
„Die Dateien für das Windows Defender PowerShell-Modul, die sich in
%windir%\System32\WindowsPowerShell\v1.0\Modules\Defender
befinden, werden als Teil des Windows Images ausgeliefert. Diese Dateien sind katalogisiert. Die Verwaltungskomponente von Windows Defender verfügt jedoch über einen neuen Out-of-Band-Aktualisierungskanal. Dieser Kanal ersetzt die Originaldateien durch aktualisierte Versionen, die mit einem Microsoft-Zertifikat signiert werden, dem das Windows-Betriebssystem vertraut. Aufgrund dieser Änderung kennzeichnet SFC die aktualisierten Dateien als „Hashes for file member do not match“.
[Original 10.Juli] Gestern war Patchday für alle Windows Versionen. Bspw. die KB4507453 (1903) oder KB4507469 (1809) Es wurden Sicherheitslücken geschlossen, gerade auch durch die Service Stack Updates. Aber wie es aussieht funktioniert sfc /scannow nun nicht mehr.
Egal ob in der Windows 10 1809, Windows 10 1903 und auch im Slow Ring (18362.10000), welches gestern auch die KB4506991 (.Net Framework) erhalten hat. Die Überprüfung wird zwar mit 100% abgeschlossen, wie ich getestet hatte, aber beschädigte Dateien können teilweise nicht repariert werden.
Schaut man in die CBS.log Datei unter C:\Windows\Logs\CBS, dann erscheinen die Dateien als nicht Reparatur-fähig, die unter
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Defender
aufgelistet sind. Die Hashes der Dateien stimmen nicht mit denen aus dem winSxS Ordner überein. Wie DK2000 in den Kommentaren schreibt, Aus irgendwelchen Gründen erwartet sfc den Hash der Dateien aus dem 32bit Paket im 64bit Paket…geht das natürlich in die Hose und sfc macht nur genau das, was es soll. Die Hardlinks passen aber alle. 32bit und 64bit sind soweit korrekt mit den Dateien im WinSxS Ordner verlinkt, nur sfc erhält hier falsche Informationen und führt dadurch einen falschen Vergleich aus.
DK2000 hat dann noch weitergeforscht und seine Erkenntnisse in den Kommentaren hinterlassen. Wie sich auch herausstellt ist nicht nur Windows 10 sondern auch Windows 8.1 davon betroffen.
Man selber muss da nichts reparieren. Hier muss Microsoft mit dem nächsten Patchday den Fehler ausbessern. Wer keine Fehler im System soweit hat, braucht sfc /scannow auch nicht ausführen. Ansonsten bleiben solange noch die DISM-Befehle für einen Check. Wurden die DISM Befehle ausgeführt, sollte auch sfc /scannow wieder alles korrekt anzeigen.
Windows 10 Tutorials und Hilfe
In unserem Windows 10 Wiki findet ihr sehr viele hilfreiche Tipps und Tricks. Falls ihr Fragen habt, dann stellt diese ganz einfach bei uns im Forum.
- Installationsmedien: Aktuelle Installationsdateien findet ihr hier immer in der rechten Sidebar. Windows 10 1903 ISO (18362)
- Installation: Windows 10 Clean installieren, Win 10 1903 neu installieren, Win 10 1809 neu installieren
- Probleme bei der Installation: Windows 10 1809 Probleme bei der Installation, Win 10 1803 lässt sich nicht installieren
- Reparaturen: Inplace Upgrade Reparatur, Win 10 reparieren über DISM, sfc und weiteres, Windows Update reparieren, Startmenü reparieren, Apps reparieren, Store reparieren, Netzwerk reparieren
- Anmeldung: Win 10 automatische Anmeldung
- Entfernen, Deinstallieren: Cortana deaktivieren, Apps deinstallieren
- Datei Explorer: Ordner unter Dieser PC entfernen, Netzwerk, OneDrive u.a. im Explorer entfernen
- Richtige Nutzung: Startmenü richtig nutzen, Suche richtig nutzen,
- Wichtig: In jedem Tutorial steht, für welche Version es geeignet ist.
„Man selber muss da nichts reparieren. Hier muss Microsoft mit dem nächsten Patchday den Fehler ausbessern. Wer keine Fehler im System soweit hat, braucht sfc /scannow auch nicht ausführen. Ansonsten bleiben solange noch die DISM-Befehle für einen Check.“
Doch, ich hab die dism befehle ausgeführt.. bekomme nach einem scannow diese meldung -> http://imgbox.com/18cKskqX
Ist doch identisch die Meldung. Verstehe deinen Kommentar jetzt nicht
nein, der unterschied liegt darin, dass er die beschädigten dateien erfolgreich repariert hat.. in dem artikel hier, heißt es „teilweise“
Ahh ok. Hatte ich übersehen im Bild.
Nach Rep. mit den 3 Dism-Befehlen „Dism /Online /Cleanup-Image /CheckHealth “ – „Dism /Online /Cleanup-Image /ScanHealth “ – „Dism /Online /Cleanup-Image /ScanHealth “
waren die Fehler beseitigt.
MS gibt zum Beispiel folgendes vor, bevor man den Befehl sfc/scannow
—
Wenn Sie Windows 10, Windows 8.1 oder Windows 8 ausführen, führen Sie zuerst das Tool zur Abbildverwaltung für die Bereitstellung (DISM) des Posteingangs aus, bevor Sie die Systemdateiprüfung ausführen.
Geben Sie den folgenden Befehl ein und drücken Sie dann die Eingabetaste.
Es kann mehrere Minuten dauern, bis der Befehl abgeschlossen ist.
DISM.exe /Online /Cleanup-image /Restorehealth
Wichtig: Wenn Sie diesen Befehl ausführen, stellt DISM unter Verwendung von Windows Update die Dateien bereit, die zur Behebung der Beschädigungen erforderlich sind.
Habe gerade bei meiner modifizierten W10 Enterprise 18362.239 mal sfc/scannow durchlaufen lassen.
Da war alles gut. Doch hab ich den Store, den Defender, etc da auch rausgeschmissen.
Hatte bei euch mal über das ToolkitV_9.3.1 gelesen. Gut zum Anpassen muss ich den Kaspersky deaktivieren,
aber das Programm läuft sehr gut und bisher hat sich die angepasste Enterprise Version immer brav via Neuinstallation oder Inplace-Upgrade installieren lassen! Gab auch anschließend nie Virenfunde
Danke nochmal an dieser Stelle für den Tipp – ohne euch wäre ich auf dies nützliche Programm so schnell
nicht gekommen!
Update KB4506991 KB4507453 KB890830 v. 10.7.19, nach Aufstarten Hänger
nach Aufstarten Hänger, rollende Punkte auf schwarzem Bildschirm, System mit Boot USB Wiederherstellungspunkt gerettet, Update ausgesetzt
Hat jemand ähnliche Probleme ? Lösung ev. ? Vielen Dank!
Vorab gem. Microsoft Support DISM.exe /Online /Cleanup-image /Restorehealth und sfc /scannow, ausgeführt, ohne Erfolg, auch nach Installation neuestem Grafik Treiber Nvidia
gepostet mit der Deskmodder.de-App
Vor dem Update in der Msconfig alle Dienste die nicht von Windows sind Deaktivieren, dann Updaten und danach restliche nicht Windows Dienste wieder einschalten.
Die Dateien sind alle einwandfrei. Beschädigt ist da nichts. und sfc /scannow arbeitet auch zu 100% sauber.
Problem ist, dass hier jemand 32bit und 64bit verwechselt hat. Aus irgendwelchen Gründen erwartet sfc den Hash der Dateien aus dem 32bit Paket im 64bit Paket:
Expected: {l:32 ml:33 b: 32bit Hash aus x86_windows-defender-management-powershell}.
Actual: {l:32 b: 64bit Hash aus amd64_windows-defender-management-powershell}.
Expected und Actual müsste aber jeweils 64bit sein. Da sich die Dateien unterscheiden (64bit sind signiert), geht das natürlich in die Hose und sfc macht nur genau das, was es soll.
Die Hardlinks passen aber alle. 32bit und 64bit sind soweit korrekt mit den Dateien im WinSxS Ordner verlinkt, nur sfc erhält hier falsche Informationen und führt dadurch einen falschen Vergleich aus. Vermutlich passt da ein Katalog nicht. Jedenfalls sind die Pakete und somit die Hashes durcheinander gekommen.
Hab ich oben zum Teil mal hinzugefügt.
Danke DK
Hallo Deskmodder, hätte ich das gestern schon gelesen hätte ich mir ein Haufen arbeit erspart. Ich habe gestern bei meinem PC und dem Laptop meiner Frau alle Updates gezogen und alles auf den neusten Stand gebracht. Dann hab ich bei meinem PC Sfc /scannow laufen lassen, alles ok. Beim Laptop meiner Frau dasselbe, aber da kam dann „Beschädigte Dateien gefunden, die nicht repariert werden können”. Ich hab dann das ganze noch mal laufen lassen und wieder dasselbe. Nach dem ich einiges (Media Creation Tool, Windows 10 USB Stick) probiert habe, hat letztendlich PowerShell mit diesen Eingaben nacheinander „Repair-WindowsImage -Online -CheckHealth“
„Repair-WindowsImage -Online -ScanHealth“ „Repair-WindowsImage -Online -RestoreHealth“ geholfen. Dann nochmal Sfc /scannow laufen lassen und beschädigte Dateien konnten repariert werden. Nun ratet mal woher ich das mit PowerShell habe, richtig von Deskmodder. Vielen Dank dafür, Ihr seit die Besten. Grüsse Hans-Dieter
Das war bei mir auf zwei Windosen genau so
Bei mir Behebung durch ausführen von „Dism /Online /Cleanup-Image /RestoreHealth“ (Auch wenn die Anzeige 100% anzeigt Warten! Bei mir waren es ca. 10 Min. Erst wenn das Prompt Zeichen angezeigt wird ist der Vorgang beendet) und danach „sfc /scannow“. Nur „sfc /scannow“ reichte bei mir nicht aus. Das Ganze habe ich als Antwort schon im Artikel zum Update weiter unten heute Beschrieben
Die Sache mit RestoreHealth scheint hier ganz böse zu sein, da jetzt alles durcheinander ist. scf ist zwar befriedigt, aber jetzt sind die falschen Dateien im Komponentenspeicher.
RestoreHealth hat hier nichts anderes gemacht, als die signierten Dateien aus dem Paket amd64_windows-defender-management-powershell zu löschen und durch die unsignierten Dateien aus dem Paket x86_windows-defender-management-powershell zu ersetzen. Das befriedigt zwar jetzt sfc, da es im 64bit Paket die Dateien aus dem 32bit Paket vorfindet, aber glaube nicht, dass das so gewollt ist.
Das ist sehr suspekt. Aber wenn es da Probleme mit den Katalogen gibt, kann RestoreHealth auch fehlerhaft reparieren, da es dann genauso wie sfc falsche Informationen hat.
Die neuen Dateien kommen im Übrigen aus diesem Update:
https://support.microsoft.com/en-us/help/4052623/update-for-windows-defender-antimalware-platform
Dort sind die signierten Scripte enthalten.
Nocheinmal getestet und es liegt definitiv an KB4052623 (Version 4.18.1906.3):
Ausschließlich besagtes KB4052623 in die 18632.207 installiert und das hier beschriebene Problem mit den „hash mismatch“ ist dann auch in der 18362.207 vorhanden. Davor war es nicht da.
Ist vermutlich niemandem aufgefallen, da einen Tag später gleich das LCU und .NET Update kam.
Und auch wenn man jetzt hier RestoreHealth ausführt, wird KB4052623 teilweise rückgängig gemacht. Aber wir auch immer. Irgendwelche Auswirkungen scheint das keine zu haben.
Jetzt verstehe ich auch, was da schief gelaufen ist:
Es geht nicht darum, dass 32bit mit 64bit verwechselt wurde, sondern dass KB4052623 am Komponentenspeicher vorbei die Dateien im 64bit Paket direkt aktualisiert, ohne Katalog und ohne Bescheid zu sagen. Der Komponentenspeicher weiß überhaupt nichts von den neuen Dateien und geht noch von den alten Dateien aus. Daher erwartet sfc hier ebenfalls die alten Dateien, genauso wie DISM mit RetoreHelath.
Das ist äußerst unsauber, wie KB4052623 das Update ausführt.
Ist das sfc /scannow das neue defrag für den Zeitvertreib oder habt ihr tatsächlich alle am laufenden Band Probleme mit euren Windows 10 Installationen?
Ich habe sfc /scannow mal vor Ewigkeiten genutzt als es nötig war, da war es schon so, dass es den Hinweis auf „teilweise“ gab.
Wenn man die richtige Reihenfolge einhält und die Vorbereitungen ausführt passt das schon, muss aber nicht zwangsläufig helfen.
Windows ist eingefroren und ich musste einen Hardreset durchführen.
Nach solchen Vorfällen läuft anschließend bei mir immer SFC durch, um Fehler auszuschließen.
Da ein User bereits von einen nach dem Update abgestürzten PC berichtet, ist die Sache wohl keine Lappalie. Microsoft ist aufgefordert den Fehler schleunigst zu beheben. Letztendlich frage ich mich ein weiteres Mal, warum es inzwischen bei fast jeden Update Ärger gibt und warum Microsoft aus seinen Fehlern anscheinend nix bis gar nix lernt…. ☹️???
gepostet mit der Deskmodder.de-App für Android
Ich habe das Problem dass ich seit dem update „EINSTELLUNGEN > SYSTEM“ nicht mehr öffnen kann!
Die anderen Einstellungen schon.
Schon mit Rechtsklick auf Startbutton = Kontexmenü EINSTELLUNGEN und abschließend Neustart probiert?
gepostet mit der Deskmodder.de-App für Android
Danke. Das kommt leider aufs gleiche raus. Das Fenster öffnet sich kaum sichtbar und verschwindet dann wieder. Wie gesagt, nur bei >SYSTEM.
Das Problem ist nicht Windows 10 Exclusiv – Auch Windows 8.1 ist davon betroffen – Alle meine 5 8.1 Maschinen zeigen exakt das gleiche Fehlerbild. Herrlich, dieses „Nadella“ Quality Management
Ja, das betrifft alle Systeme mit Powershell und Defender, auf denen sich KB4052623 (Version 4.18.1906.3) installieren lässt.
also nach dism restorehealth scheint sfc wieder ok
hat beschädigte Dateien gefunden und erfolgreich repariert
Nur das keine beschädigten Dateien repariert wurden, da gar keine beschädigten Dateien vorhanden waren. Es wurden jetzt nur neue Dateien durch alte Dateien ersetzt, weil der Komponentenspeicher von den durch KB4052623 aktualisierten Dateien nichts wusste.
Soll heißen, wenn ich jetzt alle meine 8.1 Systeme mit DISM „kaputt“ repariert habe, KB4052623 am besten de.- und Neuinstallieren und dann auf einen offiziellen fix von MS warten, trotz kaputter SFC? Wenn DISM neue, gegen alte Dateien ersetzt, kann es ja in Zukunft erst recht zu Problemen kommen, nehme ich an …. oh weh
In dem Falle hier geht es nur um eine Handvoll Cmdlets für die Powershell. Das ist hier halb so wild. Hier kann man auch die alten Dateien behalten, die sind dann halt nicht signiert.
Das Problem ist halt, dass KB4052623 am Komponentenspeicher vorbei die Dateien aktualisiert hat. Weder DISM noch sfc haben Kenntnis von den neuen Dateien, erwarten also noch die alten Dateien und betrachten dadurch die neuen Dateien als „Beschädigt“, was sie aber nicht sind.
Das ist jetzt so schon lange nicht mehr vorgekommen. Bislang haben sich die Updates an die wichtige Regel gehalten, dass nur der TrustedInstaller (über das CBS) Dateien im Komponentenspeicher in Form von Paketen mit gültigen Katalogen aktualisieren darf. Hätte KB4052623 ebenfalls das Paket mit den Dateien als ganzes aktualisiert (mit gültigem Katalog) und nicht nur die Dateien im vorhandenen Paket überschrieben, wäre alles in Ordnung. Die neuen Dateien wären dann bekannt und sfc und DISM sähen diese dann auch als in Ordnung an.
Ok danke, na dann bin ich ja ein wenig beruhigt
Hatte nämlich gerade heute mein Backup erneuert, NACH der DISM rep haha.
Beim Nicht – Defender – Gerät wurden keine Fehler bei Dism … und sfc /scannow angezeigt.
Wäre das dann folgerichtig?
Bei den Defender – Geräten wurde „repariert“ bzw. kaputtrepariert.
Es ist schwer vorstellbar, selbst wenn vor Update – Freigabe nur ganz wenige Geräte für Grundsätzliches getestet werden, dass so etwa nicht auffällt.
Rückfrage, nach der neuesten Meldung: Kann ich im „Ernstfall“ den System File Scanner durchlaufen lassen, ohne dass es negative Folgen für System32 hat?
Ja, da es bei diesem Problem nur die Dateien in dem o.g. Verzeichnis betrifft, da diese fälschlicher Weise mangels Katalog als beschädigt angesehen werden.
Danke@DK2000!?
Freut michzu lesen das der von mir entdeckte, und am 10. 07. 2019 um ca. 14:00 h, auch hier gepostete Fehler bei sfc /scannow, nun offiziell von Microsoft zur Kenntnis genommen wurde…..
Zur Info auf einen neu Clean Install Win 10 64 bit Ver.356 neuster Stand, besteht auch wieder das problem .
Lustiges System ,hab es Aufgegeben zu Suchen kostet nur meine Lebenszeit die ist mir zu Wertvoll um in das Zeugs
Windows zu Investieren.
Traurig das die NIX gebacken bekommen von MS na mal schauen in der neuen version die malnächstes Jahr kommt .
Schönen Tag noch..
dism /online /cleanup-image /restorehealth
sfc /scannow
Dann passt es wieder.