Rien ne vous vieillit plus vite qu’une machine Windows qui ne démarre plus juste après « une mise à jour rapide du pilote ». L’écran de démarrage bloque, il redémarre, peut‑être vous obtenez un écran bleu avec un alphabet d’acronymes, et soudain votre portable est une horloge très chère.
La méthode sûre n’est pas « appuyer sur des boutons au hasard jusqu’à ce que ça marche ». La méthode sûre consiste à : préserver les preuves, éviter de rendre le système moins récupérable, identifier le pilote qui a cassé le démarrage, et restaurer avec des étapes contrôlées hors ligne. Vous voulez un changement propre, pas cinq changements désespérés.
Ce qui a probablement changé : pilotes pouvant bloquer le démarrage
« Pilote » est trop large. Certains pilotes sont décoratifs. D’autres sont porteurs. Quand Windows ne démarre pas, supposez que la défaillance appartient à l’une de ces catégories :
- Pilotes de stockage critiques pour le démarrage : SATA/AHCI, NVMe, RAID, Intel RST, filtres de stockage du fournisseur. Si ceux‑ci dysfonctionnent, l’OS ne voit plus son propre disque. Attendez‑vous à des erreurs comme INACCESSIBLE_BOOT_DEVICE.
- Pilotes GPU : un pilote d’affichage défectueux peut provoquer un écran noir après le logo, parfois avec un système fonctionnel en arrière‑plan. Il peut aussi déclencher des bugchecks.
- Pilotes noyau et filtres de sécurité : protection endpoint, DLP, chiffrement, filtres système de fichiers. Quand ceux‑ci cassent, ils cassent fort—souvent tôt dans le démarrage.
- Pilotes de pile réseau ou filtres VPN : généralement pas critiques au démarrage, mais ils peuvent provoquer des blocages, de longs délais ou des échecs en mode sans échec s’ils sont configurés pour un chargement tôt.
- Pilotes de chipset et ACPI plateforme : peuvent provoquer des blocages étranges ou des problèmes de gestion d’alimentation qui donnent l’impression d’une machine morte.
Quand vous faites un rollback, votre travail est de trouver le paquet de pilote ou le service spécifique qui a changé, pas de « réinitialiser Windows ». La réinitialisation est un dernier recours. Le rollback est une chirurgie.
Playbook de diagnostic rapide (premier/deuxième/troisième)
En cas d’incident, vous ne « dépannez » pas : vous triez. Voici le playbook rapide que j’utilise lorsque Windows ne démarre pas après un changement de pilote.
Premier : établir la classe de défaillance
- Écran bleu avec un code clair (par ex., INACCESSIBLE_BOOT_DEVICE, SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) : probablement pilote critique au démarrage ou filtre en mode noyau.
- Boucle de démarrage, pas d’interface : pilote de tout début de démarrage, données BCD, ou invite de clé de chiffrement disque qui ne s’affiche pas.
- Écran noir après le logo : souvent le pilote GPU ou un problème de démarrage du shell ; parfois le système a démarré mais l’affichage est invisible.
- « Préparation de la réparation automatique » indéfiniment : peut être des erreurs disque, mais aussi un service/pilote bloqué pendant le démarrage.
Second : choisir le mécanisme de rollback le moins risqué disponible
- Restauration système si vous avez un point de restauration récent et que le disque est sain. C’est un rollback « en lot » réversible.
- Paramètres de démarrage → Mode sans échec si ça charge. Puis restauration via le Gestionnaire de périphériques ou désinstallation du paquet pilote.
- Invite de commandes WinRE pour un rollback hors ligne (DISM, éditions du registre hors ligne, analyse des logs). C’est l’option adulte quand le mode sans échec échoue.
Troisième : identifier le coupable avant de supprimer quoi que ce soit
Ne supprimez pas des pilotes au hasard. Examinez les logs hors ligne et le magasin de pilotes. Si vous retirez le mauvais pilote de stockage, vous pouvez transformer une boucle redémarrage récupérable en une situation totalement non amorçable.
Idée paraphrasée (attribuée) : Gene Kim soutient souvent que la fiabilité vient de modèles de récupération disciplinés et reproductibles—pas d’exploits héroïques in extremis.
Règles de sécurité : ne compliquez pas la récupération
Ces règles vous empêchent de transformer un problème réparable en « tout réinstaller ».
- Cessez de faire des changements avant de collecter des preuves. Les logs et horodatages importent. Si vous redémarrez dix fois et lancez trois outils de réparation, vous effacerez la piste.
- N’essayez pas de désactiver des services au hasard « pour voir ». Windows a des dépendances comme une tour de Jenga. Retirez la mauvaise brique et vous découvrirez de nouvelles formes de douleur.
- Sachez si BitLocker est activé. Si le volume OS est chiffré, l’accès hors ligne nécessite la clé de récupération. Planifiez cela avant de commencer.
- Préférez la suppression d’un paquet pilote spécifique plutôt qu’un « reset/refresh » global. Les changements ciblés sont testables et réversibles.
- En cas de doute : sauvegardez d’abord les données. Si vous pouvez atteindre une invite et voir le disque, vous pouvez généralement sauvegarder les fichiers critiques avant toute action risquée.
Blague n°1 : Une mise à jour de pilote sans plan de rollback, c’est comme déployer un vendredi—techniquement possible, moralement discutable.
Outils que vous utiliserez dans WinRE (et pourquoi)
WinRE (Windows Recovery Environment) est votre console d’opérations hors ligne. Ce n’est pas joli, mais c’est efficace.
- Réparation du démarrage : répare parfois le BCD/chaîne de démarrage. Elle n’aura pas pour effet de désinstaller un pilote défectueux, mais peut restaurer les mécanismes de démarrage.
- Restauration système : restaure fichiers système et pilotes à un point de restauration. Super quand il existe et que le système de fichiers est intact.
- Invite de commandes : pour DISM, bcdedit, diskpart et l’analyse des logs.
- Éditeur du Registre (regedit) : peut charger des ruches hors ligne pour désactiver un service pilote sans démarrer Windows.
Tâches pratiques (commandes + sortie + décision)
Ci‑dessous des tâches éprouvées sur le terrain. Chacune inclut une commande, à quoi ressemble une sortie réaliste, et la décision que vous prenez en fonction de cela. Exécutez‑les depuis l’invite de commandes WinRE (ou depuis « Réparer l’ordinateur » → Invite de commandes). Les sorties varient selon le système ; l’important est ce que cela signifie.
Task 1: Identify the Windows partition letter (WinRE lies about drive letters)
cr0x@server:~$ diskpart
DISKPART> list vol
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D WinRE NTFS Partition 980 MB Healthy Hidden
Volume 1 C FAT32 Partition 100 MB Healthy System
Volume 2 E Windows NTFS Partition 476 GB Healthy
DISKPART> exit
Signification : Votre installation Windows est sur E:, pas sur C:. C’est normal dans WinRE.
Décision : Utilisez E:\Windows pour les chemins hors ligne dans chaque commande ci‑dessous. Si vous vous trompez, DISM et les commandes reg agiront sur le mauvais volume—ce qui est une catégorie particulière d’échec.
Task 2: Confirm you’re targeting the right Windows directory
cr0x@server:~$ dir E:\Windows
Volume in drive E is Windows
Volume Serial Number is 3A1B-9C2D
Directory of E:\Windows
02/04/2026 08:12 AM <DIR> .
02/04/2026 08:12 AM <DIR> ..
01/12/2026 06:40 PM <DIR> System32
01/12/2026 06:40 PM <DIR> INF
01/12/2026 06:40 PM <DIR> Logs
Signification : Cela ressemble à un vrai répertoire Windows, pas à une partition de récupération aléatoire.
Décision : Continuez. Si System32 ou INF manque, revérifiez les lettres de lecteur.
Task 3: Check BitLocker status before you get clever
cr0x@server:~$ manage-bde -status E:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Volume E: [Windows]
[OS Volume]
Size: 475.86 GB
BitLocker Version: 2.0
Conversion Status: Fully Encrypted
Percentage Encrypted: 100.0%
Protection Status: Protection On
Lock Status: Locked
Identification Field: Unknown
Key Protectors:
Numerical Password
Signification : Le volume OS est chiffré et actuellement verrouillé.
Décision : Vous devez le déverrouiller avec la clé de récupération avant que DISM puisse accéder à Windows hors ligne. S’il est déjà déverrouillé, vous pouvez continuer.
Task 4: Unlock the encrypted OS volume (if needed)
cr0x@server:~$ manage-bde -unlock E: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
The password successfully unlocked volume E:.
Signification : Vous avez désormais un accès lecture/écriture hors ligne.
Décision : Continuez avec l’analyse des logs et le rollback des pilotes. Si le déverrouillage échoue, arrêtez et obtenez la clé correcte ; la force brute n’est pas une stratégie.
Task 5: Pull recent boot failure clues from offline event logs (quick and dirty)
cr0x@server:~$ wevtutil qe System /lf:true /rd:true /c:15 /f:text /q:"*[System[(Level=2)]]" /ms:5000
Event[0]:
Log Name: System
Source: Service Control Manager
Date: 2026-02-04T08:15:02.000
Event ID: 7000
Level: Error
Description:
The iaStorAfs service failed to start due to the following error:
The system cannot find the file specified.
Signification : Un service lié au stockage (iaStorAfs) échoue à démarrer. C’est un indice fort pour un mauvais appariement Intel RST/RAID/AHCI ou une suppression.
Décision : Considérez cela comme critique pour le démarrage. Vous n’allez pas désinstaller des éléments au hasard ; vous ciblez la pile de stockage.
Task 6: Inspect SetupAPI driver install logs for the last driver changes
cr0x@server:~$ type E:\Windows\INF\setupapi.dev.log | findstr /i /c:"Installing device" /c:"Driver Package" /c:"Failed" | more
>>> [Driver Package Install - oem42.inf]
>>> Section start 2026/02/03 19:22:11.512
cmd: "C:\Windows\System32\drvinst.exe" /i /l
sto: Driver Store Path: C:\Windows\System32\DriverStore\FileRepository\iaahcic.inf_amd64_8a1c3d3b0a0a3d2e
!!! sto: Failed to delete driver package 'oem41.inf'. Error = 0x00000002
Signification : Un paquet pilote a été installé récemment, et il implique des composants AHCI/stockage. De plus, une suppression précédente a partiellement échoué.
Décision : Prévoyez de supprimer/rollback le dernier paquet de stockage fautif, mais soyez prudent : supprimer le seul pilote de stockage fonctionnel équivaut à un brique instantanée.
Task 7: List third-party drivers in the offline image with DISM
cr0x@server:~$ dism /image:E:\ /get-drivers /format:table
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22631.3007
Obtained 62 driver package(s) installed in the image.
Published Name Original File Name Inbox Class Name Provider Name Date Version
------------------ ------------------ ----- ------------------ --------------------- ---------- -------------
oem41.inf iaStorAC.inf No SCSIAdapter Intel Corporation 01/18/2026 19.5.1.1040
oem42.inf iaahcic.inf No SCSIAdapter Intel Corporation 02/03/2026 20.0.0.1038
oem12.inf nvme.inf No SCSIAdapter Vendor Storage Labs 02/03/2026 3.2.7.0
oem33.inf oemgpu.inf No Display Vendor GPU Inc. 02/03/2026 31.0.15.5123
Signification : Plusieurs pilotes de type stockage ont été mis à jour autour du moment de la défaillance. oem42.inf et oem12.inf sont suspects car datés la veille de l’échec de démarrage.
Décision : Préférez supprimer le paquet le plus récent corrélé avec le code/log d’échec. Si l’erreur est INACCESSIBLE_BOOT_DEVICE, commencez par le stockage ; si écran noir, commencez par l’affichage.
Task 8: Get details for a specific driver package before removing it
cr0x@server:~$ dism /image:E:\ /get-driverinfo /driver:oem42.inf
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Driver package information:
Published Name : oem42.inf
Original File Name : iaahcic.inf
Inbox : No
Class Name : SCSIAdapter
Provider Name : Intel Corporation
Date : 02/03/2026
Version : 20.0.0.1038
Boot Critical : Yes
Signification : DISM indique que c’est critique pour le démarrage. C’est votre drapeau « ne soyez pas imprudent ».
Décision : Si vous le supprimez, il faut être sûr que l’ancien pilote fonctionnel reste et est activé. Envisagez de désactiver le service d’abord (plus sûr) plutôt que de supprimer immédiatement le paquet.
Task 9: Try the least destructive change—disable a problematic driver service in the offline registry
Nous allons désactiver un service en réglant son type de démarrage sur 4 (Désactivé). Vous le faites hors ligne, donc Windows ne le chargera jamais pendant le démarrage.
cr0x@server:~$ reg load HKLM\OFFLINE_SYSTEM E:\Windows\System32\Config\SYSTEM
The operation completed successfully.
cr0x@server:~$ reg query "HKLM\OFFLINE_SYSTEM\ControlSet001\Services\iaStorAfs" /v Start
HKEY_LOCAL_MACHINE\OFFLINE_SYSTEM\ControlSet001\Services\iaStorAfs
Start REG_DWORD 0x0
cr0x@server:~$ reg add "HKLM\OFFLINE_SYSTEM\ControlSet001\Services\iaStorAfs" /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.
cr0x@server:~$ reg unload HKLM\OFFLINE_SYSTEM
The operation completed successfully.
Signification : Le service du pilote était configuré pour démarrer au boot (0x0) et est maintenant désactivé (4).
Décision : Redémarrez et testez. Si la machine démarre, vous avez confirmé le coupable. Ensuite vous pouvez effectuer un rollback propre depuis Windows.
Task 10: If disabling works, remove the driver package cleanly (offline) to prevent re-enable surprises
cr0x@server:~$ dism /image:E:\ /remove-driver /driver:oem42.inf
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22631.3007
Searching for driver package to remove...
Removing 1 driver package(s) from the image...
[==========================100.0%==========================]
The operation completed successfully.
Signification : Le paquet est supprimé du magasin de pilotes hors ligne.
Décision : Redémarrez. Si vous obtenez INACCESSIBLE_BOOT_DEVICE maintenant, vous avez retiré quelque chose dont Windows avait besoin et vous devez restaurer le paquet (ou injecter un pilote fonctionnel). C’est pourquoi nous préférons désactiver d’abord.
Task 11: Add (inject) a known-good driver package offline
Parfois vous devez ajouter un pilote—surtout pour les contrôleurs de stockage. Mettez le .inf et les fichiers associés sur une clé USB, par ex. F:\drivers\iastor\.
cr0x@server:~$ dism /image:E:\ /add-driver /driver:F:\drivers\iastor\ /recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22631.3007
Searching for driver packages to install...
Installing 1 of 2 - F:\drivers\iastor\iaStorAC.inf: The driver package was successfully installed.
Installing 2 of 2 - F:\drivers\iastor\iaStorAfs.inf: The driver package was successfully installed.
The operation completed successfully.
Signification : Vous avez injecté des pilotes dans l’image hors ligne afin que Windows puisse voir son disque/contrôleur au démarrage.
Décision : Si le système plantait auparavant avec une erreur de stockage au démarrage, c’est une solution à forte probabilité de succès. Redémarrez et vérifiez.
Task 12: Verify Windows system file integrity offline (after driver surgery)
cr0x@server:~$ sfc /scannow /offbootdir=E:\ /offwindir=E:\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.
Signification : Les fichiers système sont intacts ; vous n’avez vraisemblablement pas corrompu des binaires Windows fondamentaux en réparant les pilotes.
Décision : Si SFC signale une corruption qu’il ne peut pas corriger, suivez avec la réparation du magasin de composants DISM (tâche suivante).
Task 13: Repair component store offline if SFC complains
cr0x@server:~$ dism /image:E:\ /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
Image Version: 10.0.22631.3007
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.
Signification : Le magasin de composants Windows est réparé. Cela peut être important si une installation de pilote a partiellement mis à jour des composants système.
Décision : Redémarrez. Si le démarrage échoue toujours, retournez aux logs—n’enchaînez pas les commandes de réparation comme si c’était une machine à sous.
Task 14: Force Safe Mode once (when normal boot loops too fast)
Parfois vous pouvez forcer le mode sans échec via le BCD. Vous n’êtes pas marié au mode sans échec ; vous l’utilisez juste pour désinstaller le pilote dans un environnement plus clément.
cr0x@server:~$ bcdedit /store E:\Boot\BCD /enum
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=C:
path \EFI\Microsoft\Boot\bootmgfw.efi
Windows Boot Loader
-------------------
identifier {default}
device partition=E:
path \Windows\system32\winload.efi
osdevice partition=E:
systemroot \Windows
cr0x@server:~$ bcdedit /store E:\Boot\BCD /set {default} safeboot minimal
The operation completed successfully.
Signification : Le prochain démarrage devrait essayer le mode sans échec (minimal).
Décision : Redémarrez et tentez d’atteindre le mode sans échec. Après avoir corrigé le pilote, supprimez le paramètre safeboot sinon vous resterez en mode sans échec indéfiniment (ce qui est drôle une seule fois).
Task 15: Remove the Safe Mode forced boot flag after recovery
cr0x@server:~$ bcdedit /deletevalue {default} safeboot
The operation completed successfully.
Signification : Le comportement de démarrage normal est restauré.
Décision : Si vous oubliez cela, quelqu’un ouvrira un ticket « Windows est bloqué en mode sans échec », et il aura raison.
Task 16: Read offline crash dumps pointers and Boot log hints
Même si vous ne pouvez pas analyser un dump complètement dans WinRE, vous pouvez souvent trouver des miettes pertinentes.
cr0x@server:~$ dir E:\Windows\Minidump
Volume in drive E is Windows
Directory of E:\Windows\Minidump
02/04/2026 08:14 AM 1,024,512 020426-11234-01.dmp
cr0x@server:~$ type E:\Windows\ntbtlog.txt | findstr /i /c:"Loaded driver" /c:"Did not load driver" | more
Loaded driver \SystemRoot\System32\drivers\CLASSPNP.SYS
Did not load driver \SystemRoot\System32\drivers\iaStorAfs.sys
Loaded driver \SystemRoot\System32\drivers\disk.sys
Signification : Le journal de démarrage indique qu’un pilote spécifique n’a pas été chargé. Ça peut être le coupable ou la victime.
Décision : Corrélez cela avec les journaux d’événements et les logs SetupAPI. Si le pilote manquant est critique pour le démarrage et absent, il faudra peut‑être l’injecter (Tâche 11) plutôt que le supprimer.
Stratégies de rollback : choisir la moins invasive qui fonctionne
Restaurer un pilote sans démarrer Windows consiste à contrôler le rayon d’action. Voici comment choisir votre méthode.
Stratégie A: Restauration système (meilleur quand possible)
Si les points de restauration sont activés et que la panne a commencé juste après une mise à jour de pilote, la Restauration système est le bouton « remettre l’état du système ». Elle restaure souvent les paquets pilotes, les clés de registre et les fichiers système pertinents en une seule opération.
À utiliser quand : le disque est sain, vous pouvez accéder à WinRE, et la chronologie est évidente (« ça a cassé après la mise à jour d’hier »).
À éviter quand : vous suspectez une corruption disque ou des problèmes de clé BitLocker ; vous perdrez du temps et pourriez compliquer la récupération si la restauration échoue en cours de route.
Stratégie B: Mode sans échec → Rollback via Gestionnaire de périphériques (simple, mais pas toujours disponible)
Si vous pouvez démarrer en mode sans échec, utilisez le bouton de restauration intégré dans le Gestionnaire de périphériques ou désinstallez le périphérique/le paquet pilote. C’est la voie conviviale.
À utiliser quand : le mode sans échec se charge et le pilote fautif n’est pas requis là‑bas (beaucoup de pilotes GPU retombent sur un pilote de base).
À éviter quand : le mode sans échec plante aussi. C’est courant avec les pilotes boot‑start et les filtres de sécurité.
Stratégie C: Suppression de pilote hors ligne avec DISM (chirurgical, fiable)
DISM agit sur l’image Windows hors ligne. Vous pouvez lister les paquets de pilotes, les inspecter, et en supprimer un. C’est l’épine dorsale de la méthode sûre.
À utiliser quand : vous savez quel paquet est fautif et vous avez un filet de sécurité (ancien pilote ou possibilité d’injecter un pilote sain).
À éviter quand : vous devinez pour des pilotes de stockage sans plan de récupération. Si vous supprimez la seule pile de stockage fonctionnelle, vous obtiendrez instantanément une erreur de périphérique de démarrage.
Stratégie D: Désactivation hors ligne du service pilote (tactique « l’éteindre et voir si ça revient »)
Ceci est sous‑estimé. Désactiver le service peut confirmer le coupable avec un changement minimal et peu permanent. Si le système démarre, vous pourrez faire une désinstallation propre ultérieurement.
À utiliser quand : vous n’êtes pas sûr à 100% quel paquet est en cause, ou le pilote est marqué critique pour le démarrage.
À éviter quand : le pilote est requis pour voir le disque. Désactiver le mauvais pilote de stockage peut être catastrophique ; lisez d’abord les logs.
Stratégie E: Rétablir le BCD/les bascules Safe Mode (quand les options de démarrage bloquent)
Parfois le « problème de pilote » est en réalité une option de démarrage activée (safeboot, debug, nointegritychecks) ou un BCD corrompu. Réparer le BCD ne fera pas de rollback de pilote, mais peut vous permettre d’atteindre un mode où vous pouvez le faire.
Pièges liés au stockage et aux pilotes critiques de démarrage (NVMe/RAID/BitLocker)
Les pilotes de stockage sont l’endroit où « supprimez‑le simplement » tourne mal. Quelques réalités :
- INACCESSIBLE_BOOT_DEVICE n’est pas une suggestion. Cela signifie que Windows ne peut pas communiquer avec le contrôleur de disque avec les pilotes qu’il tente d’utiliser.
- Changer le mode de stockage BIOS (AHCI ↔ RAID) change le pilote requis. Si quelqu’un a modifié un paramètre BIOS pendant le dépannage, vous poursuivez peut‑être la mauvaise piste. Rétablissez le mode d’abord, puis le pilote.
- Les pilotes NVMe « fournisseur » peuvent être pires que le pilote inbox de Microsoft. Les pilotes NVMe fournisseurs optimisent parfois pour les benchs. La fiabilité du démarrage n’est pas un benchmark.
- BitLocker vous punira pour les changements matériels/de démarrage. Même des corrections « sûres » peuvent déclencher des invites de clé de récupération. Prévoyez‑le.
En pratique : si le stockage est suspecté, préférez désactivation d’abord, puis injection d’un pilote connu‑bon, puis suppression du mauvais. C’est plus lent. C’est plus sûr. Vous essayez de restaurer le démarrage, pas de gagner une course.
Trois mini‑histoires d’entreprise issues du terrain
Mini‑histoire 1 : La panne causée par une fausse supposition
Dans une entreprise de taille moyenne avec une flotte importante de postes Windows, une équipe a déployé une mise à jour du pilote du contrôleur de stockage via leur plateforme de gestion. Les notes de version du fournisseur disaient « améliore la stabilité ». Cette phrase est l’équivalent IT de « faites‑moi confiance ».
La supposition était simple : « C’est une mise à jour de pilote de stockage ; Windows Update ne la proposerait que si elle est compatible. » Raisonnable en apparence. Aussi fausse. La mise à jour s’est appliquée à un sous‑ensemble de machines avec une révision de contrôleur plus ancienne, et elle a introduit un décalage entre le pilote/service boot‑start.
Le lendemain matin, le helpdesk a vu une vague : boucles de démarrage et INACCESSIBLE_BOOT_DEVICE. Les premiers intervenants ont essayé l’habituel : Réparation du démarrage, puis redémarrages répétés, puis « peut‑être le mode sans échec ». Le mode sans échec a échoué parce que le même pilote se chargeait aussi.
Ce qui a réparé n’était pas magique. Un technicien a démarré en WinRE, listé les pilotes hors ligne avec DISM, constaté que l’INF OEM le plus récent sur les machines affectées était le paquet de stockage, et a désactivé le service associé dans le registre hors ligne. Les machines ont recommencé à démarrer. Ensuite ils ont restauré proprement depuis Windows et bloqué cette version du pilote.
La leçon n’était pas « ne jamais mettre à jour les pilotes ». La leçon était « ne supposez pas que la distribution implique sécurité, et ne traitez pas les mises à jour de pilotes critiques pour le démarrage comme routinières ».
Mini‑histoire 2 : L’optimisation qui s’est retournée
Une autre entreprise—axée performance—décida d’« optimiser le temps de démarrage » sur les portables de développement. Quelqu’un trouva une branche de pilote GPU fournisseur pour faible latence et la poussa à l’échelle. Le démarrage paraissait plus rapide sur quelques machines, et tout le monde adore une victoire.
Puis des pannes étranges ont commencé : écrans noirs intermittents après le logo Windows. Le système était en réalité démarré ; on entendait le son de connexion et la gestion distante pouvait se connecter, mais l’affichage local restait aveugle. Les développeurs redémarraient en force sans cesse, ce qui a ajouté de la corruption de fichiers.
L’« optimisation » avait changé le comportement d’initialisation du pilote d’affichage sur certains docks et moniteurs externes. Ce n’était pas un crash cohérent ; c’était un problème de timing et de handshake. Ce sont les pires car la loterie des redémarrages « corrige » parfois, ce qui érode la confiance dans la causalité.
L’approche de récupération qui a fonctionné était ennuyeuse : démarrer WinRE, forcer le mode sans échec via BCD, désinstaller le paquet GPU, et laisser Windows retomber sur le pilote d’affichage basique. Le démarrage est redevenu fiable. Plus tard ils ont testé une autre version du pilote GPU dans un anneau canari et validé sur les modèles de dock problématiques.
Optimiser la performance, c’est bien. L’appliquer au chemin de démarrage sans contrôles de rollback, c’est découvrir la différence entre « rapide » et « fragile ».
Mini‑histoire 3 : La pratique ennuyeuse qui a sauvé la mise
Une société financière avec des contrôles stricts avait une pratique que personne n’aimait : chaque mise à jour de pilote devait être étiquetée avec un ticket de changement, et pour les classes critiques de démarrage (stockage, filtres de sécurité) le déploiement nécessitait un groupe pilote et un plan de rollback.
Un mois, un produit de sécurité endpoint a publié une mise à jour de pilote filtre noyau. Le groupe pilote l’a détectée : un petit pourcentage de machines ne démarraient plus après la mise à jour, de façon cohérente. L’équipe sécurité voulait pousser un hotfix et passer à autre chose. L’équipe postes a insisté pour des preuves : logs hors ligne, inspection du magasin de pilotes, et un runbook WinRE de rollback reproductible.
Quand le fournisseur a confirmé le bug et fourni un pilote corrigé, l’entreprise a déployé la version corrigée d’abord au groupe pilote. Ensuite seulement ils ont étendu le déploiement. L’échec initial a été contenu aux machines désignées pour absorber ce risque.
Deux choses ont rendu cela possible : (1) les clés de récupération BitLocker étaient consignées et accessibles au personnel autorisé, et (2) les techniciens savaient utiliser DISM hors ligne, pas seulement « cliquer jusqu’à ce que ça démarre ».
Personne n’a eu besoin d’un récit héroïque. Ils ont eu une semaine tranquille. C’est le bon résultat.
Faits et historique intéressants (court, concret)
- Fait 1 : Les pilotes Windows sont typiquement empaquetés en
.inf+ binaires et mis en scène dans le Driver Store pour que Windows puisse réinstaller les périphériques sans média externe. - Fait 2 : Un pilote « boot‑start » peut se charger avant la session graphique—ce qui signifie qu’un mauvais pilote peut casser le démarrage avant que vous voyiez un écran de connexion.
- Fait 3 : Le Driver Store se trouve sous
\Windows\System32\DriverStore\FileRepositoryet peut contenir plusieurs versions de pilotes similaires côte à côte. - Fait 4 : DISM a commencé comme outil d’imagerie pour le déploiement, mais c’est maintenant un des outils hors ligne les plus utiles pour réparer une installation Windows cassée.
- Fait 5 : Windows a longtemps pris en charge Dernière configuration valide connue (plus en évidence dans les versions plus anciennes), mais la récupération moderne s’appuie beaucoup sur WinRE et les points de restauration.
- Fait 6 : « INACCESSIBLE_BOOT_DEVICE » est souvent déclenché non seulement par des pilotes, mais aussi par des changements de mode de stockage BIOS et des pilotes manquants après une mise à jour du microprogramme.
- Fait 7 : Le mode sans échec n’est pas « sans pilotes ». C’est « un ensemble minimal de pilotes », et les pilotes de stockage boot‑start se chargent toujours car l’OS a besoin que le disque existe.
- Fait 8 : Beaucoup de produits de sécurité endpoint reposent sur des pilotes filtre système de fichiers ; un mauvais filtre peut empêcher le démarrage fiable des services et même du shell.
- Fait 9 : Windows Update peut distribuer des pilotes tiers, ce qui est pratique jusqu’à ce qu’un fournisseur publie un paquet problématique et que vous découvriez que « automatique » n’est pas synonyme de « sûr ».
Erreurs courantes : symptôme → cause racine → correction
Cette section vous dit quoi ne pas faire, parce que vous serez tenté.
1) Symptom: INACCESSIBLE_BOOT_DEVICE right after a driver update
- Cause racine : Mismatch du pilote du contrôleur de stockage, pilote critique de démarrage supprimé/désactivé, ou mode de stockage BIOS changé.
- Correction : Dans WinRE, vérifiez l’historique du mode BIOS si possible, puis utilisez DISM pour lister les pilotes de type stockage et soit désactivez le nouveau service soit injectez un pilote connu‑bon (Tâches 7–11).
2) Symptom: Black screen after logo, but disk activity continues
- Cause racine : Échec d’initialisation du pilote GPU ou problème de handshake moniteur/dock déclenché par un nouveau pilote d’affichage.
- Correction : Forcez le mode sans échec via BCD (Tâche 14), désinstallez le pilote GPU, redémarrez, puis installez une version stable ultérieurement. Si vous ne pouvez pas atteindre le mode sans échec, supprimez le paquet d’affichage hors ligne avec DISM.
3) Symptom: Automatic Repair loop, never reaches desktop
- Cause racine : Service/pilote bloqué au début du démarrage, parfois filtres de sécurité ou filtres de stockage.
- Correction : Examinez les journaux d’événements hors ligne et les logs SetupAPI (Tâches 5–6). Désactivez le service suspect hors ligne (Tâche 9). Ensuite seulement envisagez de supprimer des paquets.
4) Symptom: Safe Mode also crashes or loops
- Cause racine : Le pilote problématique se charge toujours en mode sans échec (pilotes boot‑start de stockage/sécurité), ou le système plante avant que le mode sans échec puisse diverger.
- Correction : Cessez de compter sur le mode sans échec. Utilisez DISM hors ligne et des éditions de registre hors ligne. Désactivez le service pilote et redémarrez.
5) Symptom: DISM says “The system cannot find the path specified”
- Cause racine : Vous avez ciblé la mauvaise lettre de lecteur dans WinRE, ou le volume est verrouillé par BitLocker.
- Correction : Utilisez diskpart pour identifier les volumes (Tâche 1) et manage-bde pour déverrouiller (Tâches 3–4). Puis réessayez.
6) Symptom: You removed a driver and now boot is worse
- Cause racine : Vous avez supprimé un pilote critique pour le démarrage sans garantir une alternative fonctionnelle dans l’image.
- Correction : Injectez le paquet pilote connu‑bon hors ligne (Tâche 11). Si vous ne l’avez pas, vous pourriez avoir besoin du média fournisseur ou de copier depuis une machine similaire.
7) Symptom: After recovery, Windows keeps booting to Safe Mode
- Cause racine : Vous avez forcé le mode sans échec via le BCD et oublié de supprimer le drapeau.
- Correction : Supprimez la valeur
safeboot(Tâche 15).
Blague n°2 : Si vous « avez réparé » en redémarrant jusqu’à ce que ça marche, vous n’avez pas réparé—vous avez négocié une trêve temporaire.
Listes de contrôle / plan étape par étape
Checklist A: The safe method (recommended order)
- Accédez à WinRE (Réparation automatique, clé de récupération, ou média d’installation Windows).
- Identifiez la lettre du volume Windows avec diskpart (Tâche 1) et vérifiez avec
dir(Tâche 2). - Vérifiez BitLocker et déverrouillez si nécessaire (Tâches 3–4).
- Collectez les preuves :
- Erreurs du journal Système (Tâche 5)
- Chronologie d’installation SetupAPI (Tâche 6)
- Indices du journal de démarrage (
ntbtlog.txt) si présent (Tâche 16)
- Décidez la classe suspecte :
- Stockage ? priorisez les pilotes critiques de démarrage.
- GPU ? priorisez les pilotes d’affichage et l’entrée en mode sans échec.
- Filtre de sécurité ? cherchez des pilotes/services filtre en échec.
- Énumérez les pilotes hors ligne avec DISM (Tâche 7).
- Inspectez les paquets pilotes suspects avant d’agir (Tâche 8).
- Privilégiez la désactivation du service pilote via le registre hors ligne si c’est critique pour le démarrage ou incertain (Tâche 9).
- Redémarrez et testez. Si le démarrage revient, faites le nettoyage depuis Windows (rollback du périphérique, désinstallation du paquet, blocage de la mise à jour).
- Si nécessaire, supprimez le paquet pilote hors ligne (Tâche 10).
- Si vous avez cassé la visibilité du stockage, injectez un pilote fonctionnel hors ligne (Tâche 11).
- Exécutez des vérifications d’intégrité hors ligne (Tâches 12–13) après l’opération ou avant le reboot final si vous suspectez des installations partielles.
- Annulez le mode sans échec forcé si vous l’avez utilisé (Tâche 15).
Checklist B: If you have exactly 20 minutes before someone escalates
- Lettres de disque + déverrouillage BitLocker (Tâches 1–4).
- DISM liste des pilotes (Tâche 7) et repérez les paquets tiers stockage/affichage/sécurité les plus récents par date.
- Désactivation hors ligne du service boot‑start suspect le plus récent (Tâche 9).
- Redémarrez. Si ça démarre, arrêtez d’y toucher et faites le nettoyage contrôlé depuis Windows.
Checklist C: After you regain boot (make it stay fixed)
- Confirmez la version du pilote dans le Gestionnaire de périphériques pour la classe affectée (stockage/GPU/sécurité).
- Bloquez la mauvaise mise à jour du pilote via vos outils de mise à jour d’entreprise ou politique. Ne comptez pas sur la mémoire.
- Créez un point de restauration si votre environnement le permet pour les postes.
- Assurez‑vous que les clés de récupération BitLocker sont consignées et accessibles aux bonnes personnes.
- Notez le nom exact de l’INF OEM (ex.,
oem42.inf) qui a causé l’incident. C’est votre poignée médico‑légale pour l’automatisation future.
FAQ
1) Is “Roll Back Driver” in Device Manager possible if Windows won’t boot?
Pas directement. Si vous ne pouvez pas atteindre l’interface graphique, vous effectuez un rollback hors ligne : suppression de paquet DISM, désactivation de service hors ligne, ou Restauration système depuis WinRE.
2) What’s the safest first action: remove the driver package or disable the service?
Désactivez d’abord quand vous n’êtes pas sûr, surtout pour les pilotes critiques au démarrage. La désactivation est plus réversible et aide à confirmer la causalité.
3) Why does WinRE show my Windows drive as D: or E: instead of C:?
WinRE assigne les lettres dynamiquement. Utilisez toujours diskpart pour localiser le volume Windows réel et vérifiez en parcourant \Windows.
4) DISM shows multiple storage drivers. Which one do I remove?
Commencez par le paquet tiers le plus récent qui correspond à la classe du contrôleur et qui se corrèle avec la chronologie/les logs de la panne. Si c’est marqué boot critical, désactivez d’abord le service et testez le démarrage.
5) If I remove a GPU driver offline, will Windows boot with a basic driver?
Généralement, oui. Windows peut retomber sur le pilote d’affichage de base de Microsoft. C’est souvent suffisant pour revenir au bureau et installer une version stable.
6) What if BitLocker is enabled and I don’t have the recovery key?
Vous êtes bloqué pour les interventions hors ligne. Vos options réalistes : obtenir la clé depuis l’escalade/la conservation, ou récupérer les données via des canaux autorisés. Sans la clé, l’intervention hors ligne est en grande partie un cul‑de‑sac.
7) Can Startup Repair fix a bad driver?
Rarement. La Réparation du démarrage corrige la chaîne de démarrage, pas la compatibilité des pilotes. Ça vaut un essai rapide, mais ne vous y bloquez pas si la panne a commencé après une installation de pilote.
8) Will System Restore remove the problematic driver?
Souvent oui, si le point de restauration précède l’installation du pilote. Mais ce n’est pas garanti, et la restauration peut échouer si le système de fichiers est endommagé.
9) I disabled a driver service and now the system boots. Should I leave it disabled?
Non. Considérez cela comme une confirmation diagnostique. Une fois démarré, désinstallez/retournez le pilote proprement, installez une version connue‑bonne, et réactivez seulement ce qui est requis.
10) How do I prevent Windows Update from re-installing the bad driver?
En entreprise, utilisez votre gestion des mises à jour et des anneaux d’approbation des pilotes. Sur une machine autonome, cachez/bloquez la mise à jour via la politique ou les restrictions d’installation de périphériques—sinon elle reviendra comme une suite indésirable.
Conclusion : étapes suivantes pour éviter la répétition
Rétablir un pilote quand Windows ne démarre pas est un problème de discipline déguisé en problème technique. La méthode sûre est reproductible : identifiez le volume correct, déverrouillez‑le si besoin, lisez les logs, confirmez le paquet pilote exact, puis désactivez d’abord ou supprimez avec DISM hors ligne. Redémarrez, vérifiez, et ne faites le nettoyage qu’après.
Étapes pratiques suivantes :
- Rédigez un runbook interne d’une page avec le processus de gestion des clés BitLocker, la méthode d’entrée en WinRE, et les commandes DISM que vous maîtrisez.
- Adoptez des anneaux de déploiement pour les pilotes : groupe pilote, puis déploiement plus large. C’est la gestion du changement pour le monde réel.
- Conservez un bundle de pilotes connus‑bons (stockage + réseau + GPU basiques) sur une clé de récupération. Vous ne voulez pas chercher des pilotes pendant une panne.
- Après la récupération, bloquez la mauvaise version et enregistrez le nom INF OEM. Votre futur vous sera reconnaissant.