Activation du débogage postmortem

Article
07/08/2024

Gestion des exceptions en mode utilisateur

Exceptions et points d’arrêt

Les erreurs d’application les plus courantes sont appelées exceptions. Il s’agit notamment de violations d’accès, d’erreurs division par zéro, de dépassements numériques, d’exceptions CLR et de nombreux autres types d’erreurs. Les applications peuvent également provoquer des interruptions de point d’arrêt. Cela se produit lorsque Windows ne peut pas exécuter l’application (par exemple, lorsqu’un module nécessaire ne peut pas être chargé) ou lorsqu’un point d’arrêt est rencontré. Les points d’arrêt peuvent être insérés dans le code par un débogueur ou appelés par le biais d’une fonction telle que DebugBreak.

Priorité des gestionnaires d’exceptions

En fonction des valeurs de configuration et des débogueurs actifs, Windows gère les erreurs en mode utilisateur de différentes façons. La séquence suivante montre la priorité utilisée pour la gestion des erreurs en mode utilisateur :

Si un débogueur en mode utilisateur est actuellement attaché au processus d’erreur, toutes les erreurs entraînent l’arrêt de la cible dans ce débogueur.

Tant que le débogueur en mode utilisateur est attaché, aucune autre méthode de gestion des erreurs n’est utilisée, même si la commande gn (Go With Exception Not Handled) est utilisée.
Si aucun débogueur en mode utilisateur n’est attaché et que le code en cours d’exécution possède ses propres routines de gestion des exceptions (par exemple, essayez - sauf), cette routine de gestion des exceptions tente de traiter l’erreur.
Si aucun débogueur en mode utilisateur n’est attaché et que Windows dispose d’une connexion de débogage du noyau ouverte et que l’erreur est une interruption de point d’arrêt, Windows tente de contacter le débogueur du noyau.

Les connexions de débogage du noyau doivent être ouvertes pendant le processus de démarrage de Windows. Si vous souhaitez empêcher une interruption en mode utilisateur de se décomposer dans le débogueur du noyau, vous pouvez utiliser l’utilitaire KDbgCtrl avec le paramètre -du . Pour plus d’informations sur la configuration des connexions de débogage de noyau et sur l’utilisation de KDbgCtrl, consultez La configuration du débogage.

Dans le débogueur du noyau, vous pouvez utiliser gh (Go With Exception Handled) pour ignorer l’erreur et continuer à exécuter la cible. Vous pouvez utiliser gn (Go With Exception Not Handled) pour contourner le débogueur du noyau et passer à l’étape 4.
Si les conditions des étapes 1, 2 et 3 ne s’appliquent pas, Windows active un outil de débogage configuré dans les valeurs de Registre AeDebug. Tout programme peut être sélectionné à l’avance en tant qu’outil à utiliser dans cette situation. Le programme choisi est appelé débogueur postmortem.
Si les conditions des étapes 1, 2 et 3 ne s’appliquent pas, et qu’aucun débogueur postmortem n’est inscrit, le rapport d’erreurs Windows (WER) affiche un message et fournit des solutions le cas échéant. WER écrit également un fichier de vidage de mémoire si les valeurs appropriées sont définies dans le Registre. Pour plus d’informations, consultez Utilisation de WER et collecte des vidages en mode utilisateur.

DebugBreak, fonction

Si un débogueur postmortem a été installé, vous pouvez délibérément basculer dans le débogueur à partir d’une application en mode utilisateur en appelant la fonction DebugBreak .

Spécification d’un débogueur Postmortem

Cette section explique comment configurer des outils tels que WinDbg comme débogueur postmortem. Une fois configuré, le débogueur postmortem est automatiquement démarré chaque fois qu’une application se bloque.

Clés de Registre du débogueur Post Mortem

Windows Error Reporting (WER) crée le processus de débogueur postmortem à l’aide des valeurs définies dans la clé de Registre AeDebug.

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

Il existe deux valeurs de Registre principales d’intérêt, de débogueur et d’auto. La valeur du Registre du débogueur spécifie la ligne de commande du débogueur postmortem. La valeur du Registre automatique spécifie si le débogueur postmortem est démarré automatiquement ou si une boîte de message de confirmation est présentée en premier.

Débogueur (REG_SZ)

Cette valeur REG_SZ spécifie le débogueur qui gère le débogage postmortem.

Le chemin d’accès complet au débogueur doit être répertorié, sauf si le débogueur se trouve dans un répertoire qui se trouve dans le chemin d’accès par défaut.

La ligne de commande est générée à partir de la chaîne du débogueur via un appel de style printf qui inclut 3 paramètres. Bien que l’ordre soit résolu, il n’est pas nécessaire d’utiliser l’un ou l’ensemble des paramètres disponibles.

DWORD (%ld) : ID de processus du processus cible.

DWORD (%ld) : handle d’événement dupliqué dans le processus de débogueur postmortem. Si le débogueur postmortem signale l’événement, WER poursuit le processus cible sans attendre que le débogueur postmortem se termine. L’événement ne doit être signalé que si le problème a été résolu. Si le débogueur postmortem se termine sans signaler l’événement, WER poursuit la collecte d’informations sur les processus cibles.

void* (%p) : adresse d’une structure de JIT_DEBUG_INFO allouée dans l’espace d’adressage du processus cible. La structure contient des informations et un contexte d’exception supplémentaires.

Auto (REG_SZ) Cette valeur REG_SZ est toujours égale à 0 ou 1.

Si l’option Auto est définie sur 0, une boîte de message de confirmation s’affiche avant le démarrage du processus de débogage postmortem.

Si l’option Auto est définie sur 1, le débogueur postmortem est immédiatement créé.

Lorsque vous modifiez manuellement le Registre, faites-le très attentivement, car les modifications incorrectes apportées au Registre peuvent ne pas autoriser Windows à démarrer.

Exemple d’utilisation de la ligne de commande

De nombreux débogueurs postmortem utilisent une ligne de commande qui inclut des commutateurs -p et -e pour indiquer que les paramètres sont un PID et un événement (respectivement). Par exemple, l’installation de WinDbg via windbg.exe -I crée les valeurs suivantes :

Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1

Il existe une certaine flexibilité dans la façon dont les paramètres WER %ld %ld %p peuvent être utilisés. Par exemple, il n’est pas nécessaire de spécifier des commutateurs autour ou entre les paramètres WER. Par exemple, l’installation de Windows Sysinternals ProcDump crée procdump.exe -i les valeurs suivantes sans commutateur entre les paramètres WER %ld %ld %ld %p :

Debugger = "<Path>\procdump.exe" -accepteula -j "c:\Dumps" %ld %ld %p
Auto = 1

Débogueurs 32 et 64 bits

Sur une plateforme 64 bits, les valeurs de Registre Debugger (REG_SZ) et Auto (REG_SZ) sont définies individuellement pour les applications 64 bits et 32 bits. Une clé Windows supplémentaire sur Windows (WOW) est utilisée pour stocker les valeurs de débogage post-mortem de l’application 32 bits.

HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

Sur une plateforme 64 bits, utilisez un débogueur post-mortem 32 bits pour les processus 32 bits et un débogueur 64 bits pour les processus 64 bits. Cela évite un débogueur 64 bits qui se concentre sur les threads WOW64, au lieu des threads 32 bits, dans un processus 32 bits.

Pour de nombreux débogueurs postmortems, notamment les outils de débogage pour les débogueurs postmortems Windows, cela implique d’exécuter la commande d’installation deux fois ; une fois avec la version x86 et une fois avec la version x64. Par exemple, pour utiliser WinDbg comme débogueur postmortem interactif, la windbg.exe -I commande est exécutée deux fois, une fois pour chaque version.

Installation 64 bits :

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I

Cela met à jour la clé de Registre avec ces valeurs.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -p %ld -e %ld –g

Installation 32 bits :

C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I

Cela met à jour la clé de Registre avec ces valeurs.

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe" -p %ld -e %ld –g

Configuration des débogueurs Post Mortem

Outils de débogage pour Windows

Les outils de débogage pour Les débogueurs Windows prennent toutes en charge la définition du débogueur postmortem. La commande d’installation prévoit que le processus soit débogué de manière interactive.

WinDbg

Pour définir le débogueur postmortem sur WinDbg, exécutez windbg -I. (Doit I être capitalisé.) Cette commande affiche un message de réussite ou d’échec après son utilisation. Pour utiliser les applications 32 et 64 bits, exécutez la commande pour les débogueurs 64 et 32.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I

Il s’agit de la configuration de l’entrée de Registre AeDebug lors windbg -I de l’exécution.

Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1

Dans les exemples, <Path> est le répertoire où se trouve le débogueur.

Les paramètres -p et -e passent l’ID de processus et l’événement, comme indiqué précédemment.

Le -g transmet la commande g (Go) à WinDbg et poursuit l’exécution à partir de l’instruction actuelle.

Notez qu’il existe un problème important en passant la commande g (Go). Le problème avec cette approche est que les exceptions ne se répètent pas toujours, généralement en raison d’une condition temporaire qui n’existe plus lorsque le code est redémarré. Pour plus d’informations sur ce problème, consultez .jdinfo (Utiliser JIT_DEBUG_INFO).

Pour éviter ce problème, utilisez .jdinfo ou .dump /j. Cette approche permet au débogueur d’être dans le contexte de l’échec du code d’intérêt. Pour plus d’informations, consultez Débogage juste-à-temps (JIT) plus loin dans cette rubrique.

CDB

Pour définir le débogueur postmortem sur CDB, exécutez cdb -iae (Installer AeDebug) ou cdb -iaec KeyString (installez AeDebug avec command).

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iae

Lorsque le paramètre -iaec est utilisé, KeyString spécifie une chaîne à ajouter à la fin de la ligne de commande utilisée pour lancer le débogueur postmortem. Si KeyString contient des espaces, il doit être placé entre guillemets.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iaec [KeyString]

Cette commande n’affiche rien s’il réussit et un message d’erreur s’il échoue.

NTSD

Pour définir le débogueur postmortem sur NTSD, exécutez ntsd -iae (Install AeDebug) ou ntsd -iaec KeyString (installez AeDebug avec la commande).

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iae

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iaec [KeyString]

Cette commande n’affiche rien si elle réussit et une erreur sur une nouvelle fenêtre de console en cas d’échec.

Notez que les paramètres -p %ld -e %ld -g apparaissent toujours d’abord sur la ligne de commande du débogueur postmortem, vous ne devez pas utiliser le commutateur -iaec pour spécifier le paramètre -server, car -server ne fonctionnera pas, sauf s’il apparaît en premier sur la ligne de commande. Pour installer un débogueur postmortem qui inclut ce paramètre, vous devez modifier le Registre manuellement.

Débogueur JIT Visual Studio

Si Visual Studio a été installé, vsjitdebugger.exe sera inscrit en tant que débogueur post mortem. Le débogueur JIT Visual Studio a l’intention que le processus soit débogué de manière interactive.

Debugger = "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

Si Visual Studio est mis à jour ou réinstallé, cette entrée est réécrite, en remplaçant les autres valeurs définies.

Fenêtre Sysinternals ProcDump

L’utilitaire Windows Sysinternals ProcDump peut également être utilisé pour la capture de vidage postmortem. Pour plus d’informations sur l’utilisation et le téléchargement de ProcDump, consultez ProcDump.

Comme la commande .dump WinDbg, ProcDump peut capturer un vidage de l’incident de manière non interactive. La capture peut se produire dans n’importe quelle session système Windows.

ProcDump se termine lorsque la capture du fichier de vidage est terminée, weR signale ensuite l’échec et le processus d’erreur est arrêté.

Permet procdump -i d’installer procdump et -you de désinstaller ProcDump pour le débogage post mortem 32 et 64 bits.

<Path>\procdump.exe -i

Les commandes d’installation et de désinstallation génèrent les valeurs de Registre modifiées en cas de réussite et les erreurs en cas d’échec.

Les options de ligne de commande ProcDump dans le Registre sont définies sur :

Debugger = <Path>\ProcDump.exe -accepteula -j "<DumpFolder>" %ld %ld %p

ProcDump utilise tous les 3 paramètres : PID, Événement et JIT_DEBUG_INFO. Pour plus d’informations sur le paramètre JIT_DEBUG_INFO, consultez Débogage juste-à-temps (JIT) ci-dessous.

La taille du vidage capturé par défaut est Mini (processus/threads/handles/modules/espace d’adressage) sans option de taille définie, MiniPlus (Mini plus MEM_PRIVATE pages) avec -mp set ou Full (toute la mémoire - équivalente à .dump /mA") avec -ma set.

Pour les systèmes disposant d’un espace disque suffisant, une capture complète (-ma) est recommandée.

Utilisez -ma avec l’option -i pour spécifier une capture de mémoire. Si vous le souhaitez, fournissez un chemin d’accès pour les fichiers de vidage.

<Path>\procdump.exe -ma -i c:\Dumps

Pour les systèmes dotés d’un espace disque limité, une capture MiniPlus (-mp) est recommandée.

<Path>\procdump.exe -mp -i c:\Dumps

Le dossier dans lequel enregistrer le fichier de vidage est facultatif. La valeur par défaut est le dossier actif. Le dossier doit être sécurisé avec une liste de contrôle d’accès égale ou supérieure à celle utilisée pour C :\Windows\Temp. Pour plus d’informations sur la gestion de la sécurité liée aux dossiers, consultez Security During Postmortem Débogage.

Pour désinstaller ProcDump en tant que débogueur postmortem et restaurer les paramètres précédents, utilisez l’option -u (Désinstaller).

<Path>\procdump.exe -u

Pour plus d’informations sur ProcDump, consultez ProcDump et Windows SysInternals Administrator’s Reference by Mark Russinovich et Aaron Margosis publié par Microsoft Press.

Débogage juste-à-temps (JIT)

Définition du contexte pour l’application défaillante

Comme indiqué précédemment, il est très souhaitable de définir le contexte sur l’exception qui a provoqué le blocage à l’aide du paramètre JIT_DEBUG_INFO. Pour plus d’informations sur ce problème, consultez .jdinfo (Utiliser JIT_DEBUG_INFO).

Outils de débogage pour Windows

Cet exemple montre comment modifier le Registre pour exécuter une commande initiale (-c) qui utilise la commande d’adresse> .jdinfo <pour afficher les informations d’exception supplémentaires et modifier le contexte en l’emplacement de l’exception (similaire à la façon dont .ecxr est utilisé pour définir le contexte sur l’enregistrement d’exception).

Debugger = "<Path>\windbg.exe -p %ld -e %ld -c ".jdinfo 0x%p"
Auto = 1

Le paramètre %p est l’adresse d’une structure JIT_DEBUG_INFO dans l’espace d’adressage du processus cible. Le paramètre %p est pré-ajouté avec 0x afin qu’il soit interprété comme une valeur hexadécimal. Pour plus d’informations, consultez .jdinfo (Utiliser JIT_DEBUG_INFO).

Pour déboguer une combinaison d’applications 32 et 64 bits, configurez les clés de Registre 32 et 64 bits (décrites ci-dessus), en définissant le chemin approprié à l’emplacement des WinDbg.exe 64 bits et 32 bits.

Création d’un fichier de vidage à l’aide de .dump

Pour capturer un fichier de vidage chaque fois qu’un échec se produit qui inclut les données JIT_DEBUG_INFO, utilisez l’adresse> .dump /j<.

<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd"

Utilisez l’option /u pour générer un nom de fichier unique pour autoriser la création automatique de plusieurs fichiers de vidage. Pour plus d’informations sur les options, consultez .dump (Créer un fichier de vidage).

Le vidage créé aura les données JITDEBUG_INFO stockées en tant que contexte d’exception par défaut. Au lieu d’utiliser .jdinfo pour afficher les informations d’exception et définir le contexte, utilisez .exr -1 pour afficher l’enregistrement d’exception et .ecxr pour définir le contexte. Pour plus d’informations, consultez .exr (Enregistrement d’exception d’affichage) et .ecxr (Enregistrement de contexte d’exception d’affichage).

Rapport d’erreurs Windows - q/ qd

La façon dont la session de débogage se termine détermine si le rapport d’erreurs Windows signale l’échec.

Si la session de débogage est détachée à l’aide de qd avant la fermeture du débogueur, WER signale l’échec.

Si la session de débogage est arrêtée à l’aide de q (ou si le débogueur est fermé sans détacher), WER ne signale pas l’échec.

Append ; q ou ; qd à la fin de la chaîne de commandes pour appeler le comportement souhaité.

Par exemple, pour permettre à WER de signaler l’échec après que CDB capture un vidage, configurez cette chaîne de commande.

<Path>\cdb.exe -p %ld -e %ld -c ".dump /j 0x%p /u c:\Dumps\AeDebug.dmp; qd"

Cet exemple permet à WER de signaler l’échec après la capture d’un vidage par WinDbg.

<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd""

Vulnérabilités de sécurité

Si vous envisagez d’activer le débogage postmortem sur un ordinateur que vous partagez avec d’autres personnes, consultez Sécurité pendant le débogage postmortem.

Partager via