Activation du débogage post-mortem

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 des violations d’accès, des erreurs de division par zéro, des dépassements de capacité numérique, des exceptions CLR et de nombreux autres types d’erreurs. Les applications peuvent également provoquer des interruptions de point d’arrêt. Ces problèmes se produisent lorsque Windows ne parvient 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 via 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 manières. La séquence suivante montre la priorité utilisée pour la gestion des erreurs en mode utilisateur :

  1. Si un débogueur en mode utilisateur est actuellement attaché au processus d’erreur, toutes les erreurs entraînent l’entrée 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.

  2. Si aucun débogueur en mode utilisateur n’est attaché et que le code en cours d’exécution a ses propres routines de gestion des exceptions (par exemple, essayez - sauf), cette routine de gestion des exceptions tente de traiter l’erreur.

  3. Si aucun débogueur en mode utilisateur n’est attaché et que Windows dispose d’une connexion de débogage de noyau ouverte et que l’erreur est une interruption de point d’arrêt, Windows tente de contacter le débogueur de noyau.

    Les connexions de débogage de noyau doivent être ouvertes pendant le processus de démarrage de Windows. Si vous souhaitez empêcher une interruption en mode utilisateur d’entrer 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 Configuration du débogage.

    Dans le débogueur de 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 de noyau et passer à l’étape 4.

  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. N’importe quel programme peut être sélectionné à l’avance comme outil à utiliser dans cette situation. Le programme choisi est appelé débogueur post-mortem.

  5. Si les conditions des étapes 1, 2 et 3 ne s’appliquent pas et qu’aucun débogueur post-mortem n’est inscrit, 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 de User-Mode dumps.

DebugBreak, fonction

Si un débogueur post-mortem a été installé, vous pouvez délibérément pénétrer le débogueur à partir d’une application en mode utilisateur en appelant la fonction DebugBreak .

Spécification d’un débogueur post-mortem

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

Clés de Registre du débogueur post mortem

Rapport d'erreurs Windows (WER) crée le processus de débogueur post-mortem à l’aide des valeurs définies dans la clé de Registre AeDebug.

HKLM\Logiciel\Microsoft\Windows NT\Currentversion\AeDebug

Il existe deux valeurs de Registre principales d’intérêt : Débogueur et Auto. La valeur de Registre du débogueur spécifie la ligne de commande du débogueur post-mortem. La valeur du Registre automatique spécifie si le débogueur post-mortem 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érera le débogage post-mortem.

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 par défaut.

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

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

DWORD (%ld) - Event Handle dupliqué dans le processus de débogueur post-mortem. Si le débogueur post-mortem signale l’événement, WER poursuit le processus cible sans attendre que le débogueur post-mortem se termine. L’événement ne doit être signalé que si le problème a été résolu. Si le débogueur post-mortem se termine sans signaler l’événement, WER continue 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 0 ou 1.

Si Auto est défini sur 0, une boîte de message de confirmation s’affiche avant le démarrage du processus de débogage post-mortem.

Si Auto a la valeur 1, le débogueur post-mortem est immédiatement créé.

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

Exemple d’utilisation de la ligne de commande

De nombreux débogueurs post-mortem utilisent une ligne de commande qui comprend les 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

La façon dont les paramètres WER %ld %ld %p peuvent être utilisés est flexible. 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 à l’aide procdump.exe -i de crée les valeurs suivantes sans commutateur entre les paramètres WER %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 Débogueur (REG_SZ) et Auto (REG_SZ) sont définies individuellement pour les applications 64 bits et 32 bits. Une clé Windows sur Windows (WOW) supplémentaire est utilisée pour stocker les valeurs de débogage post mortem de l’application 32 bits.

HKLM\Logiciel\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 qu’un débogueur 64 bits se concentre sur les threads WOW64, au lieu des threads 32 bits, dans un processus 32 bits.

Pour de nombreux débogueurs post-mortem, y compris les outils de débogage pour les débogueurs post-mortem 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 post-mortem 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 tous en charge la définition du débogueur post-mortem. La commande install prévoit que le processus soit débogué de manière interactive.

WinDbg

Pour définir le débogueur post-mortem 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 des 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

C’est ainsi que l’entrée de Registre AeDebug sera configurée lors de l’exécution windbg -I .

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 continue l’exécution à partir de l’instruction actuelle.

Note 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 de code intéressant. Pour plus d’informations, consultez Débogage juste-à-temps (JIT) plus loin dans cette rubrique.

CDB

Pour définir le débogueur post-mortem sur CDB, exécutez cdb -iae (Installer AeDebug) ou cdb -iaecKeyString (Installer 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 post-mortem. 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 si elle réussit, et un message d’erreur en cas d’échec.

NTSD

Pour définir le débogueur post-mortem sur NTSD, exécutez ntsd -iae (Installer AeDebug) ou ntsd -iaecKeyString (Installer 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

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 post-mortem. Si KeyString contient des espaces, il doit être placé entre guillemets.

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 dans une nouvelle fenêtre de console en cas d’échec.

Note Étant donné que les paramètres -p %ld -e %ld -g apparaissent toujours en premier sur la ligne de commande du débogueur post-mortem, vous ne devez pas utiliser le commutateur -iaec pour spécifier le paramètre -server, car -server ne fonctionnera que s’il apparaît en premier sur la ligne de commande. Pour installer un débogueur post-mortem 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 de déboguer le processus 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 sera réécrite, en remplaçant les autres valeurs définies.

Fenêtre Sysinternals ProcDump

L’utilitaire ProcDump de Windows Sysinternals peut également être utilisé pour la capture de vidage post-mortem. 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 ferme lorsque la capture du fichier de vidage est terminée, WER signale ensuite l’échec et le processus d’erreur est terminé.

Utilisez procdump -i pour installer procdump et -you pour 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 les 3 paramètres : PID, Event 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 jeu d’options de taille, MiniPlus (Mini plus MEM_PRIVATE pages) avec -mp set, ou Full (toute la mémoire - équivalent à « . 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 avec 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 Sécurité pendant le débogage post-mortem.

Pour désinstaller ProcDump en tant que débogueur post-mortem 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 par Mark Russinovich et Aaron Margosis publié par Microsoft Press.

Débogage juste-à-temps (JIT)

Définition du contexte pour l’application de défaillance

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 à ce sujet, 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 adresse .jdinfo <> pour afficher les informations d’exception supplémentaires et modifier le contexte par l’emplacement de l’exception (de la même façon que .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 d’accès 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’une défaillance 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 afin de permettre 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 (Display Exception Record) et .ecxr (Display Exception Context Record).

Rapport d'erreurs Windows - q/ qd

La façon dont la session de débogage se termine détermine si 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étachement), WER ne signale pas l’échec.

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

Par exemple, pour permettre à WER de signaler l’échec après que CDB a capturé 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 que WinDbg a capturé un vidage.

<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 post-mortem sur un ordinateur que vous partagez avec d’autres personnes, consultez Sécurité pendant le débogage post-mortem.