Publié le 21 février 2024 à 23h30. Un ordinateur sous Windows, bloqué après un crash pendant un jeu, a pu être réparé grâce à des outils intégrés souvent méconnus, démontrant la puissance insoupçonnée du système de récupération de Microsoft.
- L’incident a mis en évidence la vulnérabilité potentielle des systèmes Windows face à des corruptions de démarrage, même avec le chiffrement BitLocker activé.
- La réparation a nécessité l’utilisation de l’invite de commande dans l’environnement de récupération Windows (WinRE) et des outils comme « bcdboot », « bcdedit », « manage-bde » et « diskpart ».
- Microsoft améliore discrètement WinRE, notamment en intégrant la prise en charge des pilotes réseau et des fonctionnalités de récupération avancées.
Si Windows est souvent perçu comme moins flexible que Linux en matière de personnalisation profonde du système, ses outils de récupération intégrés sont en réalité étonnamment performants. Récemment, une utilisatrice a rencontré un problème critique alors qu’elle jouait à Detroit : Become Human : son ordinateur s’est figé brutalement. Après un redémarrage, elle s’est retrouvée face à un message d’erreur indiquant que le périphérique de démarrage était inaccessible. Les tentatives suivantes ont affiché un écran demandant sa clé BitLocker, mais le retour à l’écran d’erreur était inévitable.
L’appareil, équipé d’un processeur Intel Core i5-14600K et d’une carte graphique Intel Arc A770, semblait hors d’usage. La réparation automatique au démarrage n’a pas résolu le problème, et l’impossibilité de déverrouiller le disque avec la clé BitLocker a suscité des craintes quant à une perte de données. Heureusement, l’utilisatrice disposait de sauvegardes récentes, mais la situation restait déconcertante : comment un tel incident pouvait-il se produire ? Et était-il possible de récupérer le système ?
BitLocker, un obstacle supplémentaire
Ce n’était pas le problème principal
En examinant l’ordinateur, le premier obstacle rencontré a été l’écran de récupération BitLocker. La clé de récupération a été récupérée depuis le compte Microsoft de l’utilisatrice et saisie avec soin. Après un temps d’attente, le système a redémarré, pour se retrouver à nouveau face au message d’erreur concernant le périphérique de démarrage inaccessible, avant de revenir à l’écran de demande de la clé BitLocker. Le système reconnaissait la clé, mais ne parvenait pas à démarrer correctement, entrant dans une boucle sans fin.
Au lieu de considérer le disque comme définitivement perdu, une autre approche a été adoptée pour vérifier son état. L’outil Clonezilla a été démarré à partir d’une clé USB Ventoy, et la commande « ntfsfix » a été exécutée pour vérifier la partition. Le volume NTFS s’est monté sans erreur, et le système de fichiers semblait intact. Il est alors devenu clair que le problème résidait dans la configuration de démarrage, corrompue quelque part dans la chaîne.
La séquence de démarrage d’un système Windows moderne se déroule ainsi :
- Micrologiciel UEFI
- Gestionnaire de démarrage EFI
- \EFI\Microsoft\Boot\bootmgfw.efi
- Magasin BCD
- winload.efi
- Initialisation du noyau
- Pilotes de démarrage
- Ruche SYSTÈME
- Profil utilisateur
La corruption des fichiers de démarrage EFI et du BCD a entraîné une incompatibilité entre l’environnement de démarrage mesuré et la clé BitLocker scellée par le TPM (Trusted Platform Module). Cela a empêché le déverrouillage automatique de la clé de chiffrement. Même la saisie manuelle de la clé de récupération n’a pas suffi, car il n’y avait rien de valide pour démarrer le système.
En d’autres termes, une fois la partition déchiffrée, Windows aurait pu se lancer, mais les entrées BCD corrompues pointaient vers un mauvais périphérique. Lorsque le noyau a tenté de monter le volume système, l’opération a échoué, générant l’erreur INACCESSIBLE_BOOT_DEVICE. La réparation de l’EFI ne résolvait qu’une partie du problème.
La plupart des utilisateurs ignorent son existence
L’environnement de récupération Windows propose plusieurs options de réparation graphiques, telles que la réparation du démarrage, la restauration du système et la réinitialisation du PC, mais elles se sont avérées inefficaces dans ce cas. Cependant, l’invite de commande, accessible dans les options avancées, offre une puissance de récupération bien plus importante. Sachant que les données du disque étaient intactes, il était pertinent de tenter de reconstruire la séquence de démarrage.
Dans un premier temps, il a fallu déverrouiller le lecteur chiffré par BitLocker. Il est important de noter que les lettres de lecteur dans WinRE ne correspondent pas toujours à celles affichées dans Windows. La commande « diskpart » a été utilisée pour lister les volumes et identifier le bon lecteur, avant d’exécuter « manage-bde -unlock C: -RecoveryPassword » suivi de la clé à 48 chiffres, puis « `manage-bde -protectors -disable C:` » pour suspendre temporairement la protection BitLocker. Cela a permis de travailler sur les fichiers de démarrage sans être bloqué.
L’étape suivante a consisté à accéder à la partition système EFI, une petite partition FAT32 cachée d’environ 100 Mo contenant le gestionnaire de démarrage Windows et le magasin BCD. Elle n’a pas de lettre de lecteur par défaut, et WinRE n’en attribue pas automatiquement. Dans « diskpart », le disque a été sélectionné, les volumes listés, la partition EFI identifiée et la lettre S lui a été attribuée manuellement. Cette attribution forcée de la lettre de lecteur a résolu une erreur générée par « manage-bde ».
Avec la partition EFI accessible en S :, la commande « bcdboot C:\Windows /s S: /f UEFI » a été exécutée. Cette commande a copié les fichiers de démarrage nécessaires de l’installation Windows vers la partition EFI, généré un nouveau magasin BCD et configuré le gestionnaire de démarrage pour pointer vers la partition Windows correcte. La chaîne de démarrage a été reconstruite à partir de zéro. La commande « bcdedit /enum » a confirmé la validité des nouvelles entrées, et un redémarrage a permis de charger Windows normalement.
Une fois Windows redémarré, BitLocker a été réactivé à partir d’une invite de commande élevée avec « manage-bde -protectors -enable C: ».
Microsoft continue d’améliorer ses outils
Ce qui est remarquable, ce n’est pas tant la solution elle-même que le fait que ces outils – « bcdboot », « bcdedit », « manage-bde » et « diskpart » – sont disponibles avec Windows depuis des années, et pourtant, la plupart des utilisateurs ignorent leur existence. L’instinct naturel en cas de problème de démarrage est de recourir à une clé USB d’installation et de réinstaller le système, ce qui est compréhensible. L’environnement de récupération ne met pas suffisamment en avant ses capacités en ligne de commande. Cependant, ces outils peuvent éviter de devoir effacer un disque parfaitement fonctionnel, et ils sont bien plus puissants qu’on ne le pense.
Microsoft a également discrètement amélioré WinRE. Windows 11 intègre désormais les pilotes réseau de l’installation principale du système d’exploitation, permettant à l’environnement de récupération de se connecter à Internet sans avoir à injecter manuellement les pilotes. Cela a permis la création de la fonctionnalité Récupération rapide de la machine, inspirée d’un incident chez CrowdStrike en 2024, qui permet de télécharger automatiquement des correctifs ciblés en cas d’échec du démarrage. Une fonctionnalité de restauration ponctuelle est également en cours de test, permettant de revenir à un état antérieur précis du système plutôt qu’au dernier point de restauration.
Il y a une certaine ironie dans cette situation. Les propres mises à jour de Microsoft ont parfois déclenché des invites de récupération BitLocker, comme celle rencontrée ici. La mise à jour de sécurité d’octobre 2025 a provoqué le même problème sur certains PC Intel (bien qu’il s’agisse d’un déverrouillage unique plutôt que répétitif), et un bug a empêché la saisie au clavier USB dans WinRE, rendant impossible la saisie de la clé de récupération. Microsoft a corrigé le problème en une semaine, mais sans connaître ces commandes, la situation aurait été désespérée.
L’ordinateur fonctionne à nouveau parfaitement. Il n’a pas été nécessaire de réinstaller le système, aucune donnée n’a été perdue, et l’utilisatrice a pu passer une soirée sans avoir à tout reconfigurer. Les outils étaient disponibles dans Windows depuis le début, et il a été judicieux de les essayer en premier.