★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 23.008
- Renomée
- 8.830
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.
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.
Zuletzt bearbeitet:
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. 
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 
