Ce problème est souvent le résultat d'un problème matériel ou d'un problème lié au pilote de périphérique essayant de programmer le matériel. Cette erreur se produit plus souvent avec une carte vidéo ou un pilote de carte vidéo défectueux.
Solutions utilisateur final
Si vous êtes un utilisateur final (ne développez pas le pilote) et rencontrez cette erreur, recherchez les pilotes mis à jour pour votre périphérique. S'il n'y a pas de pilotes mis à jour et qu'aucun nouveau matériel n'a été ajouté, il est prudent de supposer que le matériel de l'ordinateur est en panne et qu'il doit être remplacé.
Solutions pour développeurs
Si vous êtes le développeur du pilote ou tentez de résoudre ce problème, utilisez la commande .thread ( Set Register Context ). Ensuite, pour trouver où le thread est bloqué, utilisez la commande kb ( Afficher la trace de la pile ).
Il est également possible d’utiliser les informations du débogueur pour résoudre ce problème. DbgBreakPoint sera appelé lorsque l'erreur se produira si le débogueur du noyau était déjà en cours d'exécution lorsque Windows a détecté l'erreur ou la condition de délai d' attente . Dans ce cas, le KeBugCheckEx ne sera pas appelé et l'utilisation de la commande .bugcheck ( Afficher les données de contrôle des bogues ) ne contiendra aucune information utile (le cas échéant).
Le débogueur inclura des informations similaires aux paramètres ci-dessus. Vous pouvez toujours afficher les quatre paramètres en les récupérant à partir des variables globales du Watchdog à l'aide de l'une des deux commandes, en fonction du système d'exploitation.
- Système 32 bits: chien de garde dd! G_WdBugCheckData L5
- Système 64 bits: chien de garde dq! G_WdBugCheckData L5
En utilisant cette méthode interactive pour déboguer l'erreur, vous pouvez trouver le thread à l'origine de l'erreur, définir des points d'arrêt dans le thread et utiliser plus tard la commande g (Go) pour déboguer le code en boucle.