Écran bleu après l’installation d’un pilote : restauration depuis WinRE

Ce qui a réellement cassé : un modèle mental pratique

Une « installation de pilote » n’est pas une seule chose. C’est généralement un paquet :
un pilote en mode noyau (.sys), un package INF, une entrée de service, peut‑être des pilotes filtres,
peut‑être un co‑installateur, peut‑être un composant en espace utilisateur qui appelle le réseau au démarrage si possible.
Lorsqu’un pilote casse le démarrage, il le fait typiquement de l’une des cinq façons suivantes :

1. Plantage d’un pilote de démarrage : un service Start=0 (BOOT_START) se charge tôt et déréférence quelque chose de stupide. Résultat : BSOD instantané.
2. Sabotage de la pile de stockage : le pilote du contrôleur de stockage/NVMe/RAID/filtre change la façon dont les disques sont énumérés. Résultat : périphérique de démarrage inaccessible, volume manquant, ou confusion BitLocker.
3. Intégrité du code / enforcement de signature : Windows refuse un pilote non signé/bloqué. Résultat : échec de démarrage, ou boucle de récupération avec « impossible de charger le pilote ».
4. Corruption de la mémoire noyau : le pilote « fonctionne » jusqu’à ce qu’il corrompe la mémoire et que vous crashiez plus tard. Résultat : BSOD pas immédiatement au logo ; vous avez quelques secondes/minutes.
5. Incompatibilité de dépendances : le pilote attend une autre build d’OS, des paramètres hyperviseur différents, ou un empilement fournisseur en conflit. Résultat : pannes aléatoires, parfois seulement sur certaines révisions matérielles.

Votre tâche en mode récupération n’est pas de devenir un débogueur noyau. Votre tâche est de faire démarrer le système
sans effacer les données, puis d’effectuer une post‑mortem correcte dans un environnement stable.

Une chose de plus : les pilotes sont de l’infrastructure. Traitez‑les comme des changements de configuration en production.
Les retours arrière doivent être ennuyeux, réversibles et consignés (même si « consigné » signifie que vous prenez une photo de l’écran parce que vous êtes sur un parking).

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Quand la machine ne démarre pas, vous n’avez pas le luxe d’« explorer ». Utilisez une boucle serrée :
identifiez la classe de défaillance, choisissez le rollback le moins destructeur, confirmez le démarrage, puis nettoyez.

Premier : classer le BSOD et le comportement de démarrage

• Plantage instantané au logo/roue → probablement pilote BOOT_START ou problème de pile de stockage.
• Plantage après l’apparition de l’écran de connexion → souvent pilote vidéo, réseau, ou sécurité (toujours en mode noyau, mais plus tard).
• Code d’arrêt « INACCESSIBLE_BOOT_DEVICE » → pilote du contrôleur de stockage, pilote filtre, ou BCD/chemin de périphérique.
• Mentionne un fichier .sys → vous avez un suspect de première importance. Notez‑le.

Deuxième : choisir le levier de rollback le plus petit

• Startup Settings → Mode sans échec (chargement minimal) si disponible. Supprimez ou restaurez le pilote depuis Windows.
• WinRE → Restauration du système si des points de restauration existent et si vous pouvez vous le permettre.
• WinRE → Invite de commandes pour un rollback hors ligne : DISM pour retirer le package pilote, ou registre hors ligne pour désactiver le service du pilote.

Troisième : vérifier le démarrage, puis durcir

• Confirmez que le système démarre deux fois de suite. Un seul démarrage réussi est une illusion.
• Récupérez les logs/dumps. Identifiez le package pilote racine et empêchez‑le de réapparaître.
• Réintroduisez les pilotes intentionnellement (package fournisseur ou Windows Update), pas « n’importe quoi que l’assistant trouve ».

Accéder à Windows Recovery Environment (WinRE) sans empirer la situation

WinRE est votre « gestion hors bande » pour les portables et serveurs Windows sans iDRAC/iLO.
Ce n’est pas glamour, mais c’est généralement suffisant.

Méthodes standard pour atteindre WinRE

• Récupération automatique : après quelques échecs de démarrage, Windows bascule souvent en « Préparation de la réparation automatique ». Laissez‑faire. Ne coupez pas l’alimentation en plein diagnostic sauf si c’est vraiment bloqué.
• Depuis le démarrage : interrompez le démarrage 2–3 fois (coupe d’alimentation dès que les points tournent) pour déclencher la récupération. C’est grossier mais efficace.
• Clé USB d’installation bootable : « Réparer votre ordinateur » → Dépannage → Options avancées. C’est souvent le chemin le plus propre si WinRE sur disque est endommagé.

Réalité BitLocker

Si le volume OS est protégé par BitLocker, WinRE peut demander la clé de récupération avant d’accéder au disque.
Ce n’est pas Windows qui fait la difficulté ; c’est le chiffrement qui fait son travail. Prévoyez en conséquence.

Blague #1 : Si vous n’avez pas la clé de récupération BitLocker, vous n’avez pas de plan de récupération — vous avez un plan d’optimisme.

Preuves d’abord : quoi collecter avant de « réparer » quoi que ce soit

Règle SRE : avant de changer l’état, capturez suffisamment d’éléments probants pour apprendre de la panne.
Sinon vous « réparerez » aujourd’hui et la répéterez le mois prochain avec plus d’assurance et moins de prudence. Combinaison dangereuse.

Dans WinRE, les preuves portent surtout sur : quelle installation Windows est sur quelle lettre de lecteur, quels pilotes ont été ajoutés récemment,
et si un dump/log incrimine un .sys spécifique.

• Notez le code d’arrêt exact et tout pilote nommé (une photo suffit).
• Identifiez la lettre du volume Windows dans WinRE (ce n’est souvent pas C:).
• Vérifiez les minidumps et les journaux de démarrage (si présents).
• Listez les packages pilotes récemment ajoutés hors ligne (DISM peut le faire).

L’objectif est simple : pouvoir répondre à « Qu’avons‑nous supprimé/désactivé, et pourquoi ? »

Voies de restauration depuis le mode de récupération (choisir la moins destructive)

Voie A : Mode sans échec, puis désinstallation/restauration normalement

Si vous pouvez accéder au Mode sans échec, faites‑le. Le Mode sans échec charge un ensemble minimal de pilotes et services.
Cela signifie que le pilote défectueux pourrait ne pas se charger, vous donnant une fenêtre stable pour le supprimer comme une personne civilisée.

Utilisez WinRE : Troubleshoot → Advanced options → Startup Settings → Restart, puis choisissez :
4 (Mode sans échec) ou 5 (Mode sans échec avec réseau) si vous devez récupérer un pilote connu‑bon.

En Mode sans échec :
désinstallez le pilote/logiciel depuis Programmes et fonctionnalités lorsqu’il s’agit d’une suite fournisseur,
ou restaurez via le Gestionnaire de périphériques quand c’est une mise à jour de pilote,
ou utilisez pnputil pour la précision.

Voie B : Restauration du système (rapide, parfois brutale)

La Restauration du système peut annuler des installations de pilotes parce que les pilotes font partie de « l’état système » suivi par les points de restauration.
C’est souvent le chemin le plus rapide quand vous ne savez pas quel pilote a cassé le démarrage. L’inconvénient :
vous pouvez ramener d’autres changements aussi (mises à jour, réglages).

Utilisez‑la quand :
le système a des points de restauration,
vous pouvez tolérer la perte de changements récents du système,
et vous avez besoin d’un retour rapide à l’aptitude au démarrage.

Voie C : Suppression hors ligne du pilote avec DISM (chirurgical, fiable)

DISM peut inspecter et supprimer des packages pilotes d’une image Windows hors ligne.
C’est la méthode à utiliser quand le Mode sans échec ne démarre pas et que la Restauration du système n’est pas disponible ou est risquée.

C’est aussi la méthode à utiliser quand vous voulez une trace d’audit : « suppression de oem42.inf qui contenait badstor.sys. »

Voie D : Édition hors ligne du registre pour désactiver le service du pilote (scalpel ultime)

Parfois vous ne pouvez pas enlever proprement le package (verrou, dépendance, empilement fournisseur désordonné),
mais vous pouvez empêcher le pilote de se charger en changeant son type de démarrage.
Cela peut suffire à démarrer puis finaliser le nettoyage depuis une session normale.

Utilisez ceci avec précaution, surtout pour les pilotes de stockage. Désactiver le mauvais miniport de stockage est un excellent moyen
de transformer une « boucle de démarrage » en « ne démarre plus du tout ».

Tâches pratiques (commandes + sorties + décisions)

Toutes les tâches ci‑dessous supposent que vous êtes dans l’Invite de commandes de WinRE (ou une invite élevée en Mode sans échec quand indiqué).
L’erreur la plus courante ici est de supposer que le lecteur OS est C:. Dans WinRE ce n’est souvent pas le cas.

Task 1: Find the Windows installation drive letter

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   Windows      NTFS   Partition    237 GB  Healthy
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     E   Recovery     NTFS   Partition    900 MB  Healthy    Hidden

DISKPART> exit

Ce que cela signifie : Le volume Windows est D:, pas C:.
Décision : Utilisez D:\Windows pour tous les chemins hors ligne ci‑dessous.

Task 2: Confirm you’re looking at the right Windows folder

cr0x@server:~$ dir D:\Windows\System32
 Volume in drive D is Windows
 Volume Serial Number is 34E2-9A1C

 Directory of D:\Windows\System32

...snip...

Ce que cela signifie : Le répertoire existe et ressemble à un vrai OS.
Décision : Poursuivez ; le mappage des lettres est correct.

Task 3: Check for BitLocker protection status (and whether you need to unlock)

cr0x@server:~$ manage-bde -status D:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume D: [Windows]
    Size:                 237.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password

Ce que cela signifie : Le volume est chiffré mais déverrouillé dans WinRE (commun si la récupération s’est déjà authentifiée).
Décision : S’il était verrouillé, vous auriez besoin de manage-bde -unlock D: -RecoveryPassword YOUR-KEY avant que DISM puisse le lire.

Task 4: Identify the last boot’s BSOD evidence in the offline event logs

cr0x@server:~$ wevtutil qe /lf:true D:\Windows\System32\winevt\Logs\System.evtx /q:"*[System[(EventID=41 or EventID=1001)]]" /c:5 /rd:true /f:text
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Level: Error
  Description: The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000007B ...
Event[1]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Event ID: 41
  Level: Critical
  Description: The system has rebooted without cleanly shutting down first.

Ce que cela signifie : Vous avez un code de bugcheck (ici 0x7B, classique inaccessible boot device).
Décision : Concentrez‑vous sur les pilotes du contrôleur de stockage/filtres et les installations récentes liées au stockage.

Task 5: Check for minidumps and copy them somewhere safe

cr0x@server:~$ dir D:\Windows\Minidump
 Volume in drive D is Windows
 Directory of D:\Windows\Minidump

02/04/2026  08:13 AM           1,245,184 020426-9328-01.dmp
               1 File(s)      1,245,184 bytes

Ce que cela signifie : Un minidump existe. Parfait — cela peut nommer le pilote incriminé plus tard.
Décision : Copiez‑le hors‑site (USB, partage réseau) avant de changer quoi que ce soit, si possible.

Task 6: List installed third-party driver packages offline (DISM)

cr0x@server:~$ dism /image:D:\ /get-drivers /format:table
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Published Name  Original Name  Inbox  Class Name          Provider Name       Date
-------------  -------------  -----  ------------------  ------------------  ----------
oem12.inf      iaStorVD.inf   No     SCSIAdapter         Intel              01/29/2026
oem21.inf      nvme.inf       No     SCSIAdapter         VendorStorageCo     02/03/2026
oem34.inf      netwtw10.inf   No     Net                 Intel              11/10/2025

Ce que cela signifie : Vous avez un pilote de stockage récemment ajouté (oem21.inf) daté juste avant le crash.
Décision : Candidat à la suppression ou à la désactivation, mais confirmez qu’il n’a pas remplacé le seul pilote viable pour votre contrôleur.

Task 7: Inspect a specific driver package for files and version clues

cr0x@server:~$ dism /image:D:\ /get-driverinfo /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Driver package information:
Published Name: oem21.inf
Original File Name: nvme.inf
Provider Name: VendorStorageCo
Class Name: SCSIAdapter
Class GUID: {4d36e97b-e325-11ce-bfc1-08002be10318}
Driver Version: 02/03/2026 2.1.0.14
Signer Name: Microsoft Windows Hardware Compatibility Publisher

Ce que cela signifie : C’est de la classe stockage, installé récemment. Signé, donc c’est probablement un bug/incompatibilité, pas un problème de signature.
Décision : Si le BSOD est 0x7B, retirer ce package est une étape raisonnable — à moins qu’il n’ait remplacé le seul pilote requis pour votre contrôleur.

Task 8: Remove the suspected driver package offline

cr0x@server:~$ dism /image:D:\ /remove-driver /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Removing driver package: oem21.inf
[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Le package est retiré du driver store pour cette image hors ligne.
Décision : Redémarrez et testez le démarrage. Si cela échoue encore, passez à la désactivation du service ou au point de restauration.

Task 9: If you can boot Safe Mode, use pnputil to remove a driver package (online)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem12.inf
Driver Package Provider : Intel
Class : SCSIAdapter
Driver Version And Date : 01/29/2026 19.6.1.1053
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Published Name : oem34.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 11/10/2025 22.250.1.2
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Ce que cela signifie : Vous pouvez voir ce qui est installé quand Windows est en marche (même en Mode sans échec).
Décision : Utilisez pnputil /delete-driver oemXX.inf /uninstall pour un nettoyage ciblé, particulièrement pour des suites fournisseurs qui réinstallent les pilotes.

Task 10: Enable boot logging to capture which driver loads last (when you can reach Startup Settings)

cr0x@server:~$ bcdedit /store D:\Boot\BCD /set {default} bootlog Yes
The operation completed successfully.

Ce que cela signifie : Les tentatives de démarrage suivantes écriront ntbtlog.txt.
Décision : Redémarrez, laissez échouer une fois, puis revenez à WinRE et inspectez le journal.

Task 11: Read the boot log offline to see the last loaded driver

cr0x@server:~$ type D:\Windows\ntbtlog.txt
Loaded driver \SystemRoot\system32\ntoskrnl.exe
Loaded driver \SystemRoot\System32\drivers\CLASSPNP.SYS
Loaded driver \SystemRoot\System32\drivers\disk.sys
Loaded driver \SystemRoot\System32\drivers\badstor.sys

Ce que cela signifie : Le dernier pilote chargé listé est badstor.sys. C’est une preuve accablante.
Décision : Supprimez son package via DISM ou désactivez son service hors ligne.

Task 12: Disable a driver service offline by editing the registry hive (safer than random deletions)

C’est le mouvement « arrêter de le charger ». Vous montez la ruche SYSTEM hors ligne, éditez la clé de service, puis démontez la ruche.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query HKLM\OFFSYS\ControlSet001\Services\badstor /v Start
HKEY_LOCAL_MACHINE\OFFSYS\ControlSet001\Services\badstor
    Start    REG_DWORD    0x0

cr0x@server:~$ reg add HKLM\OFFSYS\ControlSet001\Services\badstor /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Ce que cela signifie : Start=0 (démarrage) est devenu Start=4 (désactivé).
Décision : Redémarrez. Si le système démarre, vous avez maintenant une plateforme stable pour supprimer proprement le pilote et installer une version connue‑bonne.

Task 13: Verify the active control set (avoid editing the wrong one)

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query HKLM\OFFSYS\Select
HKEY_LOCAL_MACHINE\OFFSYS\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    LastKnownGood    REG_DWORD    0x2

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Ce que cela signifie : Current=1 indique que ControlSet001 est actif.
Décision : Si Current était 2, vous éditeriez ControlSet002 à la place (ou les deux si vous voulez la ceinture et les bretelles).

Task 14: Use Last Known Good Configuration logic (manual hint)

Windows n’expose plus « Last Known Good » comme avant, mais le registre le suit encore.
Si un pilote de démarrage a cassé les choses, forcer un démarrage en choisissant le dernier ensemble de contrôle connu bon peut aider.
Une approche pratique est de désactiver le pilote dans les deux ensembles de contrôle 001 et 002 si vous n’êtes pas sûr.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg add HKLM\OFFSYS\ControlSet002\Services\badstor /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Ce que cela signifie : Vous avez désactivé le pilote dans l’ensemble de contrôle alternatif aussi.
Décision : Cela réduit les surprises « ça a démarré une fois puis ça a replanté ».

Task 15: Check the offline driver file actually exists (and isn’t a leftover)

cr0x@server:~$ dir D:\Windows\System32\drivers\badstor.sys
 Volume in drive D is Windows
 Directory of D:\Windows\System32\drivers

02/03/2026  06:21 PM           842,752 badstor.sys
               1 File(s)        842,752 bytes

Ce que cela signifie : Le fichier existe ; il a probablement été ajouté/mis à jour récemment.
Décision : Ne le supprimez pas encore. Préférez la suppression du package ou la désactivation du service pour pouvoir revenir en avant proprement plus tard.

Task 16: If the driver is a filter driver, identify its attach points (offline registry check)

Les pilotes filtres de stockage vivent souvent dans UpperFilters/LowerFilters et peuvent bloquer le démarrage s’ils sont mal configurés.

cr0x@server:~$ reg load HKLM\OFFSYS D:\Windows\System32\config\SYSTEM
The operation completed successfully.

cr0x@server:~$ reg query "HKLM\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}" /v UpperFilters
HKEY_LOCAL_MACHINE\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}
    UpperFilters    REG_MULTI_SZ    badstorflt

cr0x@server:~$ reg unload HKLM\OFFSYS
The operation completed successfully.

Ce que cela signifie : Il y a un filtre supérieur attaché à la classe disque. S’il est défectueux, toute la classe peut mal fonctionner.
Décision : Désactivez le service du filtre (ou retirez son package) plutôt que d’arracher bêtement des valeurs du registre — sauf si vous avez une forte preuve que la valeur UpperFilters elle‑même est corrompue.

Task 17: Run an offline system file check (when you suspect collateral damage, not just a driver)

cr0x@server:~$ sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

Ce que cela signifie : Les fichiers système principaux sont intacts.
Décision : Concentrez‑vous sur le rollback de pilote plutôt que sur des réinstallations de l’OS.

Task 18: Check the disk for filesystem issues (especially after crash loops)

cr0x@server:~$ chkdsk D: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
No problems found.

Ce que cela signifie : Le système de fichiers semble sain.
Décision : Si des erreurs sont trouvées, corrigez‑les avant de chasser des fantômes de pilote : chkdsk D: /f (peut nécessiter un redémarrage).

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 (mauvaise supposition) : « C’est juste un pilote GPU ; il ne peut pas affecter le démarrage »

Une agence de design de taille moyenne a déployé une mise à jour du pilote graphique sur des postes de travail parce qu’une application fournisseur
se plaignait de « composants obsolètes ». Le déploiement a eu lieu tard le vendredi — parce que bien sûr —
et le plan était « c’est juste le graphique, au pire l’app plantera ».

Lundi matin, plusieurs machines étaient bloquées dans une boucle de démarrage. Le code d’arrêt était incohérent.
Certaines montraient un .sys nommé lié à la pile GPU. D’autres redémarraient avant que quelqu’un puisse le lire.
Le support a tenté Startup Repair à plusieurs reprises. Cela n’a rien fait, sauf brûler du temps et de la confiance.

La mauvaise supposition : les pilotes graphiques sont « chargés tard ». Sur Windows moderne, les pilotes GPU peuvent être impliqués tôt
dans le chemin de boot‑to‑login, surtout avec le démarrage rapide, l’hibernation hybride, et des services fournisseurs qui démarrent au boot.
Un mauvais module noyau se fiche d’être « juste graphique ». En mode noyau, il a assez de privilèges pour tout faire planter.

Le correctif a fini par être ennuyeux et chirurgical : démarrer WinRE, activer la journalisation de démarrage, identifier le dernier pilote d’affichage tiers chargé,
puis supprimer le package pilote hors ligne avec DISM. Après restauration du démarrage, ils ont verrouillé une version connue‑bonne
et désactivé les mises à jour automatiques de pilotes via une stratégie pour cette classe de périphériques jusqu’à tests approfondis.

Leçon postmortem : traitez les mises à jour de pilotes comme des changements d’OS. Si vous ne pouvez pas revenir en arrière proprement, vous ne « mettez pas à jour » : vous jouez à la roulette.

Mini-récit 2 (optimisation qui a mal tourné) : remplacement de pilotes de stockage pour « plus de performance »

Une petite entreprise SaaS a acheté de nouveaux NVMe pour quelques serveurs Windows sur site utilisés pour des artefacts de build.
Quelqu’un a trouvé un « pilote performance » fournisseur et un utilitaire de gestion promettant une meilleure gestion des files et une latence plus faible.
La fenêtre de changement était courte. L’argument était simple : « C’est le pilote recommandé du fournisseur. »

Le pilote s’est installé correctement et le serveur a redémarré une première fois sans problème. Puis, après un autre redémarrage, il a affiché INACCESSIBLE_BOOT_DEVICE.
WinRE pouvait voir le disque, mais Windows ne parvenait pas à monter le volume de démarrage à temps. C’est le type de panne qui vous donne envie d’un passe‑temps
comme la menuiserie, où au moins les outils sont honnêtes quant à leur dangerosité.

Ce qui s’est passé : le pilote fournisseur a modifié le comportement de la pile de stockage d’une manière qui interagissait mal avec la configuration du firmware du système.
Ce n’était pas « cassé » en laboratoire. C’était cassé dans leur environnement, avec leur BIOS et leur mode de démarrage.
L’« optimisation » a introduit une nouvelle chaîne de dépendances au démarrage.

La récupération s’est faite entièrement hors ligne : DISM a listé le pilote de classe stockage récemment installé ; l’équipe l’a retiré du driver store.
Quand le système a redémarré, ils ont conservé le pilote inbox Microsoft, et ont plutôt optimisé là où c’était plus sûr :
réglages système de fichiers, exclusions antivirus pour les répertoires d’artefacts, et cache applicatif.

Leçon postmortem : les ajustements de performance qui touchent aux chemins critiques de démarrage nécessitent des tests sur plusieurs cycles de redémarrage et états de firmware.
Un changement qui survit à un redémarrage n’est pas prouvé ; il a juste eu de la chance.

Mini-récit 3 (ennuyeux mais correct) : anneaux de déploiement et clés de récupération qui ont sauvé la mise

Une équipe IT d’entreprise gérait des milliers de portables avec chiffrement disque complet activé.
Ils avaient une habitude que personne ne vantait : déployer les pilotes par anneaux (pilot → early → broad),
et vérifier que les clés de récupération BitLocker étaient consignées et accessibles au personnel d’astreinte.

Une mise à jour de pilote Wi‑Fi est arrivée via un package interne. Sur un petit sous‑ensemble de machines avec une révision matérielle particulière,
elle a provoqué des BSOD peu après la connexion. Pas au boot, mais suffisamment tôt pour que les utilisateurs disent « ne démarre pas ».
L’anneau pilote l’a détecté en quelques heures.

La réponse de l’équipe n’a pas été héroïque. Elle a été procédurale : bloquer la mise à jour, publier un court runbook interne, et instruire les utilisateurs affectés à démarrer en Mode sans échec et restaurer le pilote.
Pour les machines qui ne pouvaient pas atteindre le Mode sans échec, l’astreinte a utilisé WinRE avec la clé de récupération, puis a désactivé le service du pilote hors ligne.

Ils sont rapidement revenus à l’état stable parce que deux éléments ennuyeux étaient déjà en place :
déploiements par anneaux (rayon d’impact limité) et accès garanti aux volumes chiffrés (escrow des clés).
Pas de supplications de dernière minute pour obtenir des clés. Pas de « pouvez‑vous vous connecter en admin » en va‑et‑vient.

Leçon postmortem : la différence entre un incident mineur et une panne de plusieurs jours est souvent un tableur ennuyeux
où quelqu’un a vérifié des prérequis des semaines plus tôt.

Erreurs courantes : symptôme → cause racine → correction

1) « Startup Repair n’a pas fonctionné, donc Windows est corrompu »

Symptôme : Boucle de réparation automatique ; « Startup Repair n’a pas pu réparer votre PC. »

Cause racine : Le démarrage est correct ; un pilote noyau plante après la mainlevée du chargeur de démarrage.

Correction : Utilisez l’Invite de commandes WinRE pour lister les pilotes récents (dism /get-drivers), supprimez le package suspect, ou désactivez le service hors ligne.

2) « J’ai supprimé le fichier .sys et maintenant c’est pire »

Symptôme : Nouveau code d’arrêt, ou Windows se plaint d’un pilote manquant ; la pile du périphérique échoue différemment.

Cause racine : Vous avez retiré le binaire mais laissé les références du service et du package INF.

Correction : Préférez la suppression du package (dism /remove-driver hors ligne ou pnputil /delete-driver en ligne). Si vous l’avez déjà supprimé, restaurez‑le depuis le driver store ou réinstallez un package connu‑bon.

3) « DISM ne trouve pas l’image »

Symptôme : Erreurs DISM en utilisant /image:C:\.

Cause racine : Mauvaise lettre de lecteur dans WinRE.

Correction : Utilisez diskpart → list vol pour identifier la partition Windows, puis utilisez la lettre correcte (souvent D:).

4) « J’ai désactivé un pilote de stockage et maintenant j’ai INACCESSIBLE_BOOT_DEVICE »

Symptôme : 0x7B après modification des valeurs Start du registre.

Cause racine : Vous avez désactivé le miniport/RAID/NVMe requis au lieu du module add‑on/filtre problématique.

Correction : Réactivez le pilote (remettez la valeur Start) et retirez plutôt le filtre ou le package tiers récemment ajouté ; utilisez un point de restauration si disponible.

5) « Le Mode sans échec affiche aussi un écran bleu ; je suis coincé »

Symptôme : Même le Mode sans échec échoue.

Cause racine : Pilote de démarrage, problème de pile de stockage, ou enforcement d’intégrité du code.

Correction : Utilisez le rollback hors ligne : DISM pour supprimer le package, désactivation du registre hors ligne. Envisagez la Restauration du système si elle est disponible et rapide.

6) « Le pilote revient après que je l’ai supprimé »

Symptôme : Après récupération, Windows Update réinstalle la même version ; BSOD revient.

Cause racine : Les mises à jour automatiques de pilotes réappliquent la version problématique.

Correction : Utilisez des politiques/réglages pour bloquer les mises à jour de pilotes pour cette classe de périphériques ou masquer cette mise à jour ; installez une version connue‑bonne et verrouillez‑la.

7) « WinRE demande la clé BitLocker et nous ne l’avons pas »

Symptôme : Impossible d’accéder à D:\Windows ou d’exécuter DISM ; volume verrouillé.

Cause racine : Volume OS chiffré et processus de clé de récupération manquant.

Correction : Récupérez la clé depuis le système d’escrow de l’organisation ou le compte Microsoft de l’utilisateur. Sans cela, vos options se limitent à des mesures destructrices.

8) « J’ai supprimé le pilote mais ça plante toujours »

Symptôme : Même code d’arrêt persiste.

Cause racine : Le pilote que vous avez supprimé n’était pas celui qui se chargeait en premier, ou il y a plusieurs composants (filtre + miniport + service).

Correction : Activez la journalisation de démarrage et inspectez ntbtlog.txt ; vérifiez les filtres de classe ; retirez/désactivez le composant réellement chargé.

Listes de contrôle / plan étape par étape

Checklist 1 : Séquence de récupération à risque minimal

1. Entrez dans WinRE (récupération automatique ou clé USB d’installation).
2. Notez le code d’arrêt et tout fichier .sys mentionné.
3. Ouvrez l’Invite de commandes. Identifiez la lettre du volume Windows via diskpart.
4. Vérifiez l’état BitLocker ; déverrouillez si nécessaire.
5. Essayez Startup Settings → Mode sans échec. S’il démarre, désinstallez/restaurez le pilote normalement.
6. Si le Mode sans échec échoue, listez les pilotes hors ligne avec DISM ; cherchez les pilotes non inbox récents correspondant au moment de la panne.
7. Supprimez le package pilote suspect hors ligne avec DISM.
8. Redémarrez. Si ça échoue encore, activez la journalisation de démarrage via bcdedit, reproduisez un échec, puis inspectez ntbtlog.txt.
9. Si le pilote identifié bloque toujours le démarrage, désactivez son service hors ligne (mettre Start=4 dans le bon control set).
10. Une fois démarré, stabilisez : installez un pilote connu‑bon, bloquez la mauvaise version de revenir, collectez dumps/logs pour l’analyse racine.

Checklist 2 : Si le code d’arrêt est INACCESSIBLE_BOOT_DEVICE (0x7B)

1. Supposez la voie de stockage. Ne désactivez pas des pilotes au hasard.
2. Utilisez DISM pour lister les pilotes de classe stockage et triez par date (mentalement, en regardant la sortie).
3. Supprimez d’abord le plus récent pilote tiers de stockage/filtre.
4. Si vous avez modifié le registre, vérifiez que vous n’avez pas désactivé le miniport requis.
5. Vérifiez les filtres de classe disque (UpperFilters/LowerFilters) et désactivez le service du filtre si nécessaire.
6. Ce n’est qu’ensuite que vous envisagez une réparation plus profonde (SFC/CHKDSK) si les indices le suggèrent.

Checklist 3 : Si le BSOD nomme un fichier .sys

1. Cherchez le fichier sur disque : D:\Windows\System32\drivers\name.sys.
2. Utilisez les infos DISM pour mapper le fichier à un package INF si possible.
3. Supprimez le package avec DISM (hors ligne) ou pnputil (Mode sans échec/en ligne).
4. Si la suppression échoue, désactivez le service hors ligne.
5. Démarrez, puis remplacez par une version connue‑bonne fournie par l’OEM ou Windows Update (contrôlé).

Blague #2 : « Réinstaller Windows » est l’équivalent IT de réparer une porte qui grince en déménageant.

Faits intéressants & contexte historique

• Les pilotes Windows sont souvent des services. Les pilotes noyau s’enregistrent typiquement sous HKLM\SYSTEM\...\Services avec un type Start contrôlant leur chargement.
• Les pilotes BOOT_START se chargent avant que vous puissiez vous connecter. Si un pilote de démarrage casse, même le Mode sans échec peut planter, car il a toujours besoin des pilotes de stockage et de classe de base.
• INACCESSIBLE_BOOT_DEVICE (0x7B) est un classique. Il survient quand Windows ne peut pas parler au volume de démarrage — souvent à cause de changements de pilote du contrôleur de stockage ou de pilotes filtres.
• Les packages pilotes vivent dans le driver store. Le driver store permet le rollback et des installations cohérentes, mais cela signifie aussi que « supprimer le .sys » n’enlève pas le package et peut créer des états partiels.
• DISM peut gérer des images hors ligne. Il a été conçu pour gérer des images Windows, et ce même moteur fonctionne pour un volume OS cassé depuis WinRE.
• Les pilotes filtres sont puissants et dangereux. Antivirus, chiffrement, sauvegarde et outils de stockage utilisent souvent des pilotes filtres ; un mauvais filtre peut casser des classes entières de périphériques.
• Les lettres de lecteur dans WinRE ne sont pas stables. Les environnements de récupération assignent des lettres différemment que votre OS en fonctionnement, d’où le piège fréquent du « C:\Windows » trompeur.
• BitLocker a changé la culture de réponse aux incidents. Le chiffrement est bon, mais il oblige les organisations à opérationnaliser l’escrow des clés et les workflows de récupération — sinon elles en paient le prix durant les pannes.
• Windows Error Reporting enregistre les bugchecks. Même quand les utilisateurs ne peuvent pas lire un BSOD, le système journalise souvent les infos de bugcheck et produit des minidumps pour analyse ultérieure.

Idée paraphrasée (Werner Vogels) : concevez des systèmes en supposant que des pannes arrivent, et concentrez‑vous sur la récupération comme fonctionnalité de première classe.

FAQ

1) Dois‑je utiliser la Restauration du système ou la suppression DISM en premier ?

Si vous avez un point de restauration et que vous avez besoin de rapidité, la Restauration du système est acceptable. Si vous voulez de la précision et une piste d’audit claire, utilisez DISM.
En environnement d’entreprise, je préfère DISM quand le pilote suspect est évident et critique pour le démarrage.

2) Pourquoi le Mode sans échec affiche‑t‑il encore un écran bleu ?

Le Mode sans échec est « minimal », pas « sans pilotes ». Les pilotes de démarrage, les pilotes de classe et certains composants de sécurité se chargent toujours.
Si le plantage se produit dans cet ensemble précoce, le Mode sans échec ne vous sauvera pas. Passez hors ligne : DISM ou désactivation du registre.

3) Puis‑je restaurer un pilote sans le désinstaller ?

Parfois. Si Windows peut démarrer, la fonction « Roll Back Driver » du Gestionnaire de périphériques peut revenir à une version antérieure.
Depuis WinRE hors ligne, vous retirez généralement le package problématique puis réinstallez une version connue‑bonne après le démarrage.

4) Que faire si DISM dit « The driver package could not be installed » ou que la suppression échoue ?

Si vous supprimez hors ligne et que cela échoue, vérifiez que le volume est déverrouillé (BitLocker) et que vous pointez vers le bon chemin d’image.
Si ça échoue toujours, désactivez le service du pilote hors ligne (mettre Start=4) pour démarrer le système, puis nettoyez depuis l’intérieur de Windows.

5) Est‑ce sûr de désactiver un service pilote en mettant Start=4 ?

C’est sûr quand vous désactivez un pilote clairement non essentiel (helper GPU, filtre tiers, périphérique optionnel).
C’est risqué quand vous le faites pour des pilotes de contrôleur de stockage. Si vous désactivez le mauvais, Windows ne pourra pas monter le volume de démarrage.

6) Mon BSOD ne nomme pas de pilote. Comment trouver le coupable ?

Utilisez les journaux d’événements hors ligne pour obtenir les codes de bugcheck, vérifiez les minidumps, activez la journalisation de démarrage, et recherchez les installations récentes de pilotes via DISM.
Corrélez par la temporalité : qu’est‑ce qui a changé juste avant le début des pannes.

7) Après la récupération, comment empêcher Windows Update de réinstaller le mauvais pilote ?

En environnement géré, utilisez des contrôles de politique pour bloquer les mises à jour de pilotes ou restreindre par classe de périphérique.
Sur des machines autonomes, vous pouvez désactiver les mises à jour automatiques de pilotes et installer une version OEM connue‑bonne.
L’objectif est de casser le cycle « réinstaller → redémarrer → crash ».

8) La suppression d’un package pilote supprime‑t‑elle mes données ?

La suppression d’un package pilote ne devrait pas toucher les données utilisateur. Le risque est opérationnel : retirer le mauvais pilote de stockage peut empêcher le démarrage.
C’est pourquoi vous identifiez le bon volume Windows, confirmez la classe du pilote, et changez une chose à la fois.

9) Si je ne peux pas déverrouiller BitLocker, existe‑t‑il une option non destructive ?

Pas vraiment. Sans la clé de récupération, vous ne pouvez pas accéder au volume OS chiffré pour retirer des pilotes ou récupérer des logs.
Vos options se résument à « obtenir la clé » ou « effacer et reconstruire ». C’est pour cela que l’escrow des clés n’est pas optionnel.

10) Réinstaller Windows est‑ce parfois la bonne solution ?

Oui — quand le système est jetable, ou quand vous avez perdu la clé de chiffrement, ou quand l’OS est vraiment irrécupérable.
Mais pour une boucle de démarrage causée par un pilote sur une machine avec un état précieux, réinstaller est un échec de processus, pas une stratégie.

Conclusion : étapes suivantes pour éviter la récidive

Restaurer un mauvais pilote depuis le mode de récupération est moins une question de sorcellerie que de discipline :
identifiez le volume Windows, capturez les preuves, supprimez ou désactivez la chose précise qui se charge et plante, puis vérifiez le démarrage deux fois.
DISM et les éditions hors ligne du registre sont les outils fiables quand le Mode sans échec et les points de restauration ne coopèrent pas.

Une fois de retour en session normale, ne dites pas « c’est fini ». Faites le suivi ennuyeux :
collectez le minidump, mappez le .sys coupable au package pilote, et empêchez la mauvaise version de se réinstaller.
Puis testez votre procédure de rollback pendant que vous êtes calme — pas lors de la prochaine panne quand votre seul outil est la panique et un café que vous avez oublié de boire.

Étapes pratiques à faire aujourd’hui

• Vérifiez que les clés de récupération BitLocker sont consignées et accessibles par l’astreinte.
• Adoptez des anneaux de déploiement pour les pilotes : pilote d’abord, puis élargir.
• Gardez une clé USB d’installation Windows bootable (ou équivalent) disponible pour les machines critiques.
• Documentez un runbook interne pour la suppression de pilotes hors ligne avec DISM et la désactivation des services hors ligne.
• Après la récupération, verrouillez une version de pilote connue‑bonne et bloquez le mécanisme de mise à jour problématique.