Écran bleu BAD_POOL_HEADER : les solutions

BAD_POOL_HEADER veut dire qu’un morceau de mémoire réservée par le noyau a été abîmé par du code qui n’avait rien à y faire. Dans la pratique, deux suspects reviennent en boucle : un pilote qui écrit hors de sa zone, ou une barrette de mémoire défaillante.

Points clés

• BAD_POOL_HEADER est le code d’arrêt 0x00000019. Il indique qu’un en-tête de pool est corrompu.
• Microsoft précise que les paramètres affichés varient d’une machine à l’autre : ils ne se lisent pas comme un message d’erreur classique.
• Sur l’ensemble des codes d’arrêt, Microsoft attribue 70 % des plantages à du code de pilote tiers et 10 % au matériel.
• L’outil officiel pour identifier le pilote coupable s’appelle le vérificateur de pilotes (verifier.exe), présent dans Windows depuis Windows 2000.
• Le vérificateur doit rester une étape encadrée : Microsoft recommande de l’exécuter uniquement sur des machines de test, car il provoque volontairement des arrêts.

Ce que « pool » désigne réellement

Le pool est la réserve de mémoire dans laquelle le noyau et les pilotes piochent pour stocker leurs structures de travail. Chaque bloc alloué porte un en-tête qui décrit sa taille et son propriétaire. Quand un pilote écrit au-delà de la zone qui lui a été accordée, il écrase l’en-tête du bloc voisin. Windows s’en aperçoit plus tard, au moment de libérer ce bloc, et s’arrête sur BAD_POOL_HEADER.

Ce décalage explique la difficulté du diagnostic. La documentation Microsoft le dit sans détour : l’extension d’analyse automatique du débogueur aide parfois à désigner le pilote suspect, mais ce n’est fréquemment pas le cas avec les corrupteurs de pool. Autrement dit, le nom qui apparaît dans le vidage mémoire est souvent celui de la victime, pas celui du coupable.

1. Retirer le dernier changement

Un code 0x19 apparu du jour au lendemain suit presque toujours une modification. Passez en revue les trois dernières :

• Un pilote installé ou mis à jour, en particulier réseau, audio, stockage ou périphérique USB exotique.
• Un antivirus tiers ou un outil de sécurité, qui travaille par nature dans le noyau.
• Un utilitaire de nettoyage, de gestion de disque ou de montage d’images, qui installe lui aussi un pilote en mode noyau.

Désinstallez, redémarrez, observez pendant deux jours. Si le poste ne démarre plus assez longtemps pour agir, passez par le mode sans échec : les pilotes tiers n’y sont pas chargés, ce qui suffit souvent à retrouver un système utilisable.

Quand la date du premier arrêt est identifiable, un retour à un point de restauration antérieur règle le problème plus vite qu’une chasse au pilote.

2. Tester la mémoire vive avant tout le reste

Une barrette qui se dégrade produit exactement le même symptôme qu’un pilote fautif : des octets modifiés dans une zone que personne n’a touchée. Windows fournit le Diagnostic de mémoire Windows, que l’on lance par Windows + R puis mdsched.exe. Le poste redémarre et exécute ses tests avant le chargement du système.

Le résultat s’affiche à l’ouverture de session suivante, et le journal complet est consultable dans l’Observateur d’événements sous la source MemoryDiagnostics-Results. Une erreur détectée clôt le dossier : le module est à remplacer.

Un test propre ne prouve pas l’inverse. Sur une machine à plusieurs modules, la méthode manuelle reste supérieure : ne laisser qu’un module en place, faire tourner le poste, puis alterner. Si les arrêts suivent un module, la conclusion est nette. Ce protocole vaut aussi pour les codes voisins comme PFN_LIST_CORRUPT, qui pointe la même famille de corruption mémoire.

3. Vérifier l’intégrité du système

Les arrêts brutaux répétés laissent des traces dans les fichiers système. Lancez sfc /scannow depuis une invite de commandes en administrateur. Cette étape ne corrige pas la cause d’un 0x19, mais elle élimine une variable et remet en état ce que les redémarrages sauvages ont abîmé.

Sur un poste où le message n’apparaît qu’à l’arrêt de la machine, notez que Microsoft documente un cas précis d’erreur 0x00000019 déclenchée pendant la séquence d’extinction. Le même article rappelle que tous les arrêts 0x19 ne viennent pas de ce cas de figure, donc pas de conclusion hâtive sur la base du seul moment du plantage.

4. Utiliser le vérificateur de pilotes pour nommer le coupable

C’est l’outil officiel du diagnostic de pool. Le vérificateur de pilotes est livré avec Windows dans %WinDir%\system32 sous le nom verifier.exe et ne se télécharge pas séparément. Il force les pilotes à respecter des règles strictes et provoque un arrêt immédiat au premier écart, ce qui déplace le plantage du moment de la libération vers le moment de la faute.

La procédure documentée tient en trois gestes : ouvrir une invite de commandes en tant qu’administrateur, taper verifier pour afficher le gestionnaire, puis choisir « Créer des paramètres standard » et sélectionner les pilotes à contrôler. Un redémarrage est nécessaire pour que la surveillance démarre.

Deux précautions, et elles ne sont pas facultatives. D’abord, Microsoft insiste : cet outil se lance sur des machines de test ou sur celles que l’on est en train de déboguer, pas sur un poste de production en pleine journée de travail. Ensuite, prévoyez la sortie de secours avant d’activer quoi que ce soit. Si la machine enchaîne les écrans bleus au démarrage, il faut pouvoir revenir en mode sans échec et exécuter verifier /reset pour tout désactiver.

L’option la plus utile sur un 0x19 s’appelle le pool spécial. La documentation recommande de l’appliquer aux balises de pool suspectes ou au pilote suspect, précisément parce que l’analyse automatique échoue souvent sur ce type de corruption.

5. Mettre à jour ou remplacer le pilote identifié

Une fois le pilote nommé, récupérez sa dernière version chez le fabricant du composant ou de la machine, pas sur un site de téléchargement générique. Si aucune version plus récente n’existe, le choix se réduit : rester sur une version antérieure connue comme stable, ou retirer le matériel concerné.

Pour les pilotes fournis par Windows Update, laissez le canal officiel faire son travail avant toute installation manuelle. C’est la recommandation de Microsoft sur l’ensemble des dossiers d’écran bleu.

Quand le pilote n’est pas en cause

Trois signaux orientent vers le matériel plutôt que vers le logiciel. Le code change d’un arrêt à l’autre. Les plantages arrivent aussi en mode sans échec. Le poste a subi un déplacement, une intervention interne ou une surchauffe récente.

Dans ce cas, la mémoire passe en tête des suspects, suivie par le contrôleur de stockage. Le guide des écrans bleus Windows classe les codes par famille et permet de savoir si le vôtre appartient à la série mémoire ou à la série pilote. Le code cousin BAD_POOL_CALLER se traite avec la même méthode : mêmes causes, même ordre de vérification.

Questions fréquentes

BAD_POOL_HEADER est-il un problème de disque dur ?

Rarement en direct. Le pool est en mémoire vive, pas sur le disque. Un contrôleur de stockage mal piloté peut cependant corrompre des structures du noyau, ce qui remet le pilote de stockage dans la liste des suspects.

Faut-il réinstaller Windows ?

Pas en première intention. Une réinstallation efface les pilotes tiers, donc elle masque parfois le symptôme, mais elle ne dit pas lequel était fautif. Si la mémoire est testée et que le vérificateur de pilotes ne désigne personne, elle devient défendable, après sauvegarde complète.

Le vérificateur de pilotes peut-il empêcher le démarrage ?

Oui, c’est son principe : il arrête le système dès qu’un pilote enfreint une règle. Il faut donc savoir revenir en mode sans échec et lancer verifier /reset avant de l’activer.

Combien de temps laisser le vérificateur actif ?

Assez longtemps pour reproduire le plantage dans les conditions habituelles d’usage. S’il ne se passe rien et qu’aucun arrêt ne survient, la piste du pilote surveillé s’affaiblit et on élargit la sélection.

Les paramètres affichés sur l’écran bleu servent-ils à quelque chose ?

Pour un utilisateur, presque pas : Microsoft indique que ces paramètres varient selon la configuration. Ils servent au débogueur noyau, qui parcourt les liens internes du pool pour remonter à la cause.

_{Photo d en-tete : deux modules de mémoire DDR4 Corsair, par Bretwa, CC BY-SA 4.0, via Wikimedia Commons. Les modules photographiés ne présentent aucun défaut connu.
Sources : Microsoft Learn, Bug Check 0x19 BAD_POOL_HEADER ; Microsoft Learn, Vérificateur de pilotes ; Microsoft Learn, Utiliser le vérificateur de pilotes pour identifier les problèmes ; Microsoft Support, erreur d’arrêt 0x00000019 à l’extinction ; Microsoft Learn, Stop code error or bug check troubleshooting ; Microsoft Support, Troubleshooting Windows unexpected restarts and stop code errors.}