Chkdsk kan bestandssysteem ssd op Windows 10 20H2 beschadigen - update

Gebruikers van Windows 10 20H2 met update KB4592438 melden dat de tool Chkdsk het bestandssysteem van ssd's kan beschadigen. Na het draaien van de commandlinetool voor schijfcontrole, starten systemen niet meer op volgens de berichten.

Het probleem doet zich voor als gebruikers update KB4592438 hebben doorgevoerd op Windows 10 20H2 en vervolgens chkdsk c: /f op het systeem uitvoeren. Daarmee voert Windows schijfcontrole uit en voert automatisch wijzigingen door bij problemen. Een beheerder van schoolsystemen meldt op het forum van Planet3DNow dat daarna zeven systemen niet meer konden opstarten en een blue screen of death-melding toonden.

Andere leden van het forum bevestigen de problemen en melden dat deze zich ook voordoen bij het draaien van een systeem in een virtuele machine. Bij gebruik van Windows 10 20H2 zonder update KB4592438 doen de problemen zich niet voor. Microsoft gaf deze update begin december vrij. De update verhelpt volgens Microsoft problemen met de oude Edge-browser en Office-producten. De update is ook voor Windows 10 2004 verschenen dus aan te nemen is dat ook die versie kan crashen na het draaien van Chkdsk op ssd's.

Het probleem is gemeld aan Microsoft door middel van de Feedback Hub. De maker van Windows 10 meldt dat het bekend is dat er een 'klein aantal' gebruikers problemen heeft in combinatie met KB4592438, maar voor zover bekend is nog geen update beschikbaar die het probleem verhelpt.

Update: Microsoft meldt dat het probleem verholpen is en ook publiceert het bedrijf stappen voor getroffen systemen.

Bron: Planet3DNow

Reacties (130)

Van de site van de betreffende update bij de known issues:

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. For enterprise-managed devices that have installed this update and encountered this issue, it can be resolved by installing and configuring a special Group Policy. To find out more about using Group Policies, see Group Policy Overview.

To mitigate this issue on devices which have already encountered this issue and are unable to start up, use the following steps:

The device should automatically start up into the Recovery Console after failing to start up a few times.
Select Advanced options.
Select Command Prompt from the list of actions.
Once Command Prompt opens, type: chkdsk /f
Allow chkdsk to complete the scan, this can take a little while. Once it has completed, type: exit
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.

Geen idee of ze een nieuwe versie hebben uitgebracht of wat de automatische fix zou moeten zijn....maar MS heeft dus wel gereageerd door het op te nemen in de known issues .

Als je de daar onder gelinkt group policy uitpakt zie je dat het om een register wijziging gaat (een soort 'chicken bit'):

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides
valueName: 2372249226
decimal value: 1

De uitgepakte group policy bestanden hebben datum van 19 december 2020 23:08:00 (CET, onze tijd, lijkt me)

[Reactie gewijzigd door Henk Poley op 21 december 2020 12:17]

Dat pushen gaat dan denk ik gewoon via Windows update?

Vast en zeker. Maar je krijgt in ieder geval geen item te zien in Instellingen > Bijwerken & Beveiliging > Windows Updates > Geschiedenis van updates weergeven.

In de regel erboven staat: class="Machine".
Ik ga ervan uit dat met het pad SYSTEM gewoon die onder HKLM bedoeld wordt.

👍 Ik kom dat cijfer bij mij in het register onder Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FeatureManagement\Overrides\4\2372249226 tegen met EnabledState = 1 (32-bit DWORD)

En Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\2372249226 - in feite de niet-policy versie.

[Reactie gewijzigd door Henk Poley op 21 december 2020 13:32]

Volgens microsoft is deze bug al resolved:
https://support.microsoft...ndows-10-update-kb4592438

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. For enterprise-managed devices that have installed this update and encountered this issue, it can be resolved by installing and configuring a special Group Policy. To find out more about using Group Policies, see Group Policy Overview.


To mitigate this issue on devices which have already encountered this issue and are unable to start up, use the following steps:

The device should automatically start up into the Recovery Console after failing to start up a few times.
Select Advanced options.
Select Command Prompt from the list of actions.
Once Command Prompt opens, type: chkdsk /f
Allow chkdsk to complete the scan, this can take a little while. Once it has completed, type: exit
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.

To mitigate this issue on devices which have already encountered this issue and are unable to start up, use the following steps:

The device should automatically start up into the Recovery Console after failing to start up a few times.
Select Advanced options.
Select Command Prompt from the list of actions.
Once Command Prompt opens, type: chkdsk /f
Allow chkdsk to complete the scan, this can take a little while. Once it has completed, type: exit
The device should now start up as expected. If it restarts into Recovery Console, select Exit and continue to Windows 10.

Gebruikers van Windows 10 20H2 met update KB4592438 melden dat de tool Chkdsk het bestandssysteem van ssd's kan beschadigen.

Waarschijnlijk is het probleem niet beperkt tot SSD's met een enkel bestandssysteem (er kunnen er meerdere op een enkele SSD staan d.m.v. meerdere partities). Ook is mogelijk het probleem niet beperkt tot enkel SSD's, gezien het ook in VM's voorkomt.

[Reactie gewijzigd door The Zep Man op 21 december 2020 13:09]

Maar wie gebruikt dit uberhaupt nog... dit is voor mij meer iets uit het dos tijdperk...

Maar wie gebruikt dit uberhaupt nog... dit is voor mij meer iets uit het dos tijdperk...

Windows (geautomatiseerd), bijvoorbeeld na een crash of onverwachte stroomuitval. chkdsk is het gereedschap om fouten in het bestandssysteem (NTFS) op te lossen.

[Reactie gewijzigd door The Zep Man op 21 december 2020 10:33]

In dit geval klopt dit zeker, CHKDSK /f lijkt het probleem te veroorzaken, echter de oplossing is....... ook CHKDSK /f

https://support.microsoft...ndows-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:

The device should automatically start up into the Recovery Console after failing to start up a few times.
Select Advanced options.
Select Command Prompt from the list of actions.
Once Command Prompt opens, type: chkdsk /f
Allow chkdsk to complete the scan, this can take a little while. Once it has completed, type: exit
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.

Dit was inderdaad in mijn geval de enige werkende oplossing afgelopen vrijdag...

Tweakers bijvoorbeeld. Windows zelf als het fouten detecteert. Of niet technische gebruikers die het vinkje 'repareer fouten' aanzetten bij het controleren van de disk. Of mensen uit het het FAT tijdperk die geleerd hebben dat je dit regelmatig moet doen om geen data kwijt te raken.

Ik dateer uit het "FAT tijdperk" (degene waarop je reageert vermoedelijk ook gezien zijn registratiedatum) maar CHKDSK heb ik toch al sinds midden jaren 90 niet meer gebruikt. Mijn ervaring is trouwens dat je soms juist data kwijt raakte door het gebruik ervan.CHKDSK repareerde het filesysteem maar niet perse je bestanden.

Ik kom ook uit dat tijdperk en ik gebruik zelf liever chkdsk om de eenvoudige dat reden ik feedback krijg. Als ik hetzelfde vanuit de GUI doe dan kan ik niet zien wat er gechecked en eventueel gefixed is.

Die feedback komt in de eventlog, ik geloof onder system\winlogon.
Al is de feedback in cmd draaien wel directer.

Ik kom ook uit dat tijdperk en ik gebruik zelf liever chkdsk om de eenvoudige dat reden ik feedback krijg. Als ik hetzelfde vanuit de GUI doe dan kan ik niet zien wat er gechecked en eventueel gefixed is.

De grap is dat de GUI ook gewoon dezelfde tool aanstuurt. (Getuige het feit dat de uitvoer van de commandline tool verbatim naar de event logs gaat.)

Dus ook als je de GUI versie gebruikt heb je kans deze nieuwe bug te raken.

Niet bewust, maar Windows gebruikt het zelf op de achtergrond dus wel.

Dat jij het niet handmatig gebruikt betekend niet dat Windows het niet achter de schermen automatisch doet.

Dat is dan gedrag van na het "FAT tijdperk".

Als je het sinds de jaren '90 niet meer handmatig gebruikt hebt, gebruik je waarschijnlijk gelijkwaardige 3rd party tools. Niets mis mee, maar de meeste mensen beheren Windows toch met de bijgeleverde tools en daar is ook niets mis mee. Sterker nog, MS moet die ondersteunen en dat doen ze dus ook door een patch uit te brengen voor deze fout.

Ik dateer uit het "FAT tijdperk" (degene waarop je reageert vermoedelijk ook gezien zijn registratiedatum) maar CHKDSK heb ik toch al sinds midden jaren 90 niet meer gebruikt.

Windows draait het soms automatisch, bv als het zelf een fout op het bestandssysteem detecteert. Het kan dus best zijn dat het sindsdien toch al eens heeft gedraaid.

Mijn ervaring is trouwens dat je soms juist data kwijt raakte door het gebruik ervan.CHKDSK repareerde het filesysteem maar niet perse je bestanden.

Klopt. Integriteit van Windows gaat boven de gegevens van de gebruiker bij Microsoft. Sinds de introductie van Vista wordt dat steeds sterker (al heeft men wel al eens een stapje terug gezet als er heel veel protesten kwamen op onverwachte herstarts enzo).

Maar wie gebruikt dit uberhaupt nog... dit is voor mij meer iets uit het dos tijdperk...

Mijn vader

[Reactie gewijzigd door Oaknut op 21 december 2020 10:33]

die defragmenteerd waarschijnlijk ook regelmatig nog ?

In tegenstelling tot defragmenteren, is het uitvoeren van checkdisk nog steeds nuttig en soms noodzakelijk op SSD's.

Verwarring komt waarschijnlijk van de naam; het controleert helemaal niet een schijf. Het controleert of het file systeem op een partitie nog correct is of niet (met eventuele reparatie). Een andere naam (zoals fschk ) zou waarschijnlijk beter zijn geweest.

De 16-bit chkdsk van DOS is compleet anders dan de 32- en 64-bit versies die onze huidige NTFS schijven controleren. Ja, de naam is hetzelfde maar onder de motorkap is het anders.

Klopt en daartussen had men het programma scandisk. Wie destijds de overstap maakte van Dos chkdsk naar Windows scandisk keek met de overgang naar NT dus toch een beetje raar op. (en nee, ik ben nog geen opa)

Iemand die windows-systemen beheert.
En blijkbaar niet zo jong is dat hij/zij alleen nog maar op knoppen kan drukken.

De commando prompt is niet ouderwets. Het is de meest directe toegang tot het besturingssysteem, waarbij je alle ruis van de grafische interface omzeilt.
Dit geldt niet alleen voor windows, ook Linux beheerders werken nog via een prompt. (Ik heb geen ervaring met het beheer van Apples)

Op Apples doe je dat ook als beheerder, de terminal is een van de meest gebruikte applicaties bij beheer van Apples.
Niet dat het daar van afhangt maar MacOS is in feite BSD.

Ook bij Apple komt dit voor. Momenteel werkt Schijfbeheer op mijn sata harde schijf niet meer. De schijf is corrupt en het enige wat rest is alles eraf, e.h.b.o. zijn werk laten doen en dan alles opnieuw installeren. Op de mac draai ik praktisch drie versies met verschillende mac OS’en.

MS stimuleert het gebruik van de command prompt zelfs,bij mijn weten.

Het is zelfs de grootste verandering aan de Microsoft way of working ooit (naar mijn mening). Vroegah was het GUI first maar tegenwoordig is het API first development.

Zo zie je steeds vaker features in MS producten die al jaren puur en alleen via "commandline" te gebruiken zijn voordat er een GUI voor gemaakt wordt

Dit zijn standaard tools uit de troubleshooting toolbox. Zelfs MS adviseert in een hoop gevallen dit te draaien. Wanneer is de laatste keer dat je een console heb geopend in Windows?

Iedereen die, wanneer de pc te vaak onverwacht herstart is, niet op een toets drukt om het checken op fouten te skippen.

Ik heb chkdsk wonderen zien verrichten, van formateer onleesbare partitie tot alles terug.
Het is in mijn geval zelfs opgenomen in een script welke ik heb gemaakt voor generiek pc onderhoud. Normaal gesproken is het een scan en meer niet, maar als er wel fouten zijn ben je blij dat hij hem oplost.

Tijdens werkplekken troubleshooten kwam ik het vaak tegen in combinatie met bluescreens door het vele herstarten. Dus als ik ergens bluescreens oploste pakte ik hem altijd even mee om zeker te zijn dat ook de schade was opgelost.

Dat is een standaard oplossing als er fouten zijn... maar.. nu zorgt diezelfde tool dus zelf voor fouten te zorgen... hopelijk neemt Microsoft eens beta testers aan... want dit is gewoon een blunder van jawelste.

lol, eerste wat ik doe als een Windows-machine raar doet.

wordt best nog veel gebruikt, ik gebruik eigenlijk meestal de powershell cmdlets/varianten maar er zijn genoeg beheerders die chckdsk gebruiken of als repair-volume niet voldoet (kan niet alles wat chckdsk wel doet) en verder gebruik ik dism en sfc ook nog wel eens. Dus er wordt best veel van dat soort tools (nog) gebruikt :-)

https://docs.microsoft.co...pair-volume?view=win10-ps

Ik gebruik het zeker nog. Maar niet veel meer. Want aangezien NTFS journaling kent zijn fouten in het filesystem zeldzaam geworden.

Nee hoor. Onder Windows XP was het draaien van chkdsk een zeer standaard aanbevolen handeling bij issues vanuit Microsoft zelf.

Daarmee kon je Windows installaties repareren als er opeens windows bestanden niet werden gevonden, dll errors, etc.

Was heel common en kwam direct van Microsoft knowlegde fora, database en tools.

XP kon je nog op FAT systemen zonder journalling installeren. Vista eiste NTFS.

Iedereen die tegen een schijffout aanloopt? Overigens bestond NTFS nog niet in het DOS-tijdperk, dus ergens klopt daar iets niet.

Misschien verwar je DOS met de Windows command line danwel Powershell? Die werken ook met getypte commando's maar worden dagelijks door miljoenen gebruikers en beheerders wereldwijd gebruikt.

Meen je dat nu echt?

Ik 2 weken geleden nog. Ik had problemen met opstarten vanaf mijn SSD, chkdsk gedraaid, probleem opgelost. Het is een van de eerste dingen die ik gebruik als er problemen zijn. Ik zal niet beweren dat DOS beter was dan nu, verre van dat, maar je had wel vaak een veel cleanere controle over wat er gebeurde.

/edit: sorry was natuurlijk een reactie op mjl

[Reactie gewijzigd door ArthurMorgan op 21 december 2020 11:02]

En waar draait die VM op? Op diezelfde SSD!

En waar draait die VM op? Op diezelfde SSD!

Het ligt eraan of aan de VM wordt doorgegeven dat die op een SSD draait.

Lijkt mij wel toch?

Aannames
De VM krijgt meestal alleen maar door dat die een 'Virtual HD ATA Device' VHD (Virtual Hard Drive) heeft (Hyper-V), of die op een HDD, SSD, NVME SSD, RAM disk, USB stick, LTO tape (ja, slecht idee) of compleet fiber channel SAN staat boeit de VM vrij weinig hoewel de prestaties uiteraard verschillen.
Dit kan op VirtualBox, VMWare enz anders werken maar meestal is het gewoon een vrij universele VHD(x) container.

De vraag is alleen nu, of chkdsk op een langzaam medium wel zijn werk goed doet? Zoals op een normale hardeschijf bijvoorbeeld!

Dat is mijn punt eigenlijk!

VHDX op je FC-SAN? Geen goed idee, Hyper-V heeft native support voor SAN's.

Het grote probleem is TRIM. Vanuit de host gezien is je VHD file in gebruik, alleen de guest weet welke stukken van de VHD file werkelijk files in de VM zijn, en welk deel van de VHD vrij is. Je hebt VHDX nodig om TRIM te laten werken. De guest kan dan TRIM commando's naar de virtuele disk sturen, die Hyper-V dan moet vertalen naar LBA's op de fysieke drive. En dat is inderdaad subtiel - je TRIM't clusters uit het midden van een echte file op disk.

Die VM wel ja, maar het OS op die VM niet. Die draait op een virtuele drive, óf een aparte fysieke drive (pass-through). Deze kan nooit op dezelfde drive draaien als het Host OS. Dit probleem met chkdsk kan dus alleen problemen opleveren binnen de VM.

En als door het draaien van chkdsk. Je systeem niet meer draait is het nog te fixen dan?

Mogelijk kan je nog wel bij je data. Opstarten not so much.

Ligt eraan of de schijf nog te benaderen is, hier aantal systemen gehad die hadden een RAW partitie. Na een CHKDSK (ja hetgeen wat het ook blijkbaar veroorzaakte) was de data weer te zien en de laptops starte weer op.

Klinkt heel eng Lang leve backups. Laatst zelf een defecte disk gehad, na inbouwen nieuwe SSD en opstarten van alle cloud en sync diensten was het net of er niets gebeurd was.

Moet de boel niet versleuteld zijn met iets als bitlocker. Dan kun je het waarschijnlijk vergeten.

Dan kun je normaal gesproken de ssd met een usb/sata kabel aansluiten en de bitlocker sleutel handmatig invoeren. Maar als dat deel net beschadigd is

Naja in principe draait chkdsk binnen de ontgrendelde state. Dus dat zou dan in principe goed moeten gaan, maar ja je weet nooit.

Nee hoor. Ik had hetzelfde probleem. In system restore wordt eerst je unlock key gevraagd, daarna kon ik verder en daarna via command prompt opnieuw chkdsk /f uitvoeren. Daarna was het opgelost en kon ik weer booten.

Bij mij niet en ik heb NIET actief chkdsk uitgevoerd. Alleen een Windows-update.

chkdsk draait toch niet om de zoveel tijd uitzich zelf toch?

Dont know. Wellicht dat ie dat na de eerste bod wel gedaan heeft?

Word er ook ergens aangegeven waarom het specifiek voor SSDs is. Het OS doet uiteindelijk vrij weinig met de schijf zelf. Die geeft de controller alleen de opdracht om iets te doen en daar zit uiteindelijk niet zo veel verschil in (tussen het aanspreken van een SSD of een HDD)

Misschien iets met dat TRIM gebeuren of een andere SSD specifieke opdracht.

Een TRIM verzoek is ook niks meer dan een verzoek aan de controller. Het OS doet niets meer dan “Yo controller, TRIM” en de controller geeft terug hoever ie is. En TRIM heeft niks met het bestandssysteem te maken. Dat is op blokniveau.

TRIM is juist gemaakt om aan de hand van gewiste informatie op een bestandssysteem de SSD te laten weten waar iets gewist moet worden, i.i.g. als je de ATA instructie bedoelt waar je ook moet meegeven welke LBA geTRIMd moet worden. Het OS is verantwoordelijk om voor specifieke LBA's een TRIM commando te sturen waarvan deze weet dat deze zojuist gewist zijn op het bestandssysteem.

TRIM is niet een commando zonder verdere argumenten.

Dus als het OS per ongeluk een TRIM stuurt voor een LBA waar nog belangrijke gegevens op staan, dan kan ik me voorstellen dat dat een probleem is

[Reactie gewijzigd door Sfynx op 21 december 2020 12:06]

TRIM laat de SSD niet weten waar iets gewist moet worden, dat suggereert een actieve actie die tijd zou kosten. En dat wil je niet bij een SSD; ook wissen is slijtage. TRIM betekent praktisch gezien dat de SSD die blokken niet meer mee hoeft te nemen in de wear levelling. Dat beperkt dus de slijtage.

Dat zou ook verklaren waarom Microsoft het niet gezien had - wear levelling is typisch een achtergrond proces, en een SSD hoeft dus niet meteen actie te ondernemen na een TRIM. Hoe lang het duurt zal afhangen van een heleboel factoren, zoals bijvoorbeeld al eerder geplande wear levelling die bezig is.

Dat zou ook verklaren waarom Microsoft het niet gezien had - wear levelling is typisch een achtergrond proces, en een SSD hoeft dus niet meteen actie te ondernemen na een TRIM.

Je zou wel enigszins kunnen verwachten dat er unit tests zijn die checken of alleen de correcte blocks worden geTRIMd.

Da's iets te gemakkelijk. TRIM/UNMAP stuurt een lijst van blok adressen naar de controller die de controller als ongebruikt mag markeren. Die lijst komt rechtstreeks uit het file systeem, namelijk de blokken die aan gewiste bestanden toebehoorden.

Er is een rechtstreekse relatie tussen het bestandssysteem en de blokken die vrijgegeven worden. Als door de laatste patch het TRIM mechanisme een verkeerde lijst met blokken opgeeft dan kan de SSD blokken hergebruiken die eigenlijk nog door bestanden in het filesysteem in gebruikt zijn. En zo heb je corruptie te pakken.

De theorie met TRIM verklaart alleen niet waarom een 2e chkdsk vanuit recovery het probleem verhelpt. Gewiste blocks zijn gone en corrupte blocks kun je nou niet echt meer terugbrengen naar hun oorspronkelijke staat.

Ik heb alleen update uitgevoerd en mijn laptop start niet meer op. Straks kijken of ik mijn data nog eraf kan halen

Als het mogelijk is probeer een CHKDSK uit te voeren op de C: partitie, heb dit met een aantal systemen gehad en hiermee was het opgelost. als dit niet werkt kan je nog de normale herstel opties proberen die je als het goed is zowieso in beeld krijgt.

(Edit, Geen idee waarom dit -1 krijgt, maar bedankt voor het minnen van een eventuele oplossing)

[Reactie gewijzigd door 2bad4u op 21 december 2020 11:10]

De reden dat dit ws een -1 krijgt is dat dit juist het punt van het artikel is. CHKDSK kan dus je systeem beschadigen zodat het meer opstart en dan is jouw reactie “oh moet je ff CHKDSK draaien”.

Dat werkt dan dus averechts.

Dat zou je denken inderdaad, maar omdat er al meerdere systemen hier er juist baat bij hadden en daarna juist WEL opstarte lijkt me dit geen verkeerde optie.

Geen idee of het zo werkt, wellicht verklooit de CHKDSK iets maar kan het door een 2e keer hersteld worden door hetzelfde uit te voeren.

Zie ook hier: Unique in 'nieuws: Chkdsk kan bestandssysteem ssd op Windows 10 20H2 beschadi...

[Reactie gewijzigd door 2bad4u op 21 december 2020 11:41]

Oh ik geloof het verder wel hoor, Gebruik geen windows systemen meer dus heb hier sws geen last van, maar ik kan wel begrijpen dat de erste lichting modders zoiets had van ja ho ff.

Microsoft geeft ook aan dat dit de oplossing is.
Dennism in 'nieuws: Chkdsk kan bestandssysteem ssd op Windows 10 20H2 beschad...

Ga ik zo proberen 👍

Ik had hetzelfde vorig jaar, door een cumulatieve/optionele update te installeren wilde Windows 10 niet meer opstarten, wat ik ook probeerde. Heb uiteindelijk mijn data er ook af moeten halen en alles moeten reinstalleren.

Wordt dit (chkdsk) niet ook automatisch gedaan door Windows als het op een rustig moment systeemonderhoud uitvoert?

Goede vraag! Als dat zo is hebben we straks een groot probleem over de hele wereld!

Y2k20

Wordt dit (chkdsk) niet ook automatisch gedaan door Windows als het op een rustig moment systeemonderhoud uitvoert?

Ik dacht dat er inderdaad taken voor aangemaakt zijn in de task scheduler, maar wel in read-only modus. (Dus zonder de /f flag.)

DIt probleem vorige week ook ervaren en "opgelost" met een herinstallatie, dit was "ineens" opgetreden aldus de gebruiker. Ben wel benieuwd hoe dit daadwerkelijk opgelost kan worden zonder herinstallatie.

Daar ben ik ook benieuwd naar.

Nou heb ik 20H2 ook geïnstalleerd en die KB4592438 update ook zo ontdek ik net. Zou het misschien verstandig zijn om de update te de-installeren of is het beter om simpelweg geen chkdsk te draaien..?

Kún je de KB4592438 update überhaupt trouwens wel de-installeren..?

De gebruiker die geholpen had had zelf zeker geen chkdsk gedraaid dus het kan je zomaar overkomen.

Ja, zoveel had ik inderdaad ook al begrepen.

Aangezien Win10 zelf kan beslissen om chkdsk te laten lopen heb ik toch maar eens even nagezocht of de update te verwijderen was. En dat is zo, ik heb update KB4592438 toch maar van m'n computer geknikkerd en de pc opnieuw opgestart. Dus in principe zou ik het 'euveltje' niet moeten kunnen krijgen.

Ik heb dit probleem hier vorige week ook ervaren. Gelukkig op een Game-PC waar geen belangrijke zaken op stonden. Van alles geprobeerd (herstel etc.) maar uiteindelijk W10 clean install uit moeten voeren. En dat alles na een schijnbaar simpele Windows-update..
Nu is het dus duidelijk wat er aan de hand was

[Reactie gewijzigd door Edje040 op 21 december 2020 10:39]

Yep hier ook. En Windows restore was niet mogelijk, ook de download optie deed het niet. Gelukkig nog een USB drive liggen met een oude installatie.

Alle data gelukkig op OneDrive, want ik kon niet anders dan formatteren.

Ik kan zelfs niet meer formatteren, mijn schijf is in "current read-only" mode gegaan, en de read only attribute weghalen gaat niet. Ik kan chkdsk doen, en er worden fouten gevonden, maar wanneer ik chkdsk /f of chkdsk /x probeer werkt het niet door een cyclic redundancy error of omdat hij geen writing permissions heeft...
Ik denk dat mijn SSD echt gewoon gebricked is, maar alle ideeën zijn welkom...

Geen idee of een van deze opties je helpt? https://www.diskpart.com/...-read-only-mode-7201.html

Hier idem