Wir hatten vor zwei Tagen darüber berichtet, dass es unter Windows 10 20H2 und 2004 mit der KB4592438 zu einem Problem mit dem Befehl chkdsk C: /f kommen kann. Microsoft hat sich erstaunlich schnell darum gekümmert und das Problem behoben.
„Dieses Problem ist behoben und sollte nun auf nicht administrierten Geräten automatisch verhindert werden. Bitte beachten Sie, dass es bis zu 24 Stunden dauern kann, bis die Lösung auf nicht verwaltete Geräte übertragen wird. Wenn Sie Ihr Gerät neu starten, wird die Lösung möglicherweise schneller auf Ihr Gerät angewendet.“
„Bei Geräten mit Unternehmensmanagement, die dieses Update installiert haben und bei denen dieses Problem auftritt, kann es durch die Installation und Konfiguration einer speziellen Gruppenrichtlinie (Direktlink) behoben werden.“
Sollte das Problem bereits aufgetreten sein, sollte das Gerät automatisch in die erweiterten Startoptionen starten. Hier dann die Eingabeaufforderung auswählen und chkdsk /f eingeben und ausführen. Das Gerät sollte danach wieder ganz normal starten. Beim Neustart kann chkdsk durchaus noch einmal ausgeführt werden.
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.
Solange sollte man die neuen Befehle nutzen, die es ab Windows 8 gibt. chkdsk /scan c: bzw. chkdsk /spotfix c:. Diese laufen laut Kommentaren ohne Probleme durch. Mehr dazu in unserem Wiki unter
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 2004 ISO (19041), oder 20H2 (2009) ISO (19042)
- Installation: Windows 10 Clean installieren, Win 10 2004 neu installieren
- Aktuelle Probleme mit der: Windows 10 2004 / 20H2
- 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: 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.
Hab oben noch ein Nachtrag hinzugefügt. Es lag also nicht speziell an der KB4592438.
Ist für mich trotzdem nicht verständlich. Also wer entweder Insider war oder die KB4592438 ist mit Sicherheit betroffen? Wer weder Insider war noch KB4592438 nutzt ist sicher?
Trotzdem danke an alle für die Detektivarbeit
Nein sicher nicht, da der Fehler schon länger im System war, aber nicht so häufig aufgetreten ist.
Außer du bist noch mit der Windows 10 1909 unterwegs. Dort scheint der Fehler nicht integriert worden zu sein.
Das, was Microsoft jetzt beschrieben hat, ist der andere Fehler mit chkdsk. Der war nur lästig, aber hatte keine weiteren Auswirkungen auf das Dateisystem. Aus dem Fehler ist man, so wie dort beschrieben, herausgekommen.
Das andere Problem ist, dass man aus der Bootschleife nicht mehr heraus kommt. Bei jedem Booten startet das WInRE, führt chkdsk aus, Neustart und dann geht das wieder von vorne los. Bin da einfach nicht aus der Schleife mehr herausgekommen. Und wenn ich dann mal von der WinPE Umgebung mir die Partition anschaue, dann wird diese nur als Leer oder RAW angezeigt.
Und ja, der Fehler war in Fast/DEV schon lange bekannt, dann war er weg und nur ist er wieder da. Das ist auch seltsam. Von daher bin ich mir da nicht sicher, ob KB4592438 nicht da doch eine Rolle spielt. Ist im Moment schwer zu sagen.
Die KB spielte da wohl den Auslöser des „bösen Spiels“. Anders kann ich mir das nicht erklären. Sonst würde der Fehler sicherlich noch weitere 8 Monate im System schlummern.
Aus meiner Sicht sind das zwei unterschiedliche Fehler. Einmal kommt man über Umwege raus und alles passt wieder, der andere Fehler scheint das Dateisystem zu schreddern. Hier hilft nur Backup oder Neuinstallation. Habe es da gerade mal in der VM getestet und 19042.685 und 20279.1 haben das Problem. Hängt sich nach dem GSOD bzw. BSOD in einer Dauerschleife „Automatischer Reparatur mit chkdsk“ auf.
Oder es ist eine „mutierte“ Form des Bugs. So, dass da im System was anderes nicht stimmt und es deshalb zum Schreddern kommt. Schwer zu sagen.
Dem kann ich nur zustimmen, das sind zwei verschiedene Paar Schuhe diese Fehler … ich kam ohne Backup nicht mehr zurück bei dem Rechner.
Ich habe den chkdsk/-f Befehl bisher nicht benutzt. Wo kann man denn das Update bekommen? Oder lohnt es sich, bis zum Januar-Update zu warten?
Du brauchst nichts zu unternehmen.
Dann bin ich ja beruhigt. Danke für die Info.
Gibt es da nun ein neues Update oder wie will MS die Problemlösung an die User weiter geben? Geht dem text nicht hervor (außer der Angabe für Admins im Unternehmensmanagement, wie sie es machen können).
Das passiert automatisch ohne ein neues Update.
Danke für den Hinweis
Dann gibt es wahrscheinlich keinen Eintrag im Update-Verlauf? Kann ich sonst i’wie feststellen, ob auf meinem System der Fix stattgefunden hat?
Der Fix, den Microsoft meint, kam mit der 662 und ist somit auch in der 685 enthalten.
Hallo moinmoin,
die Fehlerbehebung funktioniert doch aber nur, wenn man quasi ein jungfräuliches Windows hat, oder? Ich habe hingegen einiges an Telemetry usw. abgeschaltet. Funktioniert das dann auch? Kann man das irgendwo in Windows einsehen, wenn es behoben wurde? Es müsste ja irgendwo dokumentiert sein.
Schöne Feiertage
Thorky
Anmerke:
Ich hatte diesen CHKDSK-Fehler bereits vor Monaten beschrieben – und auch, daß der wohl nur unter 64-Bit-Windows so „deutlich“ auftritt/auftrat …
Möglicherweise hängt das ja mit der „neuen Auswerte-Funktion“ (Detailanzeigen der einzelnen Schritte) zusammen … Aber so genau kann ich das auch nicht beschreiben – bin schließlich nicht von hier (ortsfremd und geländedoof) …
„Sollte das Problem bereits aufgetreten sein, sollte das Gerät automatisch in die erweiterten Startoptionen starten. Hier dann die Eingabeaufforderung auswählen und chkdsk /f eingeben und ausführen. Das Gerät sollte danach wieder ganz normal starten.“
Und welche Partion soll da in den mit
chkdsk /f
angesprochen werden?
Edit:
Und welche Partition in den erweiterten Startoptionen in der Eingabeaufforderung soll mit
chkdsk /f
angesprochen werden?
zur Aussage von DK2000 am 21. Dezember 2020 um 19:29 Uhr:
„Der Fix, den Microsoft meint, kam mit der 662 und ist somit auch in der 685 enthalten.“
Danke, wenn es sich so verhält! Diese klare Aussage hätte dann aber auch vielleicht schon von
„moinmoin“ (oder anderen Fachleuten) zu Beginn dieser Diskussion erfolgen sollen!?
Ich wünsche dem Deskmodder-Team alles Gute für die Feiertage – und macht weiter so im
neuen Jahr. Danke für die wirklich tolle Arbeit, die Ihr leistet!
Moin, gibt es ein Feedback hub link für den aktuellen Fehler in Dev?
gepostet mit der Deskmodder.de-App für Android
Gute Frage, nächste Frage?
So wie ich das sehe, sind die Ergänzungen in KB KB4586853 und KB4592438 (en) i.Z.m. chkdsk vermutlich vom 21.12.2020 (letztes Änderungsdatum), mit u. a. jeweils dem Hinweis (vorbehaltlich Übersetzung):
„Eine kleine Anzahl von Geräten, die dieses Update installiert haben, hat gemeldet, dass beim Ausführen von chkdsk / f das Dateisystem möglicherweise beschädigt wird und das Gerät möglicherweise nicht startet. „ Im Weiteren zur Auflösung siehe dort.
Die jeweiligen deutschen Artikel enthalten diesen Hinweis noch nicht.
Insoweit (dem Wortlaut nach) würde sich das Problem aus meiner Sicht schon auf die zwei KBs beziehen,
was es da auch sonst noch an weiteren Zusammenhängen geben mag.
Vlt. geben ja die Aktivitäten im Zuverlässigkeitsverlauf Aufschluss über erfolgte Korrekturen.
Konnte hier jedenfalls umfangreiche Aktivitäten bei Neukonfigurationen beobachten.