Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce laboratoire présente le débogueur du noyau WinDbg. Vous utilisez WinDbg pour déboguer l’exemple de code du pilote en mode noyau echo.
Objectifs du labo
Ce laboratoire comprend des exercices qui introduisent les outils de débogage, enseignent les commandes de débogage courantes, illustrent l’utilisation de points d’arrêt et montrent comment utiliser les extensions de débogage.
Dans ce laboratoire, vous utilisez une connexion de débogage de noyau en direct pour explorer les actions suivantes :
- Utiliser les commandes du débogueur Windows
- Utiliser des commandes standard (piles d’appels, variables, threads, IRQL)
- Utiliser des commandes de débogage de pilotes avancées ( !commands)
- Utiliser des symboles
- Définir des points d’arrêt dans le débogage en direct
- Afficher les piles d’appels
- Afficher l’arborescence des appareils Plug-and-Play
- Utiliser le contexte de thread et de processus
Débogage en mode utilisateur et noyau
Lorsque vous utilisez le débogueur Windows, vous pouvez effectuer deux types de débogage :
Mode utilisateur : les applications et sous-systèmes s’exécutent sur l’ordinateur en mode utilisateur. Les processus qui s’exécutent en mode utilisateur le font dans leurs propres espaces d’adressage virtuels. Ils ne peuvent pas accéder directement à de nombreuses parties du système, notamment le matériel système, la mémoire qui n’est pas allouée pour leur utilisation et d’autres parties du système susceptibles de compromettre l’intégrité du système. Étant donné que les processus qui s’exécutent en mode utilisateur sont efficacement isolés du système et d’autres processus en mode utilisateur, ils ne peuvent pas interférer avec ces ressources.
Mode noyau : le système d’exploitation et les programmes privilégiés s’exécutent en mode noyau. Le code en mode noyau est autorisé à accéder à n’importe quelle partie du système. Il n’est pas limité comme le code en mode utilisateur. Il peut accéder à n’importe quelle partie de tout autre processus s’exécutant en mode utilisateur ou en mode noyau. La plupart des fonctionnalités principales du système d’exploitation et de nombreux pilotes de périphériques matériels s’exécutent en mode noyau.
Cet exercice couvre les commandes de débogage fréquemment utilisées pendant le débogage en mode utilisateur et en mode noyau. L’exercice couvre également les extensions de débogage, parfois appelées « bang » !commands, qui sont utilisées pour le débogage en mode noyau.
Configuration du laboratoire
Vous avez besoin du matériel suivant pour terminer le labo :
- Ordinateur portable ou ordinateur de bureau exécutant Windows 11
- Un deuxième ordinateur portable ou ordinateur de bureau (cible) exécutant Windows 11
- Un hub réseau ou un routeur et des câbles réseau pour connecter les deux ordinateurs
- Accès à Internet pour télécharger des fichiers de symboles
Vous avez besoin du logiciel suivant pour terminer le labo :
- Visual Studio
- Kit de développement logiciel Windows (SDK) pour Windows 11
- Kit de pilotes Windows (WDK) pour Windows 11
- Exemple de pilote d’écho pour Windows 11
Le labo comporte les sections suivantes :
- Se connecter à une session WinDbg en mode noyau
- Commandes et techniques de débogage en mode noyau
- Télécharger et générer le pilote d’écho KMDF
- Installer l’exemple de pilote echo sur le système cible
- Utiliser WinDbg pour afficher des informations sur le pilote
- Afficher les informations sur l’arborescence des appareils Plug-and-Play
- Travailler avec des points d’arrêt et du code source
- Afficher les variables et les piles d’appels
- Afficher les processus et les threads
- IRQL, inscrit et termine la session WinDbg
- Ressources de débogage Windows
Se connecter à une session WinDbg en mode noyau
Dans cette section, configurez le débogage réseau sur l’hôte et le système cible.
Les ordinateurs de ce labo doivent être configurés pour utiliser une connexion réseau Ethernet pour le débogage du noyau.
Ce laboratoire utilise deux ordinateurs. Le débogueur Windows s’exécute sur le système hôte et le pilote d’écho KMDF (Kernel Mode Driver Framework) s’exécute sur le système cible .
Utilisez un hub réseau ou un routeur et des câbles réseau pour connecter les deux ordinateurs.
Pour utiliser des applications en mode noyau et utiliser WinDbg, nous vous recommandons d’utiliser le réseau KDNET sur le transport Ethernet. Pour plus d’informations sur l’utilisation du protocole de transport Ethernet, consultez Prise en main de WinDbg (mode noyau). Pour plus d’informations sur la configuration de l’ordinateur cible, consultez Préparation d’un ordinateur pour le déploiement manuel de pilotes et configuration du débogage automatique du noyau réseau KDNET.
Configurer le débogage en mode noyau à l’aide d’Ethernet
Enregistrer l’adresse IP de l’hôte
Pour activer le débogage en mode noyau sur le système cible :
Sur le système hôte, ouvrez une fenêtre d’invite de commandes et entrez ipconfig pour déterminer son adresse IPv4.
Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::c8b6:db13:d1e8:b13b%3 Autoconfiguration IPv4 Address. . : 169.182.1.1 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . :
Enregistrez l’adresse IP du système hôte : ______________________________________
Modifier les paramètres de démarrage pour activer le débogage
Activez le débogage en mode noyau sur le système cible en effectuant les étapes suivantes.
Important
Avant d’utiliser BCDEdit pour modifier les informations de démarrage, vous devrez peut-être suspendre temporairement les fonctionnalités de sécurité Windows telles que BitLocker et Le démarrage sécurisé sur l’ordinateur de test. Réactivez ces fonctionnalités de sécurité lorsque le test est terminé. Gérez correctement l’ordinateur de test lorsque les fonctionnalités de sécurité sont désactivées. Le démarrage sécurisé est généralement désactivé dans UEFI. Pour accéder au paramètre UEFI, utilisez le système, la récupération, le démarrage avancé. Lors du redémarrage, sélectionnez Résoudre les problèmes, Options avancées, paramètres du microprogramme UEFI. Utilisez une précaution, car la définition incorrecte des options UEFI ou la désactivation de BitLocker peut rendre le système inopérable.
Avertissement
Pour augmenter la sécurité de la connexion et réduire le risque de demandes de connexion du débogueur client aléatoire, utilisez une clé aléatoire générée automatiquement. Pour plus d’informations, consultez Configurer automatiquement le débogage du noyau réseau KDNET.
Pour utiliser l’utilitaire KDNET pour activer le débogage en mode noyau sur le système cible, procédez comme suit.
Sur le système hôte, recherchez le répertoire KDNET WDK. Par défaut, il se trouve ici.
C :\Program Files (x86)\Windows Kits\10\Debuggers\x64
Ce laboratoire suppose que les deux PC exécutent une version 64 bits de Windows à la fois sur la machine cible et l'hôte. Si ce n'est pas le cas, la meilleure approche consiste à exécuter les outils sur l’hôte en utilisant la même architecture que celle du système cible. Par exemple, si la cible exécute Windows 32 bits, exécutez une version 32 du débogueur sur l’hôte. Pour plus d’informations, consultez Choisir les outils de débogage 32 bits ou 64 bits.
Recherchez ces deux fichiers et copiez-les sur un partage réseau ou un lecteur pouce, afin qu’ils soient disponibles sur l’ordinateur cible.
kdnet.exe
VerifiedNICList.xml
Sur l’ordinateur cible, ouvrez une fenêtre de ligne de commande en tant qu’administrateur. Entrez cette commande pour vérifier que la carte réseau sur le PC cible est prise en charge.
C:\KDNET>kdnet
Network debugging is supported on the following NICs:
busparams=0.25.0, Intel(R) 82579LM Gigabit Network Connection, KDNET is running on this NIC.kdnet.exe
- Tapez cette commande pour définir l’adresse IP du système hôte. Utilisez l’adresse IP réelle du système hôte que vous avez enregistrée au lieu de 169.182.1.1 qui est affichée dans l’exemple de sortie. Choisissez une adresse de port unique pour chaque paire cible/hôte avec laquelle vous travaillez, par exemple 50010.
C:\>kdnet 169.182.1.1 50010
Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.
Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
Entrez cette commande pour confirmer que les valeurs de
dbgsettings
sont correctement configurées :bcdedit /dbgsettings
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p debugtype NET hostip 169.168.1.1 port 50000 dhcp Yes The operation completed successfully.
Remarque
Si vous recevez un message du pare-feu et que vous souhaitez utiliser le débogueur, sélectionnez les trois zones.
Sur l’ordinateur hôte, ouvrez une fenêtre d’invite de commandes en tant qu’administrateur. Ce laboratoire utilise la version x64 de WinDbg.exe à partir du Kit de pilotes Windows (WDK) qui a été installé dans le cadre de l’installation du kit Windows. Passez au répertoire WinDbg par défaut, l’emplacement par défaut est indiqué ci-dessous.
cd C:\Program Files(x86)\Windows Kits\10\Debuggers\x64
Ces laboratoires supposent que les deux ordinateurs exécutent une version 64 bits de Windows sur la cible et l’hôte. Si ce n’est pas le cas, la meilleure approche consiste à exécuter la même architecture d’outils sur l’hôte que celle sur laquelle la cible s’exécute. Par exemple, si la cible exécute Windows 32 bits, exécutez une version 32 bits du débogueur sur l’hôte. Pour plus d’informations, consultez Choisir les outils de débogage 32 bits ou 64 bits.
Ouvrez WinDbg avec le débogage utilisateur distant à l’aide de la commande suivante. Les valeurs de la clé et du port correspondent aux valeurs que vous avez définies précédemment à l’aide de BCDEdit sur l’ordinateur cible.
WinDbg –k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
Redémarrez le système cible.
D'ici une minute ou deux, la sortie de débogage doit être affichée sur le système hôte.
Microsoft (R) Windows Debugger Version 10.0.17074.1002 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Using NET for debugging Opened WinSock 2.0 Waiting to reconnect... Connected to target 169.182.1.1 on port 50005 on local IP 169.182.1.2 You can get the target MAC address by running .kdtargetmac command. Connected to Windows 10 16299 x64 target at (Wed Feb 28 17:16:23.051 2018 (UTC - 8:00)), ptr64 TRUE Kernel Debugger connection established. (Initial Breakpoint requested) Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 16299 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 16299.15.amd64fre.rs3_release.170928-1534 Machine Name: Kernel base = 0xfffff800`9540d000 PsLoadedModuleList = 0xfffff800`95774110 Debug session time: Wed Feb 28 17:16:23.816 2018 (UTC - 8:00) System Uptime: 0 days 0:00:20.534
La fenêtre Commande du débogueur est la fenêtre d’informations de débogage principale dans WinDbg. Vous pouvez entrer des commandes de débogueur et afficher la sortie de commande dans cette fenêtre.
La fenêtre Commande du débogueur est divisée en deux volets. Entrez des commandes dans le volet plus petit, qui est le volet d’entrée de commande en bas de la fenêtre, puis affichez la sortie de commande dans le volet plus grand en haut de la fenêtre.
Dans le volet d’entrée de commande, utilisez la flèche haut et les touches de direction bas pour parcourir l’historique des commandes. Lorsqu’une commande s’affiche, vous pouvez la modifier ou appuyer sur Entrée pour exécuter la commande.
Commandes et techniques de débogage en mode noyau
Dans cette section, utilisez des commandes de débogage pour afficher des informations sur le système cible.
Certaines commandes de débogage affichent du texte à l’aide du langage DML (Debugger Markup Language) que vous pouvez sélectionner pour collecter rapidement plus d’informations.
Sur le système hôte, utilisez ctrl+verrou de défilement dans WinDBg pour décomposer le code en cours d’exécution sur le système cible. La réponse du système cible peut prendre un certain temps.
Entrez la commande suivante pour activer DML dans la fenêtre Commande du débogueur :
0: kd> .prefer_dml 1 DML versions of commands on by default
Vous pouvez accéder à l'aide de commande de référence en utilisant la commande
.hh
. Entrez la commande suivante pour afficher l’aide de référence de commande pour.prefer_dml
:0: kd> .hh .prefer_dml
Le fichier d’aide du débogueur affiche l’aide de la commande
.prefer_dml
.Pour afficher des informations détaillées sur la version du système cible, entrez la commande vertarget (Afficher la version de l’ordinateur cible) dans la fenêtre WinDbg :
0: kd> vertarget Windows 10 Kernel Version 9926 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 9926.0.amd64fre.fbl_awesome1501.150119-1648 Machine Name: "" Kernel base = 0xfffff801`8d283000 PsLoadedModuleList = 0xfffff801`8d58aef0 Debug session time: Fri Feb 20 10:15:17.807 2015 (UTC - 8:00) System Uptime: 0 days 01:31:58.931
Pour vérifier que vous utilisez le processus correct en mode noyau, entrez la commande lm (List Loaded Modules) dans la fenêtre WinDbg pour afficher les modules chargés :
0: Kd> lm start end module name fffff801`09200000 fffff801`0925f000 volmgrx (no symbols) fffff801`09261000 fffff801`092de000 mcupdate_GenuineIntel (no symbols) fffff801`092de000 fffff801`092ec000 werkernel (export symbols) werkernel.sys fffff801`092ec000 fffff801`0934d000 CLFS (export symbols) CLFS.SYS fffff801`0934d000 fffff801`0936f000 tm (export symbols) tm.sys fffff801`0936f000 fffff801`09384000 PSHED (export symbols) PSHED.dll fffff801`09384000 fffff801`0938e000 BOOTVID (export symbols) BOOTVID.dll fffff801`0938e000 fffff801`093f7000 spaceport (no symbols) fffff801`09400000 fffff801`094cf000 Wdf01000 (no symbols) fffff801`094d9000 fffff801`09561000 CI (export symbols) CI.dll ...
La sortie qui a été omise est indiquée avec « ... » dans ce labo.
Pour demander des informations détaillées sur un module spécifique, utilisez l’option
v
(détaillée) :0: Kd> lm v m tcpip Browse full module list start end module name fffff801`09eeb000 fffff801`0a157000 tcpip (no symbols) Loaded symbol image file: tcpip.sys Image path: \SystemRoot\System32\drivers\tcpip.sys Image name: tcpip.sys Browse all global symbols functions data Timestamp: Sun Nov 09 18:59:03 2014 (546029F7) CheckSum: 00263DB1 ImageSize: 0026C000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Unable to enumerate user-mode unloaded modules, Win32 error 0n30
Il n’existe pas de chemin de symbole défini ni de symboles chargés, donc les informations disponibles dans le débogueur sont limitées.
Télécharger et compiler le pilote d’écho KMDF
Dans cette section, téléchargez et générez le pilote d’écho KMDF.
En règle générale, vous travaillez avec votre propre code de pilote lorsque vous utilisez WinDbg. Pour vous familiariser avec le fonctionnement de WinDbg, cet atelier utilise l'exemple de pilote « Echo » basé sur le modèle KMDF. Le code source est disponible pour comprendre les informations affichées dans WinDbg. Cet exemple est également utilisé pour illustrer la façon dont vous pouvez parcourir un seul pas à pas le code en mode noyau natif. Cette technique peut être utile pour le débogage de problèmes complexes de code en mode noyau.
Affichez l’exemple d’écho dans GitHub.
En savoir plus sur l’exemple.
Parcourez tous les exemples de pilotes Windows.
Pour télécharger et compiler le pilote d'échantillon Echo :
Tout d’abord, téléchargez et extrayez l’exemple d’écho KMDF à partir de GitHub.
L’exemple KMDF Echo se trouve dans le dossier général .
Télécharger les exemples de pilotes dans un fichier zip : exemples de pilotes
Téléchargez le fichier zip sur votre disque dur local.
Sélectionnez et maintenez la touche enfoncée ou cliquez avec le bouton droit sur le fichier zip, puis sélectionnez Extraire tout. Spécifiez un nouveau dossier ou accédez à un dossier existant pour stocker les fichiers extraits. Par exemple, vous pouvez spécifier C :\DriverSamples\ comme nouveau dossier dans lequel extraire les fichiers.
Une fois les fichiers extraits, accédez au sous-dossier suivant : C :\DriverSamples\general\echo\kmdf
Dans Microsoft Visual Studio, sélectionnez Fichier>ouvrir>un projet/solution... et accédez au dossier qui contient les fichiers extraits, par exemple , C :\DriverSamples\general\echo\kmdf. Double-cliquez sur le fichier de solution kmdfecho pour l’ouvrir.
Dans Visual Studio, recherchez l’Explorateur de solutions. Si cette fenêtre n’est pas déjà ouverte, sélectionnez l’Explorateur de solutions dans le menu Affichage . Dans l’Explorateur de solutions, vous pouvez voir une solution qui comporte trois projets.
Définissez la configuration et la plateforme de l’exemple. Dans l’Explorateur de solutions, sélectionnez et maintenez ou maintenez le bouton droit sur la solution « kmdfecho » (3 projets), puis sélectionnez Configuration Manager. Assurez-vous que les paramètres de configuration et de plateforme sont identiques pour les trois projets. Par défaut, la configuration est définie sur Win10 Debug et la plateforme est définie sur Win64 pour tous les projets. Si vous apportez des modifications de configuration ou de plateforme pour un projet, apportez les mêmes modifications pour les trois projets restants.
Les exemples de pilotes doivent être modifiés pour utiliser des valeurs qui n'entrent pas en conflit avec les pilotes existants. Reportez-vous à Partir d’un exemple de code à un pilote de production - Qu’est-ce à changer dans les exemples pour créer un exemple de pilote unique qui coexistera avec les pilotes réels existants installés dans Windows.
Définissez la bibliothèque runtime. Ouvrez la page de propriétés du pilote d’écho et recherchez C/C++>Code Generation. Remplacez la bibliothèque d'exécution par Multithread Débogage (/MTd). Pour plus d’informations sur les options de compilation, consultez /MD, /MT, /LD (Utiliser la bibliothèque Run-Time).
Dans les propriétés du pilote, vérifiez que le mode de signature>du pilote est réglé sur Test Sign.
Dans Visual Studio, sélectionnez Générer>Générer la solution.
Les fenêtres de génération doivent afficher un message indiquant que la génération de tous les trois projets a réussi.
Conseil / Astuce
Si vous rencontrez un message d’erreur de build, utilisez le numéro d’erreur de build pour déterminer un correctif. Par exemple, l’erreur MSBuild MSB8040 décrit comment utiliser des bibliothèques atténuées par spectre.
Dans l’Explorateur de fichiers, accédez au dossier qui contient les fichiers extraits pour l’exemple. Par exemple, accédez à C :\DriverSamples\general\echo\kmdf, si c’est le dossier que vous avez spécifié précédemment. Dans ce dossier, l’emplacement des fichiers de pilotes compilés varie en fonction des paramètres de configuration et de plateforme que vous avez sélectionnés dans Configuration Manager. Si vous avez laissé les paramètres par défaut inchangés, les fichiers de pilotes compilés sont enregistrés dans un dossier nommé \x64\Debug pour une build de débogage 64 bits.
Accédez au dossier qui contient les fichiers générés pour le pilote de synchronisation automatique : C :\DriverSamples\general\echo\kmdf\driver\AutoSync\x64\Debug.
Le dossier doit contenir ces fichiers :
Fichier Descriptif Echo.sys Fichier du pilote. Echo.inf Fichier d’informations (INF) qui contient les informations nécessaires pour installer le pilote. En outre, le fichier echoapp.exe a été généré et doit se trouver ici : C :\DriverSamples\general\echo\kmdf\exe\x64\Debug.
Fichier Descriptif EchoApp.exe Un fichier de test exécutable du terminal de commande qui communique avec le pilote echo.sys. Recherchez un lecteur USB ou configurez un partage réseau pour copier les fichiers de pilotes construits et l'application EchoApp de l'hôte vers le système cible.
Dans la section suivante, copiez le code dans le système cible, installez et testez le pilote.
Installer l’exemple de pilote d’écho KMDF sur le système cible
Dans cette section, utilisez l’outil DevCon pour installer l’exemple de pilote echo.
L’ordinateur sur lequel vous installez le pilote est appelé l’ordinateur cible ou l’ordinateur de test. En règle générale, cet ordinateur est distinct de l’ordinateur sur lequel vous développez et générez le package de pilotes. L’ordinateur sur lequel vous développez et générez le pilote est appelé l’ordinateur hôte.
Le processus de déplacement du package de pilotes vers l’ordinateur cible et l’installation du pilote est appelé déploiement du pilote.
Avant de déployer un pilote de test signé, préparez l'ordinateur cible en activant la signature de test. Vous devez également localiser l’outil DevCon dans votre installation wdK et le copier sur le système cible.
Pour installer le pilote sur le système cible, procédez comme suit.
Sur le système cible, activez les pilotes de test signés :
Ouvrez Paramètres Windows.
Dans Update and Security, sélectionnez Récupération.
Sous Démarrage avancé, sélectionnez Redémarrer maintenant.
Lorsque l’ordinateur redémarre, sélectionnez les options de démarrage. Dans Windows 11, sélectionnez Dépannage>Options avancées>Paramètres de démarrage, puis sélectionnez Redémarrer.
Sélectionnez Désactiver l’application de la signature du pilote en appuyant sur la touche F7.
Redémarrer l’ordinateur cible.
Sur le système hôte, accédez au dossier Outils de votre installation WDK et recherchez l’outil DevCon. Par exemple, recherchez dans le dossier suivant : C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon.exe.
Créez un dossier à l'emplacement de destination pour le package de pilotes généré, par exemple C :\EchoDriver. Copiez devcon.exe sur le système cible. Recherchez le certificat .cer sur le système hôte. Il se trouve dans le même dossier sur l’ordinateur hôte dans le dossier qui contient les fichiers de pilote générés. Copiez tous les fichiers du pilote généré décrit précédemment sur l’ordinateur hôte et enregistrez-les dans le même dossier que celui que vous avez créé sur l’ordinateur cible.
Sur l’ordinateur cible, sélectionnez et maintenez ou maintenez le bouton droit sur le fichier de certificat, puis sélectionnez Installer, puis suivez les invites pour installer le certificat de test.
Si vous avez besoin d’instructions plus détaillées pour configurer l’ordinateur cible, consultez Préparation d’un ordinateur pour le déploiement manuel de pilotes.
Les instructions suivantes vous montrent comment installer et tester l’exemple de pilote. Voici la syntaxe générale de l’outil devcon que vous utilisez pour installer le pilote :
devcon install <INF file> <hardware ID>
Le fichier INF requis pour l’installation de ce pilote est echo.inf. Le fichier inf contient l’ID matériel pour l’installation du echo.sys. Pour l’exemple d’écho, l’ID matériel est root\ECHO.
Sur l’ordinateur cible, ouvrez une fenêtre de ligne de commande en tant qu’administrateur. Accédez à votre dossier de package de pilotes, puis entrez la commande suivante :
devcon install echo.inf root\ECHO
Si vous recevez un message d’erreur indiquant que devcon n'est pas reconnu, essayez d’ajouter le chemin à l’outil devcon. Par exemple, si vous l’avez copiée dans un dossier appelé C :\Tools, essayez d’utiliser la commande suivante :
c:\tools\devcon install echo.inf root\ECHO
Une boîte de dialogue s’affiche indiquant que le pilote de test est un pilote non signé. Sélectionnez Installer ce pilote quand même pour continuer.
Conseil / Astuce
Si vous rencontrez des problèmes avec l’installation, consultez le fichier suivant pour plus d’informations. %windir%\inf\setupapi.dev.log
Après avoir installé l’exemple de pilote, vous êtes prêt à le tester.
Sur l’ordinateur cible, dans une fenêtre d’invite de commandes, entrez devmgmt pour ouvrir Device Manager. Dans le Gestionnaire de périphériques, dans le menu Affichage , choisissez Appareils par type. Dans l’arborescence de l’appareil, recherchez l’exemple de pilote Echo WDF dans l’exemple de nœud d’appareil .
Entrez echoapp pour démarrer l’application d’écho de test pour confirmer que le pilote est fonctionnel.
C:\Samples\KMDF_Echo_Sample> echoapp
DevicePath: \\?\root#sample#0005#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
Opened device successfully
512 Pattern Bytes Written successfully
512 Pattern Bytes Read successfully
Pattern Verified successfully
30720 Pattern Bytes Written successfully
30720 Pattern Bytes Read successfully
Pattern Verified successfully
Utiliser WinDbg pour afficher des informations sur le pilote
Dans cette section, définissez le chemin du symbole et utilisez les commandes du débogueur du noyau pour afficher des informations sur le pilote d’exemple d’écho KMDF.
Pour afficher des informations sur le pilote :
Sur le système hôte, si vous avez fermé le débogueur, ouvrez-le à nouveau à l’aide de la commande suivante dans la fenêtre d'invite de commandes en tant qu'administrateur.
WinDbg -k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
Utilisez Ctrl+Arrêt (verrouillage de défilement) pour entrer dans le code en cours d’exécution sur le système cible.
Pour définir le chemin des symboles sur le serveur de symboles Microsoft dans l’environnement WinDbg, utilisez la
.symfix
commande.0: kd> .symfix
Pour ajouter l'emplacement de vos symboles locaux afin d'utiliser ceux-ci, ajoutez le chemin d'accès à l'aide de
.sympath+
puis de.reload /f
.0: kd> .sympath+ C:\DriverSamples\general\echo\kmdf 0: kd> .reload /f
La
.reload
commande avec l’option/f
force supprime toutes les informations de symbole pour le module spécifié et recharge les symboles. Dans certains cas, cette commande recharge également ou décharge le module lui-même.
Vous devez charger les symboles appropriés pour utiliser des fonctionnalités avancées que WinDbg fournit. Si vous n’avez pas correctement configuré de symboles, lorsque vous tentez d’utiliser des fonctionnalités dépendantes des symboles, vous recevez des messages indiquant que les symboles ne sont pas disponibles.
0:000> dv
Unable to enumerate locals, HRESULT 0x80004005
Private symbols (symbols.pri) are required for locals.
Type “.hh dbgerr005” for details.
Il existe de nombreuses approches qui peuvent être utilisées pour utiliser des symboles. Dans de nombreuses situations, vous pouvez configurer l’ordinateur pour accéder aux symboles à partir d’un serveur de symboles fourni par Microsoft lorsqu’il est nécessaire. Ce laboratoire utilise cette approche. Si les symboles de votre environnement se trouvent dans un autre emplacement, modifiez les étapes à suivre pour utiliser cet emplacement. Pour plus d’informations, consultez le chemin des symboles pour le débogueur Windows.
Pour effectuer le débogage source, vous devez générer une version vérifiée (debug) de vos fichiers binaires. Le compilateur crée des fichiers de symboles (fichiers .pdb ). Ces fichiers de symboles montrent le débogueur comment les instructions binaires correspondent aux lignes sources. Les fichiers sources réels eux-mêmes doivent également être accessibles au débogueur.
Les fichiers de symboles ne contiennent pas le texte du code source. Pour le débogage, il est préférable que l’éditeur de liens n’optimise pas votre code. Le débogage source et l’accès aux variables locales sont plus difficiles, et parfois presque impossibles, si le code a été optimisé. Si vous rencontrez des problèmes lors de l’affichage des variables locales ou des lignes sources, définissez les options de génération suivantes :
set COMPILE_DEBUG=1
set ENABLE_OPTIMIZER=0
Entrez la commande suivante dans la zone de commande du débogueur pour afficher des informations sur le pilote echo :
0: kd> lm m echo* v Browse full module list start end module name fffff801`4ae80000 fffff801`4ae89000 ECHO (private pdb symbols) C:\Samples\KMDF_ECHO_SAMPLE\echo.pdb Loaded symbol image file: ECHO.sys Image path: \SystemRoot\system32\DRIVERS\ECHO.sys Image name: ECHO.sys ...
Pour plus d’informations, consultez lm.
Comme ce labo est défini
prefer_dml
précédemment, certains éléments de la sortie sont des liens chauds que vous pouvez sélectionner. Sélectionnez le lien Parcourir tous les symboles globaux dans la sortie de débogage pour afficher des informations sur les symboles d’éléments qui commencent par la lettre « a ».0: kd> x /D Echo!a*
L’exemple d’écho ne contient aucun symbole commençant par la lettre « a », de sorte que tapez
x ECHO!Echo*
pour afficher des informations sur tous les symboles associés au pilote d’écho qui commencent par « Echo ».0: kd> x ECHO!Echo* fffff801`0bf95690 ECHO!EchoEvtIoQueueContextDestroy (void *) fffff801`0bf95000 ECHO!EchoEvtDeviceSelfManagedIoStart (struct WDFDEVICE__ *) fffff801`0bf95ac0 ECHO!EchoEvtTimerFunc (struct WDFTIMER__ *) fffff801`0bf9b120 ECHO!EchoEvtDeviceSelfManagedIoSuspend (struct WDFDEVICE__ *) ...
Pour plus d’informations, consultez x (Examiner les symboles).
L’extension
!lmi
affiche des informations détaillées sur un module. Saisissez!lmi echo
. Votre sortie doit être similaire au texte présenté dans cet exemple :0: kd> !lmi echo Loaded Module Info: [echo] Module: ECHO Base Address: fffff8010bf94000 Image Name: ECHO.sys …
Utilisez l’extension
!dh
pour afficher les informations d’en-tête comme indiqué dans cet exemple :0: kd> !dh echo File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (i386) 6 number of sections 54AD8A42 time date stamp Wed Jan 07 11:34:26 2015 ...
Entrez les éléments suivants pour modifier le masque de bits de débogage par défaut afin que tous les messages de débogage du système cible soient affichés dans le débogueur :
0: kd> ed nt!Kd_DEFAULT_MASK 0xFFFFFFFF
Certains pilotes affichent des informations supplémentaires lorsque le masque de 0xFFFFFFFF est utilisé. Définissez le masque sur 0x00000000 si vous souhaitez réduire la quantité d’informations affichées.
0: kd> ed nt!Kd_DEFAULT_MASK 0x00000000
Utilisez la
dd
commande pour confirmer que le masque est défini pour afficher tous les messages du débogueur.0: kd> dd nt!kd_DEFAULT_MASK fffff802`bb4057c0 ffffffff 00000000 00000000 00000000 fffff802`bb4057d0 00000000 00000000 00000000 00000000 fffff802`bb4057e0 00000001 00000000 00000000 00000000 fffff802`bb4057f0 00000000 00000000 00000000 00000000 fffff802`bb405800 00000000 00000000 00000000 00000000 fffff802`bb405810 00000000 00000000 00000000 00000000 fffff802`bb405820 00000000 00000000 00000000 00000000 fffff802`bb405830 00000000 00000000 00000000 00000000
Afficher les informations sur l’arborescence des appareils Plug-and-Play
Dans cette section, affichez des informations sur l’exemple de pilote d’appareil echo et sur son emplacement dans l’arborescence de l’appareil Plug-and-Play.
Les informations sur le pilote de périphérique dans l’arborescence d’appareils Plug-and-Play peuvent être utiles pour résoudre les problèmes. Par exemple, si un pilote de périphérique n’est pas présent dans l’arborescence du périphérique, il peut y avoir un problème avec l’installation du pilote de périphérique.
Pour plus d’informations sur l’extension de débogage du nœud d’appareil, consultez !devnode.
Sur le système hôte, pour afficher tous les nœuds d’appareil dans l’arborescence d’appareils Plug-and-Play, entrez la
!devnode 0 1
commande.0: kd> !devnode 0 1 Dumping IopRootDeviceNode (= 0xffffe0005a3a8d30) DevNode 0xffffe0005a3a8d30 for PDO 0xffffe0005a3a9e50 InstancePath is "HTREE\ROOT\0" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) DevNode 0xffffe0005a3a3d30 for PDO 0xffffe0005a3a4e50 InstancePath is "ROOT\volmgr\0000" ServiceName is "volmgr" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) DevNode 0xffffe0005a324560 for PDO 0xffffe0005bd95ca0… …
Utilisez Ctrl+F pour rechercher dans la sortie générée pour rechercher le nom du pilote de périphérique, écho.
Le pilote de périphérique Echo doit être chargé. Utilisez la
!devnode 0 1 echo
commande pour afficher les informations Plug-and-Play associées à votre pilote de périphérique echo, comme illustré dans cet exemple :0: Kd> !devnode 0 1 echo Dumping IopRootDeviceNode (= 0xffffe0007b725d30) DevNode 0xffffe0007b71a630 for PDO 0xffffe0007b71a960 InstancePath is "ROOT\SAMPLE\0000" ServiceName is "ECHO" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeEnumerateCompletion (0x30d) …
La sortie affichée dans la commande précédente inclut le PDO associé à l’instance actuelle de votre pilote, dans cet exemple, 0xffffe0007b71a960. Entrez la
!devobj <PDO address>
commande pour afficher les informations Plug-and-Play associées au pilote de périphérique echo. Utilisez l’adresse PDO qui!devnode
s’affiche sur votre ordinateur, et non celle affichée ici.0: kd> !devobj 0xffffe0007b71a960 Device object (ffffe0007b71a960) is for: 0000000e \Driver\PnpManager DriverObject ffffe0007b727e60 Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040 Dacl ffffc102c9b36031 DevExt 00000000 DevObjExt ffffe0007b71aab0 DevNode ffffe0007b71a630 ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN AttachedDevice (Upper) ffffe000801fee20 \Driver\ECHO Device queue is not busy.
La sortie affichée dans la
!devnode 0 1
commande inclut l’adresse PDO associée à l’instance en cours d’exécution de votre pilote, dans cet exemple, elle est 0xffffe0007b71a960. Entrez la!devstack <PDO address>
commande pour afficher les informations Plug-and-Play associées au pilote de périphérique. Utilisez l’adresse PDO qui!devnode
s’affiche sur votre ordinateur, et non celle indiquée dans cet exemple.0: kd> !devstack 0xffffe0007b71a960 !DevObj !DrvObj !DevExt ObjectName ffffe000801fee20 \Driver\ECHO ffffe0007f72eff0 > ffffe0007b71a960 \Driver\PnpManager 00000000 0000000e !DevNode ffffe0007b71a630 : DeviceInst is "ROOT\SAMPLE\0000" ServiceName is "ECHO"
La sortie indique que vous disposez d’une pile de pilotes de périphérique assez simple. Le pilote d’écho est un sous-composant du nœud PnPManager. PnPManager est un nœud racine.
\Driver\ECHO
\Driver\PnpManager
Ce diagramme montre une arborescence de nœuds d’appareil plus complexe.
Pour plus d’informations sur les piles de pilotes plus complexes, consultez les sections piles de pilotes et nœuds d’appareils et piles d’appareils.
Travailler avec des points d’arrêt et du code source
Dans cette section, définissez des points d'arrêt et exécutez le code source en mode noyau étape par étape.
Pour pouvoir parcourir le code et vérifier les valeurs des variables en temps réel, activez les points d’arrêt et définissez un chemin d’accès au code source.
Les points d’arrêt arrêtent l’exécution du code à une ligne de code particulière. Progressez dans le code à partir de ce point pour déboguer cette section spécifique du code.
Pour définir un point d’arrêt à l’aide d’une commande de débogage, utilisez l’une des commandes suivantes b
.
Commande | Descriptif |
---|---|
bp |
Définit un point d’arrêt actif jusqu’à ce que le module dans lequel il se trouve soit déchargé. |
bu |
Définit un point d’arrêt non résolu lorsque le module est déchargé et réactivé lors du rechargement du module. |
bm |
Définit un point d’arrêt pour un symbole. Cette commande utilise bu ou bp de manière appropriée et permet l'utilisation de caractères génériques (* ) pour définir des points d’arrêt sur chaque symbole correspondant, comme toutes les méthodes d’une classe. |
Pour plus d’informations, consultez débogage du code source dans WinDbg.
Sur le système hôte, utilisez l’interface utilisateur WinDbg pour vérifier que lemode sourcede débogage> est activé dans la session WinDbg actuelle.
Entrez la commande suivante pour ajouter votre emplacement de code local au chemin d’accès source :
.srcpath+ C:\DriverSamples\KMDF_Echo_Sample\driver\AutoSync
Entrez la commande suivante pour ajouter votre emplacement de symbole local au chemin des symboles :
.sympath+ C:\DriverSamples\KMDF_Echo_Sample\driver\AutoSync
Utilisez la
x
commande pour examiner les symboles associés au pilote d’écho pour déterminer le nom de la fonction à utiliser pour le point d’arrêt. Vous pouvez utiliser un caractère générique ou Ctrl+F pour localiser le nom de laDeviceAdd
fonction.0: kd> x ECHO!EchoEvt* 8b4c7490 ECHO!EchoEvtIoQueueContextDestroy (void *) 8b4c7000 ECHO!EchoEvtDeviceSelfManagedIoStart (struct WDFDEVICE__ *) 8b4c7820 ECHO!EchoEvtTimerFunc (struct WDFTIMER__ *) 8b4cb0e0 ECHO!EchoEvtDeviceSelfManagedIoSuspend (struct WDFDEVICE__ *) 8b4c75d0 ECHO!EchoEvtIoWrite (struct WDFQUEUE__ *, struct WDFREQUEST__ *, unsigned int) 8b4cb170 ECHO!EchoEvtDeviceAdd (struct WDFDRIVER__ *, struct …
La sortie indique que la méthode de votre pilote d’écho
DeviceAdd
estECHO!EchoEvtDeviceAdd
.Vous pouvez également consulter le code source pour trouver le nom de la fonction pour votre point d’arrêt.
Définissez le point d’arrêt avec la
bm
commande en utilisant le nom du pilote, suivi du nom de la fonction, par exemple,AddDevice
où vous souhaitez définir le point d’arrêt, séparé par une marque d’exclamation. Ce laboratoire utiliseAddDevice
pour surveiller le chargement du pilote.0: kd> bm ECHO!EchoEvtDeviceAdd 1: fffff801`0bf9b1c0 @!"ECHO!EchoEvtDeviceAdd"
Vous pouvez utiliser une syntaxe différente conjointement avec la définition de variables telles que
<module>!<symbol>
,<class>::<method>
'<file.cpp>:<line number>'
ou ignorer un certain nombre de fois<condition> <#>
. Pour plus d’informations, consultez les points d’arrêt conditionnels dans WinDbg et d’autres débogueurs Windows.Répertoriez les points d’arrêt actuels pour confirmer que le point d’arrêt a été défini en entrant la
bl
commande :0: kd> bl 1 e fffff801`0bf9b1c0 0001 (0001) ECHO!EchoEvtDeviceAdd
La lettre « e » dans la sortie indiquée ici précise que le point d'arrêt numéro 1 est activé pour se déclencher.
Redémarrez l’exécution du code sur le système cible en entrant la
g
commande (go).Sur le système cible, dans Windows, ouvrez Device Manager à l’aide de l’icône ou entrez mmc devmgmt.msc. Dans Device Manager, développez le nœud Exemples .
Sélectionnez et maintenez la touche enfoncée ou cliquez avec le bouton droit sur l’entrée du pilote d’écho KMDF, puis sélectionnez Désactiver dans le menu.
Sélectionnez et maintenez la touche enfoncée ou cliquez avec le bouton droit sur l’entrée du pilote d’écho KMDF à nouveau, puis sélectionnez Activer dans le menu.
Sur le système hôte, lorsque le pilote est activé, le point d'arrêt de débogage AddDevice devrait se déclencher. L’exécution du code du pilote sur le système cible doit s’arrêter. Lorsque le point d’arrêt est atteint, l’exécution doit être arrêtée au début de la routine AddDevice . La sortie de la commande de débogage s’affiche
Breakpoint 1 hit
.Parcourez la ligne de code par ligne en entrant la
p
commande ou en appuyant sur F10 jusqu’à atteindre la fin suivante de la routine AddDevice . Le caractère accolades (}
) est mis en surbrillance comme indiqué.
Dans la section suivante, examinez l’état des variables après l’exécution du code DeviceAdd.
Vous pouvez modifier des points d’arrêt existants à l’aide des commandes suivantes :
Commande | Descriptif |
---|---|
bl |
Répertorie les points d’arrêt. |
bc |
Supprime un point d’arrêt de la liste. Utilisez bc * pour effacer tous les points d’arrêt. |
bd |
Désactive un point d’arrêt. Utilisez bd * pour désactiver tous les points d'arrêt. |
be |
Permet d'activer un point d'arrêt. Utilisez be * pour activer tous les points d’arrêt. |
Alternativement, vous pouvez également modifier des points d’arrêt dans l’interface utilisateur de WinDbg.
Vous pouvez également définir des points d’arrêt qui se déclenchent lorsqu’un emplacement mémoire est accessible. Utilisez la ba
commande (break on access) avec la syntaxe suivante :
ba <access> <size> <address> {options}
Choix | Descriptif |
---|---|
e |
execute : quand le processeur récupère une instruction à partir de l’adresse |
r |
lecture/écriture : lorsque le processeur lit ou écrit à l'adresse |
w |
écrire : lorsque le processeur écrit à l'adresse |
Vous ne pouvez définir que quatre points d’arrêt de données à tout moment. C’est à vous de vous assurer que vous alignez correctement vos données pour déclencher le point d’arrêt. Les mots doivent se terminer par des adresses divisibles par 2, les mots doivent être divisibles par 4 et les mots quad par 0 ou 8.
Par exemple, pour définir un point d’arrêt en lecture/écriture sur une adresse mémoire spécifique, vous pouvez utiliser une commande comme cet exemple.
ba r 4 0x0003f7bf0
Vous pouvez utiliser les commandes suivantes pour parcourir votre code avec les raccourcis clavier associés affichés entre parenthèses.
- Arrêt (Ctrl+Arrêt). Cette commande interrompt un système tant que le système est en cours d’exécution et est en communication avec WinDbg. La séquence dans le débogueur du noyau est Ctrl+C.
- Exécutez le curseur (F7 ou Ctrl+F10). Placez le curseur dans une fenêtre source ou désassembleur dans laquelle vous souhaitez que l’exécution s’interrompe, puis appuyez sur F7. L’exécution du code se poursuit jusqu’à ce point. Si le flux d’exécution du code n’atteint pas le point indiqué par le curseur, WinDbg ne s’arrête pas. Cette situation peut se produire si une instruction IF n’est pas exécutée.
- Exécuter (F5). Exécutez jusqu’à ce qu’un point d’arrêt soit rencontré ou qu’un événement tel qu’une vérification de bogue se produit.
- Pas à pas (F10). Cette commande entraîne l'exécution du code pour avancer d'une déclaration ou d'une instruction à la fois. Si un appel est rencontré, l’exécution du code ignore l'appel sans entrer dans la routine appelée. Si le langage de programmation est C ou C++ et que WinDbg est en mode source, vous pouvez activer ou désactiver le mode source à l'aide de Débogage>Mode Source.
- Entrer (F11). Cette commande est semblable au pas à pas (step-over), sauf que l'exécution d'un appel entre dans la routine appelée.
- Sortir (Maj+F11). Cette commande entraîne l’exécution vers et la sortie de la routine actuelle ou de l’emplacement actuel dans la pile des appels. Cette commande est utile si vous avez vu suffisamment de routine.
Pour plus d’informations, consultez débogage du code source dans WinDbg.
Afficher les variables et les piles d’appels
Dans cette section, affichez des informations sur les variables et les piles d’appels.
Ce laboratoire suppose que vous êtes arrêté à la routine AddDevice à l’aide du processus décrit précédemment. Pour afficher la sortie affichée ici, répétez les étapes décrites précédemment, si nécessaire.
Sur le système hôte, pour afficher des variables, utilisez l’élément de menulocald’affichage> pour afficher les variables locales.
Pour rechercher l’emplacement d’une adresse de variable globale, entrez ? <variable name>
.
- Pas à pas (Maj+F11) : cette commande entraîne l’exécution et la sortie de la routine actuelle (emplacement actuel dans la pile des appels). Cela est utile si vous avez vu assez de routine.
Pour plus d’informations, consultez Le débogage du code source dans WinDbg (classique) dans la documentation de référence sur le débogage.
Section 8 : Affichage des variables et des piles d’appels
Dans la section 8, vous allez afficher des informations sur les variables et les piles d’appels.
Ce laboratoire part du principe que vous êtes arrêté à la routine AddDevice à l’aide du processus décrit précédemment. Pour afficher la sortie ici, répétez les étapes décrites précédemment, si nécessaire.
<- Sur le système hôte
Afficher les variables
Utilisez l’élément de menu affichage>local pour afficher les variables locales.
Variables globales
Vous pouvez trouver l’emplacement d’une adresse de variable globale en tapant ? <nom> de la variable.
Variables locales
Vous pouvez afficher les noms et valeurs de toutes les variables locales d’une trame donnée en tapant la commande dv .
Pour afficher les noms et les valeurs de toutes les variables locales pour un frame spécifique, entrez la dv
commande :
0: kd> dv
Driver = 0x00001fff`7ff9c838
DeviceInit = 0xffffd001`51978190
status = 0n0
La pile d'appels est la suite d’appels de fonction qui ont conduit à l’emplacement actuel du compteur de programme. La fonction supérieure de la pile des appels est la fonction actuelle, et la fonction suivante est la fonction qui a appelé la fonction actuelle, et ainsi de suite.
Pour afficher la pile des appels, utilisez les k*
commandes.
Commande | Descriptif |
---|---|
kb |
Affiche la pile et les trois premiers paramètres. |
kp |
Affiche les piles et la liste complète des paramètres. |
kn |
Vous permet de voir la pile avec les informations de cadre à côté. |
Sur le système hôte, si vous souhaitez conserver la pile des appels disponible, sélectionnez afficher> lapile des appels pour l’afficher. Sélectionnez les colonnes en haut de la fenêtre pour activer/désactiver l’affichage d’informations supplémentaires.
Utilisez la
kn
commande pour afficher la pile des appels lors du débogage de l’exemple de code de l’adaptateur dans un état d’arrêt.3: kd> kn # Child-SP RetAddr Call Site 00 ffffd001`51978110 fffff801`0942f55b ECHO!EchoEvtDeviceAdd+0x66 [c:\Samples\kmdf echo sample\c++\driver\autosync\driver.c @ 138] 01 (Inline Function) --------`-------- Wdf01000!FxDriverDeviceAdd::Invoke+0x30 [d:\wbrtm\minkernel\wdf\framework\shared\inc\private\common\fxdrivercallbacks.hpp @ 61] 02 ffffd001`51978150 fffff801`eed8097d Wdf01000!FxDriver::AddDevice+0xab [d:\wbrtm\minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 72] 03 ffffd001`51978570 fffff801`ef129423 nt!PpvUtilCallAddDevice+0x35 [d:\9142\minkernel\ntos\io\pnpmgr\verifier.c @ 104] 04 ffffd001`519785b0 fffff801`ef0c4112 nt!PnpCallAddDevice+0x63 [d:\9142\minkernel\ntos\io\pnpmgr\enum.c @ 7397] 05 ffffd001`51978630 fffff801`ef0c344f nt!PipCallDriverAddDevice+0x6e2 [d:\9142\minkernel\ntos\io\pnpmgr\enum.c @ 3390] ...
La pile des appels indique que le noyau (nt) a appelé le code Plug and Play (PnP) qui a appelé le code du framework de pilote (WDF) qui a appelé ultérieurement la fonction d’écho du pilote DeviceAdd
.
Afficher les processus et les threads
Dans cette section, affichez des informations sur les processus et les threads en cours d’exécution en mode noyau.
Processus
Vous pouvez afficher ou définir des informations de processus à l’aide de l’extension du débogueur !process . Définissez un point d’arrêt pour examiner le processus utilisé lorsqu’un son est lu.
Sur le système hôte, entrez la
dv
commande pour examiner les variables de paramètres régionaux associées à laEchoEvtIo
routine :0: kd> dv ECHO!EchoEvtIo* ECHO!EchoEvtIoQueueContextDestroy ECHO!EchoEvtIoWrite ECHO!EchoEvtIoRead
Effacez les points d’arrêt précédents à l’aide de
bc *
.0: kd> bc *
Définissez un point d’arrêt de symbole sur les
EchoEvtIo
routines à l’aide de la commande suivante :0: kd> bm ECHO!EchoEvtIo* 2: aade5490 @!”ECHO!EchoEvtIoQueueContextDestroy” 3: aade55d0 @!”ECHO!EchoEvtIoWrite” 4: aade54c0 @!”ECHO!EchoEvtIoRead”
Répertoriez les points d’arrêt pour vérifier que le point d’arrêt est correctement défini :
0: kd> bl 1 e aabf0490 [c:\Samples\kmdf echo sample\c++\driver\autosync\queue.c @ 197] 0001 (0001) ECHO!EchoEvtIoQueueContextDestroy ...
Entrez
g
pour redémarrer l’exécution du code :0: kd> g
Sur le système cible, exécutez le
EchoApp.exe
programme de test de pilotes sur le système cible.Sur le système hôte, lorsque l’application de test s’exécute, la routine d’E/S dans le pilote est appelée. Cet appel provoque le déclenchement du point d’arrêt et interrompt l’exécution du code du pilote sur le système cible.
Breakpoint 2 hit ECHO!EchoEvtIoWrite: fffff801`0bf95810 4c89442418 mov qword ptr [rsp+18h],r8
Utilisez la
!process
commande pour afficher le processus actuel impliqué dans l’exécution deechoapp.exe:0: kd> !process PROCESS ffffe0007e6a7780 SessionId: 1 Cid: 03c4 Peb: 7ff7cfec4000 ParentCid: 0f34 DirBase: 1efd1b000 ObjectTable: ffffc001d77978c0 HandleCount: 34. Image: echoapp.exe VadRoot ffffe000802c79f0 Vads 30 Clone 0 Private 135. Modified 5. Locked 0. DeviceMap ffffc001d83c6e80 Token ffffc001cf270050 ElapsedTime 00:00:00.052 UserTime 00:00:00.000 KernelTime 00:00:00.000 QuotaPoolUsage[PagedPool] 33824 QuotaPoolUsage[NonPagedPool] 4464 Working Set Sizes (now,min,max) (682, 50, 345) (2728KB, 200KB, 1380KB) PeakWorkingSetSize 652 VirtualSize 16 Mb PeakVirtualSize 16 Mb PageFaultCount 688 MemoryPriority BACKGROUND BasePriority 8 CommitCharge 138 THREAD ffffe00080e32080 Cid 03c4.0ec0 Teb: 00007ff7cfece000 Win32Thread: 0000000000000000 RUNNING on processor 1
La sortie indique que le processus est associé au thread echoapp.exe , qui s’exécutait lorsque votre point d’arrêt sur l’événement d’écriture du pilote a été atteint. Pour plus d’informations, consultez !process.
Utilisez l’option
!process 0 0
pour afficher des informations récapitulatives pour tous les processus. Dans la sortie, utilisez Ctrl+F pour localiser la même adresse de processus pour le processus associé à l’imageechoapp.exe . Dans l’exemple, l’adresse du processus estffffe0007e6a7780
.... PROCESS ffffe0007e6a7780 SessionId: 1 Cid: 0f68 Peb: 7ff7cfe7a000 ParentCid: 0f34 DirBase: 1f7fb9000 ObjectTable: ffffc001cec82780 HandleCount: 34. Image: echoapp.exe ...
Enregistrez l’ID de processus associé à echoapp.exe à utiliser ultérieurement dans ce labo. Vous pouvez également utiliser Ctrl+C pour copier l’adresse dans la mémoire tampon de copie pour une utilisation ultérieure.
_____________________________________________________( adresse de processusechoapp.exe)
Entrez
g
dans le débogueur au besoin pour avancer dans l'exécution du code jusqu'à ce que echoapp.exe ait terminé son exécution. Il atteint le point d'arrêt lors des événements de lecture et d'écriture plusieurs fois. Lorsque echoapp.exe se termine, passez en mode débogueur en appuyant sur Ctrl+ScrLk (Ctrl+Arrêt).Utilisez la
!process
commande pour confirmer que vous exécutez un autre processus. Dans la sortie illustrée ici, le processus avec la valeur d'image System est différent de la valeur d'image Echo.1: kd> !process PROCESS ffffe0007b65d900 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 001ab000 ObjectTable: ffffc001c9a03000 HandleCount: 786. Image: System VadRoot ffffe0007ce45930 Vads 14 Clone 0 Private 22. Modified 131605. Locked 64. DeviceMap ffffc001c9a0c220 Token ffffc001c9a05530 ElapsedTime 21:31:02.516 ...
La sortie indique qu’un processus système ffffe0007b65d900 s’exécutait lorsque vous avez arrêté le système d’exploitation.
Utilisez la
!process
commande pour essayer d’examiner l’ID de processus associé à echoapp.exe que vous avez enregistré précédemment. Fournissez votre adresse de processusechoapp.exe que vous avez enregistrée précédemment, au lieu de l’exemple d’adresse de processus indiquée dans cet exemple.0: kd> !process ffffe0007e6a7780 TYPE mismatch for process object at 82a9acc0
L’objet de processus n’est plus disponible, car le processus echoapp.exe n’est plus en cours d’exécution.
Fils de discussion
Les commandes permettant d’afficher et de définir des threads sont similaires aux commandes pour les processus. Utilisez la commande !thread pour afficher les threads. Utilisez .thread pour définir les threads actuels.
Sur le système hôte, entrez
g
dans le débogueur pour redémarrer l’exécution du code sur le système cible.Sur le système cible, exécutez le programme de test de pilotes EchoApp.exe.
Sur le système hôte, le point d’arrêt est atteint et l’exécution du code s’arrête.
Breakpoint 4 hit ECHO!EchoEvtIoRead: aade54c0 55 push ebp
Pour afficher les threads en cours d’exécution, entrez !thread. Les informations similaires à l’exemple suivant doivent être affichées :
0: kd> !thread THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING on processor 0 IRP List: ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000 Not impersonating DeviceMap ffffc001d83c6e80 Owning Process ffffe0008096c900 Image: echoapp.exe ...
Notez le nom d'image de echoapp.exe. Cela indique que vous examinez le thread associé à l’application de test.
Utilisez la
!process
commande pour déterminer si ce thread est le seul thread en cours d’exécution dans le processus associé à echoapp.exe. Le numéro du thread en cours d’exécution dans le processus correspond au thread affiché par la commande!thread
.0: kd> !process PROCESS ffffe0008096c900 SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34 DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34. Image: echoapp.exe VadRoot ffffe000800cf920 Vads 30 Clone 0 Private 135. Modified 8. Locked 0. DeviceMap ffffc001d83c6e80 Token ffffc001cf5dc050 ElapsedTime 00:00:00.048 UserTime 00:00:00.000 KernelTime 00:00:00.000 QuotaPoolUsage[PagedPool] 33824 QuotaPoolUsage[NonPagedPool] 4464 Working Set Sizes (now,min,max) (681, 50, 345) (2724KB, 200KB, 1380KB) PeakWorkingSetSize 651 VirtualSize 16 Mb PeakVirtualSize 16 Mb PageFaultCount 686 MemoryPriority BACKGROUND BasePriority 8 CommitCharge 138 THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING on processor 0
Utilisez la
!process 0 0
commande pour localiser l’adresse de processus de deux processus connexes et enregistrer ces adresses de processus ici.Cmd.exe: ____________________________________________________________
EchoApp.exe: _______________________________________________________
0: kd> !process 0 0 … PROCESS ffffe0007bbde900 SessionId: 1 Cid: 0f34 Peb: 7ff72dfa7000 ParentCid: 0c64 DirBase: 19c5fa000 ObjectTable: ffffc001d8c2f300 HandleCount: 31. Image: cmd.exe … PROCESS ffffe0008096c900 SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34 DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34. Image: echoapp.exe …
Vous pouvez également utiliser
!process 0 17
pour afficher des informations détaillées sur chaque processus. La sortie de cette commande peut être longue. La sortie peut être recherchée à l’aide de Ctrl+F.Utilisez la
!process
commande pour répertorier les informations de processus pour les deux processus exécutant votre ordinateur. Indiquez l’adresse du processus à partir de votre!process 0 0
sortie, et non l’adresse indiquée dans cet exemple.Cet exemple de sortie concerne l’ID de processus cmd.exe enregistré précédemment. Le nom de l’image de cet ID de processus est cmd.exe.
0: kd> !process ffffe0007bbde900 PROCESS ffffe0007bbde900 SessionId: 1 Cid: 0f34 Peb: 7ff72dfa7000 ParentCid: 0c64 DirBase: 19c5fa000 ObjectTable: ffffc001d8c2f300 HandleCount: 31. Image: cmd.exe VadRoot ffffe0007bb8e7b0 Vads 25 Clone 0 Private 117. Modified 20. Locked 0. DeviceMap ffffc001d83c6e80 Token ffffc001d8c48050 ElapsedTime 21:33:05.840 UserTime 00:00:00.000 KernelTime 00:00:00.000 QuotaPoolUsage[PagedPool] 24656 QuotaPoolUsage[NonPagedPool] 3184 Working Set Sizes (now,min,max) (261, 50, 345) (1044KB, 200KB, 1380KB) PeakWorkingSetSize 616 VirtualSize 2097164 Mb PeakVirtualSize 2097165 Mb PageFaultCount 823 MemoryPriority FOREGROUND BasePriority 8 CommitCharge 381 THREAD ffffe0007cf34880 Cid 0f34.0f1c Teb: 00007ff72dfae000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable ffffe0008096c900 ProcessObject Not impersonating ...
Cet exemple de sortie concerne l’ID de processus echoapp.exe enregistré précédemment.
0: kd> !process ffffe0008096c900 PROCESS ffffe0008096c900 SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34 DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34. Image: echoapp.exe VadRoot ffffe000800cf920 Vads 30 Clone 0 Private 135. Modified 8. Locked 0. DeviceMap ffffc001d83c6e80 Token ffffc001cf5dc050 ElapsedTime 00:00:00.048 UserTime 00:00:00.000 KernelTime 00:00:00.000 QuotaPoolUsage[PagedPool] 33824 QuotaPoolUsage[NonPagedPool] 4464 Working Set Sizes (now,min,max) (681, 50, 345) (2724KB, 200KB, 1380KB) PeakWorkingSetSize 651 VirtualSize 16 Mb PeakVirtualSize 16 Mb PageFaultCount 686 MemoryPriority BACKGROUND BasePriority 8 CommitCharge 138 THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING on processor 0 IRP List: ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000 Not impersonating ...
Enregistrez ici la première adresse de thread associée aux deux processus.
Cmd.exe: ____________________________________________________
EchoApp.exe: _________________________________________________
Utilisez la
!Thread
commande pour afficher des informations sur le thread actuel.0: kd> !Thread THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING on processor 0 IRP List: ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000 Not impersonating DeviceMap ffffc001d83c6e80 Owning Process ffffe0008096c900 Image: echoapp.exe Attached Process N/A Image: N/A ...
Comme prévu, le thread actuel est le thread associé à echoapp.exe et il est dans un état d’exécution.
Utilisez la
!Thread
commande pour afficher des informations sur le thread associé à cmd.exe processus. Indiquez l’adresse du thread que vous avez enregistrée précédemment.0: kd> !Thread ffffe0007cf34880 THREAD ffffe0007cf34880 Cid 0f34.0f1c Teb: 00007ff72dfae000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable ffffe0008096c900 ProcessObject Not impersonating DeviceMap ffffc001d83c6e80 Owning Process ffffe0007bbde900 Image: cmd.exe Attached Process N/A Image: N/A Wait Start TickCount 4134621 Ticks: 0 Context Switch Count 4056 IdealProcessor: 0 UserTime 00:00:00.000 KernelTime 00:00:01.421 Win32 Start Address 0x00007ff72e9d6e20 Stack Init ffffd0015551dc90 Current ffffd0015551d760 Base ffffd0015551e000 Limit ffffd00155518000 Call 0 Priority 14 BasePriority 8 UnusualBoost 3 ForegroundBoost 2 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site ffffd001`5551d7a0 fffff801`eed184fe : fffff801`eef81180 ffffe000`7cf34880 00000000`fffffffe 00000000`fffffffe : nt!KiSwapContext+0x76 [d:\9142\minkernel\ntos\ke\amd64\ctxswap.asm @ 109] ffffd001`5551d8e0 fffff801`eed17f79 : ffff03a5`ca56a3c8 000000de`b6a6e990 000000de`b6a6e990 00007ff7`d00df000 : nt!KiSwapThread+0x14e [d:\9142\minkernel\ntos\ke\thredsup.c @ 6347] ffffd001`5551d980 fffff801`eecea340 : ffffd001`5551da18 00000000`00000000 00000000`00000000 00000000`00000388 : nt!KiCommitThreadWait+0x129 [d:\9142\minkernel\ntos\ke\waitsup.c @ 619] ...
Ce thread est associé à cmd.exe et est dans un état d’attente.
Fournissez l'adresse du fil d'attente CMD.exe pour changer le contexte vers ce fil en attente.
0: kd> .Thread ffffe0007cf34880 Implicit thread is now ffffe000`7cf34880
Utilisez la
k
commande pour afficher la pile des appels associée au thread en attente.0: kd> k *** Stack trace for last set context - .thread/.cxr resets it # Child-SP RetAddr Call Site 00 ffffd001`5551d7a0 fffff801`eed184fe nt!KiSwapContext+0x76 [d:\9142\minkernel\ntos\ke\amd64\ctxswap.asm @ 109] 01 ffffd001`5551d8e0 fffff801`eed17f79 nt!KiSwapThread+0x14e [d:\9142\minkernel\ntos\ke\thredsup.c @ 6347] 02 ffffd001`5551d980 fffff801`eecea340 nt!KiCommitThreadWait+0x129 [d:\9142\minkernel\ntos\ke\waitsup.c @ 619] 03 ffffd001`5551da00 fffff801`ef02e642 nt!KeWaitForSingleObject+0x2c0 [d:\9142\minkernel\ntos\ke\wait.c @ 683] ...
Les éléments de pile d’appels tels que
KiCommitThreadWait
indiquent que ce thread n'est pas en marche comme prévu.
Pour plus d’informations sur les threads et les processus, consultez les références suivantes :
IRQL, registres et terminer la session WinDbg
Dans cette section, affichez le niveau de demande d’interruption (IRQL) et le contenu des registres.
Afficher l'IRQL enregistré
Le niveau IRQL est utilisé pour gérer la priorité de la gestion des interruptions. Chaque processeur a un paramètre IRQL que les threads peuvent augmenter ou réduire. Les interruptions qui se produisent au niveau ou en dessous du paramètre IRQL du processeur sont masquées et n’interfèrent pas avec l’opération actuelle. Les interruptions qui se produisent au-dessus du paramètre IRQL du processeur sont prioritaires sur l’opération actuelle.
Sur le système hôte, l’extension !irql affiche l’IRQL sur le processeur actuel de l’ordinateur cible avant que l’arrêt du débogueur ne s’est produit. Lorsque l’ordinateur cible accède au débogueur, l'IRQL change, mais l'IRQL qui était en vigueur juste avant l’arrêt du débogueur est enregistré et s’affiche par !irql
.
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)
Afficher les registres
Sur le système hôte, affichez le contenu des registres pour le thread actif sur le processeur actuel à l’aide de la commande r (Registres).
0: kd> r
rax=000000000000c301 rbx=ffffe00173eed880 rcx=0000000000000001
rdx=000000d800000000 rsi=ffffe00173eed8e0 rdi=ffffe00173eed8f0
rip=fffff803bb757020 rsp=ffffd001f01f8988 rbp=ffffe00173f0b620
r8=000000000000003e r9=ffffe00167a4a000 r10=000000000000001e
r11=ffffd001f01f88f8 r12=0000000000000000 r13=ffffd001f01efdc0
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!DbgBreakPointWithStatus:
fffff803`bb757020 cc int 3
Vous pouvez également afficher le contenu des registres en sélectionnant Afficher>les registres. Pour plus d’informations, consultez r (Registres).
L’affichage du contenu des registres peut être utile lors de l’exécution de code du langage d’assembly et dans d’autres scénarios. Pour plus d’informations sur le désassemblage du langage assembleur, consultez Désassemblage x86 annoté et désassemblage x64 annoté.
Pour plus d’informations sur le contenu du registre, consultez l’architecture x86 et l’architecture x64.
Mettre fin à la session WinDbg
Si vous souhaitez laisser le débogueur attaché, mais que vous souhaitez travailler sur la cible, supprimez les points d’arrêt à l’aide de bc *
, afin que l’ordinateur cible n’essaie pas de se connecter au débogueur de l’ordinateur hôte. Utilisez ensuite la g
commande pour autoriser l’ordinateur cible à réexécuter.
Pour mettre fin à la session de débogage, sur le système hôte, faites un saut dans le débogueur et entrez la qd
commande (Quitter et détacher) ou sélectionnez Arrêter le débogage dans le menu.
0: kd> qd
Pour plus d’informations, consultez Terminer une session de débogage dans WinDbg.
Ressources de débogage Windows
Vous trouverez plus d’informations sur le débogage Windows. Certains de ces livres utilisent des versions antérieures de Windows comme Windows Vista dans leurs exemples, mais les concepts abordés s’appliquent à la plupart des versions de Windows.
Livres
- Débogage Windows avancé par Mario Hewardt et Daniel Pravat
- Débogage Windows de l'intérieur : Guide pratique pour le débogage et le suivi des méthodes dans Windows® par Tarik Soulami
- Windows Internals by Pavel Yosifovich, Alex Ionescu, Mark Russinovich et David Salomon
Vidéo
Fournisseurs de formation