10 chkdsk von Windows 10 20H2 killt Dateisystem

[Nero24]

Hallo zusammen,

ich war heute in einer von mir betreuten Schule und habe einen Schulungsraum, der "festgezurrt" ist und sich daher nicht automatisch aktualisieren kann, manuell auf den neuesten Stand gebracht. Update auf Windows 10 20H2, Kumulative Updates, Office-Updates, Firefox-Update usw. Routine alle paar Monate. Hat auch alles reibungslos geklappt. Am Ende kriegen die Systeme immer noch ein "chkdsk c: /f" mit auf den Weg. Sie fahren dann runter, machen die Dateisystemprüfung und fahren anschließend wieder hoch. NORMALERWEISE.

Schon die letzte Windows-10-Version 2004 verhielt sich hier komisch, denn die Systeme blieben beim Filesystemcheck bei 100% stehen. Die PCs mussten manuell neu gestartet werden. Bei 20H2 ist das nun nicht mehr der Fall, allerdings weiß ich nicht, ob mir das Ergebnis besser gefälllt!





Die Systeme konnten nach dem chkdsk nicht mehr booten, stürzten mit einem BSOD mit der Meldung NTFS FILE SYSTEM ab. Zum Glück hab ich nicht gleich alle PCs auf einmal in den Reboot geschickt, so konnte ich das Maleur nach 7 PCs abbrechen.

Ich hing die SSD als Nicht-Bootlaufwerk in einen funktionierenden PC um zu sehen, was mit der Partition passiert ist. Das System erkennt sie nicht mehr als NTFS, sondern nur noch als RAW!


Ein chkdsk e: /f fand auf allen SSDs die identischen Fehler, einen haufen Fehler bei einer ominösen Datei 9 und ein Fehler im Attribut BITMAP der Master File Table:




Wieder zurückgebaut in das System bootet Windows wieder. Jetzt ist die Frage nach dem WARUM?! Es sind alles Kaveri-Systeme mit ASUS A68HM-PLUS Mainboard und Kingston-SATA-SSD, die im AHCI-Modus mit dem Windows-Standard-AHCI-Treiber laufen. Zuerst hatte ich ein fehlerhaftes TRIM-Verhalten in Kombination mit chkdsk und dem Umstand, dass das System nach Fertigstellung sofort rebootet, in Verdacht. Aber es sind nicht identische SSDs. Die meisten sind Kingston A400 mit Phison S11 Controller und 2D-TLC-NANDs, aber es war auch eine Kingston V300 mit Sandforce-Controller und MLC-NANDs dabei, die sicherlich ein völlig anderes TRIM-Verhalten hat wie die Phison-befeuerten.

Ich hab aktuell leider kein "Müll-System" herumstehen, wo ich das mal eben probieren könnte, ob der chkdsk-Vorgang eines Bootlaufwerks bei Windows 10 20H2 generell verbuggt ist oder ob da irgendwas zusammenspielt. Daher vorerst nur als Warnung gedacht. Ich muss morgen dasselbe Spielchen auf Laptops machen, einmal mit Beema und SATA-SSDs, einmal mit Kaby-Lake und NVMe-PCIe-SSDs. Dann sehe ich ja gleich ob die sich genauso verhalten oder nicht.

Nachtrag 1:
Es scheint wohl kein Hardware-Problem, da es auch in VMs auftreten kann.
https://forum.planet3dnow.de/index....10-20h2-killt-dateisystem.439733/post-5315867

Nachtrag 2:
Die ersten Community-Mitglieder können das Problem nachstellen:
https://forum.planet3dnow.de/index....10-20h2-killt-dateisystem.439733/post-5315946
https://forum.planet3dnow.de/index....10-20h2-killt-dateisystem.439733/post-5315964

Nachtrag 3:
Mit der Community zusammen versuchen wir zu ergründen, welche gemeinsame Eigenschaft das Problem auslöst, denn nur das betreffende Windows-Build kann es ja nicht sein. Allerdings ist es schwer da ein Muster zu erkennen.

OK 12x Lenovo B50 mit AMD A6-6310, Sandisk Z400s SATA-SSD, MBR/BIOS, Nero24
OK 1x ASUS Prime H410M-D mit Intel Core i3-10100F, Kingston A2000 M.2-PCIe-SSD, GPT/UEFI, Nero24
OK 1x MSI A320M-A Max Pro mit AMD Ryzen 3 2200G, Crucial BX500 SATA-SSD, MBR/BIOS, Nero24
OK 1x Gigabyte A75M-UD2H mit AMD A8-3870K, LiteOn SATA-SSD, MBR/BIOS (clean install 20H2), Shinsaja
OK 1x HP Elitebook 8460p, Core i5-2520M, Crucial MX300 275 GB 2,5" SATA, MBR/BIOS, Sje8607
OK 1x VMWare Workstation 15.1.0 (13591040) auf GA880-UD3H V2.1 mit Athlon II X4 640, VM auf HDD, MBR/BIOS, RPU
OK 1x VMWare Workstation 15.1.0 (13591040) auf GA880-UD3H V2.1 mit Athlon II X4 640, VM auf HDD, GPT/UEFI, RPU
OK 1x ASUS B450M-A mit AMD Ryzen 7 1700, Sandisk PRO SATA-SSD, GPT/UEFI, eratte
OK 9x Lenovo Flex 2-15D mit AMD A6-6310, Kingston A400 SATA-SSD, GPT/UEFI, Nero24

KO 6x ASUS A68HM-PLUS mit AMD A8-7600, Kingston A400 SATA-SSD, MBR/BIOS, Nero24
KO 1x ASUS A68HM-PLUS mit AMD A8-7600, Kingston V300 SATA-SSD, MBR/BIOS, Nero24
KO 2x Lenovo V110 mit Intel Core i3-6006U, Intel 540s M.2-SATA-SSD, MBR/BIOS, Nero24
KO 1x Lenovo V110 mit Intel Core i3-6006U, Samsung PM881 M.2-SATA-SSD, MBR/BIOS, Nero24
KO 1x VirtualBox-VM mit AMD Ryzen 7 2700, VDI auf Toshiba-HDD, MBR/BIOS, Nero24
KO 1x VirtualBox-VM mit AMD Ryzen 7 2700, VDI auf Toshiba-HDD, GPT/UEFI, Nero24
KO 1x ASUS ROG STRIX Z49-E mit Intel i9-10900KF, Samsung 970 Evo Plus M.2-PCIe-SSD, GPT/UEFI, Orbiter
KO 1x ASUS Strix B350-I mit AMD Ryzen 5 3600, Samsung 960 Evo M.2-PCIe-SSD, GPT/UEFI, eratte
KO 4x Lenovo Flex 2-15D mit AMD A6-6310, Kingston A400 SATA-SSD, GPT/UEFI, Nero24
KO 1x Lenovo V320 mit Intel Pentium Gold 4415U, Intel 545s M.2-SATA-SSD, MBR/BIOS, Nero24

Nachtrag 4:
Microsoft hat den Bug unerwartet schnell gefixt. Eine Bestätigung in freier Wildbahn steht allerdings noch aus.

 

[HITCHER]

Beim letzten Sicherheitsupdate hatte ich am Notebook mit A8-6410 auch Probleme, es ist nicht mehr gestartet und mit blauem Bildschirm hängen geblieben. Nach einer automatischen Startreparatur hat es aber doch wieder funktioniert, also habe ich es nicht weiter untersucht.
Ist aber noch Windows 19.09 drauf.

 

[eratte]

Ich mache nachher mal ein Image an einem Rechner und probiere es dann aus.

Doppelposting wurde automatisch zusammengeführt: 18.12.2020

So System mit 3900X/X470, 32 GB RAM, MX200 500 GB mit Windows 20H2, chkdsk c: /f ist nach reboot ohne Fehler durch gelaufen und Windows ganz normal wieder gestartet.

 

[Nero24]

Hab's eben in einer virtuellen Maschine auf meinem Arbeits-PC probiert!



Es hat also nichts mit der Hardware der Schulungs-PCs zu tun, auch nicht mit der SSD oder TRIM, weil meine VM auf einer HDD läuft. Es ist ein ganz übler Bug in der chkdsk-Version von Windows 10 20H2.

Ich werde das mal an Microsoft melden und gleich noch eine News dazu schreiben.

Vorsicht Datensalat: chkdsk c: /f auf Windows 10 20H2 beschädigt Dateisystem - Planet 3DNow!

Auf Planet 3DNow! gibt es alle wichtigen Informationen für AMD-User: News, Downloads, Support, Tests

www.planet3dnow.de

 

[gruenmuckel]

Wie geil! P3D deckt mal wieder einen Riesen-Bug auf. Duckt euch, der Ansturm kommt.

 

[eratte]

Die Frage ist für mich warum ist es bei mir nicht passiert?

 

[Nero24]

Die Frage ist für mich warum ist es bei mir nicht passiert?

Das ist eine gute Frage, denn sogar in der frisch installierten VM war es auf Anhieb reproduzierbar. Hattest Du den Befehl in der Admin-Konsole mit dem Parameter /f gestartet und mit J bestätigt vor dem Reboot?

Ist das System, auf dem Du getestet hast, ein UEFI-System mit GPT oder ein Legacy-System mit MBR? Bei mir letzteres.

 

[eratte]

Ja Eingabeaufforderung mit Adminrechten und nach Eingabe chkdsk c: /f mit j bestätigt

UEFI-System mit GPT

 

[Nero24]

Ok, ich werde das mal gegentesten. Bei mir sind alle Systeme, bei denen das aufgetreten ist, Non-UEFI-Installation auf einem MBR-Datenträger und auch VirtualBox verwendet ja den Legacy-Mode wenn man es nicht explizit anders einstellt.

 

[GrenSo]

Welche genaue Build hat des das betreffende Win10 20H2?

 

[Nero24]

Welche genaue Build hat des das betreffende Win10 20H2?

Gut, dass Du fragst. Ich habe eben nochmal eine neue VM aufgesetzt und ihr bei der Installation das Netzwerk abgedreht, damit Windows sich keine Updates laden kann. Das System hat mit der mir vorliegenden ISO das Build 19042.572. In diesem Zustand ist der Fehler nicht aufgetreten!


Anschließend habe ich das Netzwerk wieder verbunden und das Windows-Update alle Patches bis zum heutigen Tag laden lassen und neu gestartet. Nun hat das System das Build 19042.685

Nun abermals chkdsk c: /f laufen lassen und Zack: BSOD

Ich werde den Test jetzt noch einmal mit einer UEFI-Installation wiederholen.

 

[GrenSo]

Danke für die Info.
Wenn ich am Wochenende die Zeit finde, werde ich es ggf. auch mal bei mir in der VM versuchen zu reproduzieren.

 

[Nero24]

Ok, hab's grad in einer UEFI-VM probiert. Auch im UEFI-Modus auf einem GPT-Datenträger tritt der BSOD nach chkdsk c: /f auf. Es scheint also das aktuelle Build 19042.685 bzw. das kumulative Update 2020-12 das Problem zu sein. Kann natürlich sein, dass es bereits mit 2020-11 oder 2020-10 eingeführt wurde. Das mag ich aber jetzt nicht auch noch testen.

Ich kann daher nur wiederholen: Obacht mit dem Befehl derzeit!

 

[gruenmuckel]

Da P3D vielleicht nicht mehr ganz die Reich weite von vor 20 Jahren hat, es aber wirklich freundlich wäre, wenn diese Information publik würde könnte man das ja an ein paar Webseiten streuen? https://www.borncity.com/blog/ hat mir schon öfter bei kniffligen Problemen weitergeholfen. Eventuell könnte man das dort mal lancieren?

 

[Jackpot]

Ich habe die selbe Windows 10 UEFI Version und den Updatestand auf einer SSD und habe das mit "chkdsk c: /f" getestet. Es lief einwandfrei durch und Windows startet einwandfrei.

Kannst du das mal auf einem Intel System ausprobieren?

 

[Nero24]

Kannst du das mal auf einem Intel System ausprobieren?

Hier nicht, aber heute im Laufe des Tages werde ich den nächsten Schwung an Systemen aktualisieren. Da sind dann auch ein paar Kaby-Lake-Laptops dabei. Bei einem werde ich es wagen

 

[ghostadmin]

Also bei mir ist bei 2004 nichts hängengeblieben, hab aber beim Reboot nicht drauf geachtet ob das auch tatsächlich gelaufen ist.

 

[eratte]

winver von dem Rechner:

 

[Nero24]

Dann scheint da noch mehr mit reinzuspielen als nur die OS-Version. Ich frag mich aber welcher gemeinsame Auslöser das sein könnte. 6 der Systeme in der Schule waren wie gesagt Kaveri-Systeme (AMD A8-7600) mit ASUS A68HM-PLUS Mainboard und Kingston A400 SSD (Phison-Controller), eines war mit Kingston V300 SSD (Sandforce-Controller) und mein Arbeits-PC im Büro, auf dem ich die VM-Tests gemacht habe, ist ein AMD Ryzen 7 2700 auf einem ASUS Prime B350-PLUS mit Samsung 970 Evo SSD, wobei die VirtualBox-VDIs auf einer mechanischen Festplatte liegen, also nicht nur eine völlig andere Plattform, sondern auch eine andere Architektur

 

[eratte]

Ich probiere es gleich noch mal an 2 anderen Rechnern - mit einem Image ist das gefahrlos kostet höchstens etwas Zeit.

 

[Nero24]

Super Vielleicht magst Du es dann auch mal mit einer Legacy-Installation probieren? Ich hab zwar UEFI in der VM getestet und da ist es auch aufgetreten, aber der VM-Host ist ein Legacy-Gerät. Nur als Gegentest

 

[Shinsaja]

Ich habs grad aufm meinem FM1 System mit aktuellem Build probiert. Dort liefs Fehlerfrei durch. Is ne Legacy Install

 

[ghostadmin]

Vielleicht liegt es an einem bestimmten Virenscanner.
Wo ich mal Probleme mit chkdsk hatte, war bei einem korrupten Dateisystem. Das war danach komplett hinüber.

 

[Nero24]

Vielleicht liegt es an einem bestimmten Virenscanner.

Bei den Rechnern in der Schule wäre das ein Ansatzpunkt, denn dort ist G-DATA Antivirus Business drauf. In den VMs dagegen war nur der Windows Defender drauf, sonst gar nichts weiter

Hab grad mal einen Bekannten gebeten, den Test auf einem Intel Core i3-10100F-System zu machen. Ist eine UEFI-Installation und ebenfalls Build 19042.685. Dort ist chkdsk c: /f fehlerfrei durchgelaufen. Mal sehen was meine Updates auf den Laptops heute so bringen

 

[ghostadmin]

Hatte hier unter Vmware auch keine Probleme mit dem 685 Build. Ist Legacy MBR.