10 chkdsk von Windows 10 20H2 killt Dateisystem

VMWare Workstation 15.1.0 (13591040) auf GA880-UD3H V2.1, Athlon 640, Host OS: Win10Pro 20H2 19042.685
OK Win10Pro 20H2 19042.685 auf , VM auf HDD, VM HDD ist MBR, BIOS
OK Win10Pro 20H2 19042.685 auf , VM auf HDD, VM HDD ist GPT, UEFI (der gleiche Guest nur mit UEFI (ohne Secure Boot) und GPT Datenträger
 
Zuletzt bearbeitet:
sharptooth schrieb:
Passiert das nur bei der Bootpartition? Ich prüfe nämlich ab und an meine externe Backup HDD mit chkdsk Laufwerk: /f/r, da wäre ein Datensalat natürlich fatal, auch wenn es nicht meine einzige Backup HDD ist.
Zum Vergrößern anklicken....
Hab mal einen unwichtigen Stick getestet, chkdsk /f, keine Probleme, die Dateien sind auch im Bitvergleich unverändert. Build .685
 
ghostadmin schrieb:
Vielleicht liegts am Treiber für den Controller. MS haut ja ab und zu mal fehlerhafte Versionen raus.
Zum Vergrößern anklicken....
Maybe, MS haut öfter mal was raus.

Wenn auf einen Datenträger geschrieben wird, ist der Speicher dafür verantwortlich.
Wenn der RAM Fehler macht sind sie definitiv auch auf dem Datenträger, da kann chkdsk dann auch nichts mehr reparieren. ;)
 
So, heute hatte ich noch 13 Lenovo Flex 2-15D mit AMD A6-6310 und Kingston A400 in der Reißn. Alle identisch installiert, alle mit identischer Hardware. 9 sind fehlerfrei durchgelaufen nach chkdsk c: /f, 4 steckten anschließend im BSOD fest. Ich denke das ist der letzte sehr starke Hinweis, dass die Hardware-Ausstattung nicht entscheidend ist bei dem Problem. :(

Was mich auch irritiert: die Test-VMs hatte ich ja frisch installiert, neue VM, neue VDI, taufrische Installation. Was hat chkdsk c: /f in so einem Fall überhaupt herumzureparieren am FS? Bei einer taufrischen Installation kann doch unmöglich schon etwas reparaturbedürftig gewesen sein?! *kopfkratz
 
Zuletzt bearbeitet:
Gigabyte GA X99 UD 3 Rev. 1
Intel I7-5960X
64GB DDR4
Systemplatte Samsung 970 EVO Plus 250GB via M.2 PCIe Adapter
Windows 10 Build 19042.685

Hängenbleiben im Bluescreen nach Chckdsk C:/F
Nach Reset Dateisystemrepratur, reboot, Windows läuft wieder.
 
OK Asrock Taichi X399, 2950X, Samsung PM981 128GB NVMe CSM aktiv (wegen Win7)

Vorgehensweise: Ausgangsbasis 2004
Alle Updates installiert bis auf 20H2, nach Neustart chkdsk (mit /f) IO ausgeführt
20H2 installiert + Neustart, danach chkdsk (mit /f) IO ausgeführt
 
Nero24 schrieb:
So, heute hatte ich noch 13 Lenovo Flex 2-15D mit AMD A6-6310 und Kingston A400 in der Reißn. Alle identisch installiert, alle mit identischer Hardware. 9 sind fehlerfrei durchgelaufen nach chkdsk c: /f, 4 steckten anschließend im BSOD fest. Ich denke das ist der letzte sehr starke Hinweis, dass die Hardware-Ausstattung nicht entscheidend ist bei dem Problem. :(

Was mich auch irritiert: die Test-VMs hatte ich ja frisch installiert, neue VM, neue VDI, taufrische Installation. Was hat chkdsk c: /f in so einem Fall überhaupt herumzureparieren am FS? Bei einer taufrischen Installation kann doch unmöglich schon etwas reparaturbedürftig gewesen sein?! *kopfkratz
Zum Vergrößern anklicken....
Wenn es kein Hardware Problem ist, wird es wohl ein Soft-Fehler sein. ;)

Wie ist den das Herunterladen von Update auf anderen PC eingestellt in der Werkseinstellung?

Wenn die Update direkt von MS kommen sollte es keine Probleme geben, aber wenn die Update von anderen PC im www kommen (ohne ECC Speicher) dann wird u.U. auch Mist übertragen.

Meine bescheidene Erklärung, hat natürlich noch copy & paste Potential.
 
Dann würde die Prüfsumme nicht stimmen und das Update nicht installiert.
 
Nero24 schrieb:
So, heute hatte ich noch 13 Lenovo Flex 2-15D mit AMD A6-6310 und Kingston A400 in der Reißn. Alle identisch installiert, alle mit identischer Hardware. 9 sind fehlerfrei durchgelaufen nach chkdsk c: /f, 4 steckten anschließend im BSOD fest. Ich denke das ist der letzte sehr starke Hinweis, dass die Hardware-Ausstattung nicht entscheidend ist bei dem Problem. :(

Was mich auch irritiert: die Test-VMs hatte ich ja frisch installiert, neue VM, neue VDI, taufrische Installation. Was hat chkdsk c: /f in so einem Fall überhaupt herumzureparieren am FS? Bei einer taufrischen Installation kann doch unmöglich schon etwas reparaturbedürftig gewesen sein?! *kopfkratz
Zum Vergrößern anklicken....


Golem kann wie PCGH aber auch 3DNow! nicht richtig schreiben. ;)


www.borncity.com

Windows 10 20H2: Achtung bei Update KB4592438, ChkDsk beschädigt das Dateisystem

[English]In Windows 10 20H2 gibt es möglicherweise ein massives Problem mit der Datenträgerprüfung chkdsk, wenn das Update KB4592438 installiert ist. Diese beschädigt bei einer Prüfung mit…
www.borncity.com www.borncity.com

In den Kommentaren da steht noch, das man mittlerweile lieber andere Parameter verwenden sollte:

CHKDSK /scan und CHKDSK /spotfix
 
wenn dem thread schon so viel aufmerksam von ausserhalb beigemessen wird, dann vielleicht nicht schlecht über die anderen schreiben ^^
 
Morkhero schrieb:
wenn dem thread schon so viel aufmerksam von ausserhalb beigemessen wird, dann vielleicht nicht schlecht über die anderen schreiben ^^
Zum Vergrößern anklicken....


*chatt* Hier bin ich doch nett. Du musst mal meine Beschwerdemails lesen. 8)
Nein quatsch, wir haben doch eigentlich zu allen nen gutes Verhältnis und teilweise ist selbst die Chefredaktion nur ne Mail weit entfernt.
 
Es gibt wohl eine Lösung. Auf Deskmodder:

deskmodder.de/blog/2020/12/21/chkdsk-f-problem-wurde-behoben-unter-windows-10-20h2-und-windows-10-2004

(Einen direkten Link wollte das Forum nicht annehmen, sei sei wahrscheinlich SPAM. Ist es aber nicht...)
 
Nein du hast erst 2 Posts, meine nach 5 gehen dann auch Links

chkdsk /f Problem wurde behoben unter Windows 10 20H2 und Windows 10 2004 (deskmodder)
Doppelposting wurde automatisch zusammengeführt:

Die haben da ein Update im Artikel:

Nachtrag: Der Fehler war schon seit 8 Monaten im System​


Wie Star Fox und Albacore aus dem Telegram Kanal herausgefunden haben, lag es am Feature Servicing_2011c_28083526, welches im System seit der Windows 10 Insider Build 19624 bzw. 19619 enthalten war. Somit lag es nicht direkt an der KB4592438, sondern war eine „tickende Zeitbombe“. Wie Albacore schreibt, ist dieser Codepfad in der aktuellen Insider Build 21277 noch aktiv. Also sollte man dort kein chkdsk /f durchführen. Sicherlich wird dies dann in der nächsten Insider im Januar korrigiert.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Wo soll der der Fix den herkommen? Per Windows Update? Also da hat bisher kein Rechner was bekommen bei mir. Nur ein Defender Update bisher.
 
Keine Ahnung, kann nur wiedergeben was da steht bei MS: "This issue is resolved and should now be prevented automatically on non-managed devices. Please note that it can take up to 24 hours for the resolution to propagate to non-managed devices. Restarting your device might help the resolution apply to your device faster."
 
Ja das habe ich ja auch gelesen, na warten wir mal bis Mittwoch ab.
 
Sagi T 754 schrieb:
Dann würde die Prüfsumme nicht stimmen und das Update nicht installiert.
Zum Vergrößern anklicken....
Da hast du schon recht, nur ist das Feature für Umgebungen die schlechte Internet Verbindungen habe.
Also peer-to-peer von einem anderen Rechner, da gibts dann kein Feedback vom MS Server ob die Prüfsumme passt.
Es wird nur geprüft ob sie so ankommt, wie sie beim Sender vorliegt. (CRC)
 
Eben getestet, ok, Update KB4592438 ist installiert.

  • Windows 10 Pro x64 20H2 Build 19042.685
  • Ryzen 9 3900X
  • Asus PRIME B450-PLUS UEFI Ver. 2409
  • 64 GB DDR4 ECC
  • Samsung 970 EVO 1TB NVMe PCIe 3.0 X4

  • Windows 10 ist als Dualboot mit Linux Mint 20 installiert,
  • CSM ist abgeschaltet im UEFI,
  • kein Secure Boot,
  • GPT Portionierung,
  • 4 Partitionen: UEFI Fat32, Windows Systemwiederherstellung, NTFS Win 10 C:\, Ext4 Linux ./ Root


Die lahme Gurke von Convertible mit AMD A4-1200 APU kommt die Tage dran.
 
Zuletzt bearbeitet:
  • Windows 10 Home 20H2 x64
  • NTFS, GPT Partitionierung
  • Toshiba WD30Dt-A100
  • 500 GB Western Digital Sata Festplatte
  • Secure Boot im UEFI aktiviert
  • 1GHz Dual-core AMD A4-1200
Chkdsk ist nach 5 Stunden fertig geworden *chatt* *rofl*
 
Klasse, hätte ich das mal früher mit bekommen.
Habe heute genau den gleichen Fehler, nach dem ich mal wieder ein chkdsk /f über meine Festplatten laufen lassen habe.
Habe ein Dual-Boot System (Win10, Win7, Linux) mit ASRock B85M Pro3 mit 16GB DDR3 RAM und als Windows 10 Laufwerk eine KingDian S400 120GB SSD.

Normal mache ich regelmäßig (von Linux aus auf einen lokalen BackUp Server) eine komplette Sicherung aller Partitionen bzw. der kompletten SSD (Win10/Win7). Nur diesmal - Murphy - habe ich kein BackUp gemacht. :-(

Aber wenn ich das richtig verstanden habe, kann ich von der Boot-Konsole mit chkdsk /f den Fehler wieder beheben? Korrekt?
 
Ja, so beschreibt es MS hier: (aber nur auf der englischen Seiten)
support.microsoft.com/en-us/help/4592438/windows-10-update-kb4592438
To mitigate this issue on devices which have already encountered this issue and are unable to start up, use the following steps:
  1. The device should automatically start up into the Recovery Console after failing to start up a few times.
  2. Select Advanced options.
  3. Select Command Prompt from the list of actions.
  4. Once Command Prompt opens, type: chkdsk /f
  5. Allow chkdsk to complete the scan, this can take a little while. Once it has completed, type: exit
  6. The device should now start up as expected. If it restarts into Recovery Console, select Exit and continue to Windows 10.

Note After completing these steps, the device might automatically run chkdsk again on restart. It should start up as expected once it has completed.
 
Tja, klappt nur leider nicht. Wenn ich mit F8 abgesicherten Modus mit Konole starten will, bekomme ich einen GSOD.
Ich habe dann Win7 gestartet, um evtl. von dort auf der Partition chksdk auszuführen, aber die Partition wird nur als RAW angezeigt. :-(
Also werde ich wohl oder übel eine drei Wochen alte Sicherung aufspielen müssen und alles ist weg, was seid dem geändert wurde...

Edit:
Erstaunlicherweise kann ich die Partition unter Linux ohne Probleme mounten! Seltsam...

Ich habe die komplette SSD mit dd (linux dd) auf eine andere (USB) Festplatte 1:1 gesichert. Dort werden jetzt alle Laufwerke auch korrekt gemounted. Das ist schon komisch...
 
Zuletzt bearbeitet:
Sehr ärgerlich! Vor allen weil's inzwischen angeblich (wie denn genau ohne erneutes Update?) behoben sein soll.
borncity.com/blog/2020/12/21/windows-10-2004-20h2-microsoft-fixt-chkdsk-problem-in-update-kb4592438/
Es ist jetzt zwar kein passender Augenblick zu Fragen, aber wie machst du eine Sicherung von deinen System Laufwerk? Image?
Hast du kein Boot-Medium AKA ct Notfall Windows oder ähnliches?
Mich hat's am Montag erwischt, nachdem Windows einen Fehler auf LW C monierte und die "Platte" überprüfen wollte. Danach hatte ich zwar kein so einen fatalen Fehler wie du bzw. die Meisten hier, aber einen Loop beim Starten im Explorer. Trotzdem zähle ich es mal dazu:

KO WXP 20H2 19042.685 auf ASUS ROG Crosshair VIII HERO mit Ryzen™ 9 3950X, SanDisk Extreme PRO 1 TB M.2, GPT/UEFI
(schon wieder ein ASUS Board)
Habe es zum Anlass genommen eine Neuinstallation vorzunehmen...8)
 

Ähnliche Themen

C
Windows 10 auf NVME bootet nicht
Antworten
15
Aufrufe
2K
eratte
eratte
neax
ASRock X570 PG Velocita m. 3800X Sound- und andere Probleme
5 6 7
Antworten
160
Aufrufe
13K
eiernacken1983
E
Hammerhead Shark
Ablösung eines 10 Jahre alten AMD Heimservers
Antworten
12
Aufrufe
3K
Thyler Durden
Thyler Durden
gruenmuckel
Ryzen 7 statt Intel. Muss das so? Takt, Wärme etc.
2 3
Antworten
51
Aufrufe
7K
MagicEye04
MagicEye04
Thyler Durden
LENOVO ThinkPad E595
Antworten
7
Aufrufe
3K
Thyler Durden
Thyler Durden
Zurück
Oben Unten