Écran bleu KERNEL_MODE_HEAP_CORRUPTION : les solutions

KERNEL_MODE_HEAP_CORRUPTION correspond au code d’arrêt 0x0000013A. Le gestionnaire de tas du noyau Windows a détecté qu’une structure de mémoire qu’il gère venait d’être écrasée, et il arrête le système avant que la corruption ne se propage. Dans la pratique, c’est presque toujours un pilote fautif, et bien plus rarement une barrette de mémoire défaillante.

Points clés

• Code d’arrêt : 0x0000013A. Le paramètre 1 du bug check indique le type de corruption détecté, le paramètre 2 l’adresse du tas concerné, le paramètre 3 l’adresse où la corruption a été vue.
• Cause dominante : un pilote en mode noyau qui écrit hors de la zone qui lui est allouée. Carte graphique, réseau, audio et utilitaires de virtualisation ou d’antivirus sont les familles les plus souvent citées.
• La méthode qui tranche : lire le fichier de vidage mémoire, puis activer le Vérificateur de pilotes avec verifier /standard /all pour forcer le pilote coupable à se trahir.
• Le test mémoire avec mdsched.exe reste utile, mais il vient après l’examen des pilotes : la mémoire physique n’est pas la piste la plus fréquente sur ce code.

Ce que Windows vous dit exactement

Le tas en mode noyau est la zone où les composants système et les pilotes réservent de la mémoire. Le gestionnaire de tas y maintient des métadonnées de contrôle autour de chaque bloc alloué. Quand il relit ces métadonnées et les trouve incohérentes, il déclenche le bug check 0x13A. La documentation de Microsoft est explicite : le tas a détecté la corruption, mais le fautif est ailleurs.

Le premier paramètre affiché dans le vidage précise la nature de l’anomalie. Une valeur 0x17, par exemple, signale un bloc corrompu dans une liste de libération différée, ce qui pointe vers une écriture après libération ou un dépassement de tampon sur le bloc voisin. Le module qui apparaît dans la pile d’appels est souvent le gestionnaire de tas lui-même, pas le pilote responsable, d’où la nécessité d’un test actif.

1. Noter le contexte avant tout diagnostic

Trois questions à trancher immédiatement, parce qu’elles éliminent la moitié des pistes.

• Depuis quand ? Un nouveau matériel, un pilote installé la semaine passée ou une mise à jour cumulative récente donnent le suspect principal.
• Dans quelles conditions ? Un plantage systématique au lancement d’un jeu ou d’un logiciel de capture désigne un pilote graphique ou un filtre système. Un plantage aléatoire au repos élargit le champ.
• Une seule machine ou plusieurs ? Sur un parc, un pilote déployé en masse ou un agent de sécurité commun devient très probable.

2. Lire le fichier de vidage mémoire

Windows écrit un vidage à chaque écran bleu, dans C:\Windows\Minidump. Vérifiez d’abord qu’il est bien généré : Paramètres système avancés, onglet Avancé, Démarrage et récupération, l’écriture des informations de débogage doit être sur « Petite image mémoire » au minimum.

Ouvrez ensuite le fichier avec WinDbg, puis lancez !analyze -v. Trois informations comptent :

1. La valeur du paramètre 1, qui donne le type de corruption.
2. Le champ du module fautif quand l’analyseur parvient à l’identifier.
3. La liste des pilotes chargés, à croiser avec les mises à jour récentes.

Si vous n’avez jamais utilisé de débogueur, notre article sur l’analyse des fichiers minidump détaille l’installation et la lecture pas à pas.

3. Mettre à jour ou revenir en arrière sur les pilotes suspects

Commencez par les pilotes graphiques, réseau et de stockage, dans cet ordre. Utilisez les pilotes du site du constructeur du composant, pas ceux redistribués par un utilitaire tiers.

• Pilote récemment mis à jour : dans le Gestionnaire de périphériques, propriétés du périphérique, onglet Pilote, bouton Version précédente.
• Pilote ancien : téléchargez la dernière version signée chez le fabricant, désinstallez l’ancienne avec l’option de suppression du logiciel de pilote, puis installez.
• Utilitaires à filtre noyau : antivirus tiers, VPN, outils de virtualisation, logiciels de contrôle de ventilateurs. Désinstallez-les temporairement plutôt que de les désactiver, un filtre désactivé reste chargé.

4. Faire parler le pilote fautif avec le Vérificateur de pilotes

Le Vérificateur de pilotes soumet les pilotes à des contrôles stricts et provoque un plantage immédiat, et identifié, au premier écart. C’est l’outil qui transforme un plantage aléatoire en diagnostic nominatif.

1. Créez un point de restauration.
2. Dans une invite de commandes en administrateur : verifier /standard /all, puis redémarrez.
3. Utilisez la machine normalement, jusqu’au prochain écran bleu. Analysez le nouveau vidage : il nomme cette fois le pilote.
4. Désactivez ensuite le vérificateur avec verifier /reset et redémarrez.

Les options standard couvrent le pool spécial, le contrôle d’IRQL, le suivi du pool, la vérification des entrées et sorties, la détection d’interblocage, la vérification DMA et les contrôles de sécurité. Attention : avec /all, la machine peut devenir instable au point de ne plus démarrer normalement. Le mode sans échec et verifier /reset restent votre porte de sortie, et Microsoft conseille de cibler /driver sur un pilote précis quand vous avez déjà un suspect.

5. Vérifier l’intégrité du système et la mémoire

Deux passes complémentaires, dans cet ordre :

1. sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth pour réparer les fichiers système et le magasin de composants.
2. Windows + R, mdsched.exe, redémarrage immédiat. Pendant le test, F1 ouvre le choix du jeu de tests : passez en Étendu pour un contrôle sérieux, même s’il dure plusieurs heures.

Une seule erreur signalée suffit à condamner la barrette. Testez-les alors une par une pour identifier laquelle. Un profil XMP ou EXPO trop agressif produit les mêmes symptômes : revenez aux fréquences par défaut avant de conclure au défaut matériel. Ce réflexe est le même que pour MEMORY_MANAGEMENT et PFN_LIST_CORRUPT, deux codes voisins qui interrogent la même chaîne mémoire.

6. Isoler par élimination quand rien ne se dégage

Démarrez en mode sans échec avec mise en réseau. Si le système tient plusieurs heures alors qu’il plantait en quelques minutes, un pilote ou un service non Microsoft est en cause, et la configuration système (msconfig) permet de réactiver les services par moitiés jusqu’à retrouver le coupable.

Testez aussi une session avec un seul module de mémoire, puis avec l’autre. Et si la machine est overclockée, remettez tout à zéro : processeur, mémoire, carte graphique. Une corruption de tas n’a pas besoin d’un composant mort pour se produire, une instabilité électrique suffit.

7. Recouper avec l’Observateur d’événements

Le vidage mémoire dit ce qui a planté, l’Observateur d’événements dit ce qui se passait juste avant. Ouvrez-le avec eventvwr.msc, puis Journaux Windows, Système, et filtrez sur les niveaux Critique et Erreur.

1. Repérez l’événement Kernel-Power 41, qui marque l’arrêt brutal, et relevez son horodatage.
2. Remontez de quelques minutes : les erreurs de service, de disque ou de pilote qui précèdent nomment souvent le composant en cause.
3. En ligne de commande, wevtutil qe System /c:20 /rd:true /f:text affiche les vingt derniers événements sans passer par l’interface.

Un fichier .sys qui revient systématiquement dans ces entrées est un suspect à traiter en priorité, avant même de lancer le vérificateur. Le recoupement entre l’heure de l’écran bleu et les dernières mises à jour installées permet aussi de savoir s’il faut chercher du côté d’un correctif récent plutôt que d’un matériel.

Quand ça ne vient pas de là

• Le code change à chaque plantage. Une corruption mémoire généralisée fait défiler des codes différents. La méthode générale du guide des écrans bleus Windows par code d’arrêt s’applique alors mieux que la piste d’un pilote unique.
• Le plantage est immédiat au démarrage. Cherchez plutôt du côté d’un chargeur ou d’un pilote de stockage : voir écran bleu au démarrage.
• Les erreurs concernent des vérifications de sécurité de structures. Le code KERNEL_SECURITY_CHECK_FAILURE décrit un contrôle voisin mais un mécanisme différent.

La réinstallation de Windows règle la question quand la corruption vient d’un système abîmé, mais elle ne changera rien si le pilote fautif est réinstallé après coup, ni si une barrette est défectueuse.

Questions fréquentes

KERNEL_MODE_HEAP_CORRUPTION vient-il de la RAM ?

Parfois, mais ce n’est pas le cas le plus fréquent. Le code signale une corruption des structures du tas noyau, qu’un pilote mal écrit provoque sans qu’aucune puce mémoire ne soit défaillante. Le test mémoire reste utile pour écarter cette hypothèse.

Que veut dire le premier paramètre du code d’arrêt ?

Il donne le type de corruption détectée par le gestionnaire de tas. Microsoft en publie la liste dans la documentation du bug check 0x13A. Une valeur 0x17 pointe vers une écriture après libération ou un débordement sur le bloc voisin.

Le Vérificateur de pilotes est-il risqué ?

Il provoque volontairement des plantages, donc oui, sur une machine de production. Faites un point de restauration, sauvegardez avant, et prévoyez le mode sans échec pour lancer verifier /reset. Sur un poste critique, ciblez un pilote avec /driver au lieu de /all.

Un antivirus tiers peut-il déclencher cette erreur ?

Oui. Les moteurs de sécurité installent des filtres en mode noyau qui allouent de la mémoire dans le tas noyau. Une désinstallation temporaire, pas une simple désactivation, est le seul vrai test.

Combien de temps garder le vérificateur activé ?

Jusqu’au prochain écran bleu, ou quelques jours d’usage normal. Sans plantage après cette période, les pilotes vérifiés passent le contrôle et la piste matérielle remonte dans la liste.

Sources

_{Photo d’en-tête : écran bleu Windows, par Tony Webster, licence CC BY 2.0 via Wikimedia Commons. La photo montre un écran bleu générique, pas le code KERNEL_MODE_HEAP_CORRUPTION.
Bug Check 0x13A KERNEL_MODE_HEAP_CORRUPTION, Microsoft Learn (paramètres du bug check et types de corruption).
How to Use Driver Verifier for Driver Testing et Selecting Driver Verifier Options, Microsoft Learn.
verifier et sfc, référence des commandes Windows, Microsoft Learn.
Run Diagnostics to Check Your System for Memory Problems, Microsoft Learn (mdsched.exe, jeux de tests).}