La dernière série de correctifs lancée par Microsoft pour ses Windows (Patch Tuesday) contenait un bug pouvant avoir de fâcheuses conséquences.
Touchant les branches 2004 et 20H2 de Windows 10, il entrainait un comportement problématique de la commande chkdsk /f. Sans que l’on sache pourquoi, l’outil affectait alors le système de fichier, produisant un BSOD voire, dans les pires cas, une corruption du système de fichier.
Le bug ne semble pas avoir fait un trop grand nombre de victimes, car il réclame l’utilisation de la ligne de commande et la présence d’un SSD. Sa reproductibilité est cependant très bonne, car il survient même en machine virtuelle.
Microsoft a mis à jour les problèmes connus pour ses mises à jour KB4592438 et KB4586853. On y trouve une méthode pour réparer sa machine si la commande empêche le système de démarrer, sans pour autant avoir ruiné le système de fichier :
- La machine doit démarrer automatiquement en mode Console de récupération après plusieurs échecs de démarrage
- Aller dans Options avancées
- Sélectionner Invite de ligne de commande dans la liste des actions
- Lancer la commande chkdsk /f
- Laisser chkdsk finir l’analyse, ce qui peut prendre du temps
- Une fois l’opération terminée, taper exit
Le démarrage de Windows devrait maintenant aboutir. Si le système revient sur la Console de récupération, Microsoft conseille simplement de cliquer sur Quitter et continuer vers Windows 10.
Parallèlement – et surtout – un correctif est en cours de diffusion, qui doit normalement empêcher le souci de se produire.
Commentaires (12)
#1
Le programme de réparation qui casse tout, c’est ballot !
#2
bien content d’apprendre ce problème, je m’apprêtait a faire un chkdsk suite aux lenteurs de boot constatées depuis la dernière grosse maj windows 20H2
#3
Si je comprend bien, il est préférable de lancer cette commande en forçant la console au démarrage.
Quelqu’un peut confirmer ? Merci par avance.
#4
C’est ce qui est marqué dans la brève
#5
Ça m’est déjà arrivé il y a bien longtemps… (windows 98 ou XP je ne me rappelle plus) le système de fichier était corrompu et le programme de vérif l’a achevé :(
Bref, c’est là qu’on réalise que les sauvegardes régulières c’est le bien
#5.1
Ca m’arrivais très souvent quand j’avais un dualboot Win7/Win10 (pourtant installés sur des disques différents, avec des secteurs de boot indépendant vu que je faisais le choix de l’OS via les options de boot du bios) : chaque fois que je bootais sur Win10 il me réclamait une vérif de tous les disques (alors que RAS tant que je bootais uniquement sur Win7) et si je le laissait faire j’avais droit à la même quand je repassais sous Win7, sauf qu’une fois sur 2 le chkdsk de Win10 me bousillait le boot de Win7 et donc fallait en passer par un peu de bricolage pour “réparer la réparation”.
Quand j’en ai eu marrer “d’appuyer sur une touche pour ignorer la vérification” à chaque switch d’OS j’ai fini par configurer les 2 pour que leurs chkdsk respectifs ignorent les disques de l’autre et depuis plus de soucis.
#6
la machine doit démarrer “AUTOMATIQUEMENT” en mode console de récup’
on ne fait rien au départ……
#6.1
on peut le forcer dans les options de démarrage avancées.
faut juste pas utiliser chkdsk sur un invite de commande windows classique.
#7
Quand on automatise le contrôle qualité, voilà ce que ça donne…
#7.1
Franchement c’est même + pitoyable que ça, parce que je vois pas pourquoi ce problème n’aurait pas été trouvé par le contrôle qualité automatique.
Le contrôle qualité de Windows 10 n’est pas automatisé, il est délégué aux clients.
#8
Heureusement que la brève contient un lien vers l’article original, car la traduction automatique a produit quelques perles inintelligibles.
“l’outil affectait alors le système de fichier”
Je n’arrive d’ailleurs pas à trouver quelle partie de l’original a pu produire cette phrase.
#9
Qui utilise encore ce truc ? J’ai pas dû taper cette commande depuis Windows 98… Et pourtant, en dos, c’était incontournable !