Référence du code Live Dump du noyau
Cette section contient des descriptions des codes de dumps en direct courants du noyau qui peuvent se produire. Les dumps en direct ne réinitialisent pas le système d’exploitation, mais permettent de capturer des informations sur la mémoire pour des situations anormales où le système d’exploitation peut continuer à fonctionner.
Remarque
Cette rubrique s’adresse aux programmeurs. Si vous êtes un client dont le système a affiché un écran bleu avec un code de vérification de bogue, veuillez consulter la section Résolution des erreurs d’écran bleu.
Comparaison entre le dump en direct du noyau et la vérification de bogue
Avec une vérification de bogue traditionnelle, le PC se réinitialise et le travail de l’utilisateur est interrompu. L’objectif du dump en direct du noyau est de collecter des données pour résoudre une situation anormale, tout en permettant au système d’exploitation de continuer à fonctionner. Cela réduit les temps d’arrêt par rapport à une vérification de bogue pour des défaillances et blocages « non fatals » mais à fort impact. Les dumps en direct du noyau sont utilisés lorsqu’il est possible de récupérer le système d’exploitation à un état sain connu. Par exemple, une réinitialisation matérielle d’un sous-système, tel que la vidéo/l’affichage, l’USB3 ou le Wi-Fi, peut permettre à ces systèmes de revenir à un état sain connu, avec un impact minimal pour l’utilisateur.
Un dump en direct du noyau crée une capture cohérente de la mémoire du noyau et la sauvegarde dans un fichier de dump pour une analyse future. Pour minimiser l’impact sur les performances, des techniques de copie de mémoire sont utilisées pour créer le fichier de dump en un court laps de temps. De plus, la collecte des dumps en direct est limitée, afin que l’impact sur l’utilisateur soit minimisé.
Un dump en direct du noyau est efficace pour une catégorie de problèmes où quelque chose prend beaucoup de temps, sans pour autant que rien ne tombe techniquement en panne. Un temporisateur de surveillance peut être initialisé lorsqu’une opération est lancée. Si le temporisateur expire avant que l’opération ne soit terminée dans le délai prévu, un dump en direct du système peut être effectué. Le dump peut ensuite être analysé en parcourant la trace d’appels et la chaîne d’attente associée à cette opération pour comprendre pourquoi elle ne se termine pas dans le délai prévu.
Les journaux système fonctionnent bien lorsqu’une panne survient et que le propriétaire du code a enregistré la cause de la panne et peut l’identifier. Les dumps en direct qui utilisent des temporisateurs de surveillance tentent de capturer des chemins de défaillance qui n’étaient pas prévus et enregistrés. Mais comme pour toute défaillance, les journaux système peuvent identifier d’autres problèmes pouvant fournir des indices sur la cause racine spécifique de la panne.
Contenu des fichiers de dump en direct du noyau
Similaires aux fichiers de dump classiques, les fichiers de dump en direct peuvent contenir des mini-dumps (avec des données secondaires), et des dumps complets du noyau, qui peuvent également inclure la mémoire en mode utilisateur, similaires aux dumps actifs. Pour des informations générales sur le contenu des fichiers de dump, veuillez consulter la section Variétés de fichiers de dump en mode noyau. Certains dumps en direct ne tentent de capturer que des mini-dumps, car ils sont conçus pour capturer des données spécifiques liées au matériel, tandis que d’autres peuvent tenter de capturer un dump en direct du noyau plus grand.
Pour des raisons de performance, de taille de fichier et de fiabilité des captures de dump, certaines informations ne sont pas incluses, telles que les pages de la liste d’attente et les caches de fichiers.
Les fichiers de dump en direct contiennent généralement des pages mémoire telles que :
- KdDebuggerBlock
- Liste des modules chargés
Pour chaque processeur, les informations suivantes sont capturées dans les dumps du noyau :
- KiProcessorBlock
- PRCBs
- Pile active
- Tableau de répertoires de pages actuel
- KI_USER_SHARED_DATA
- Image du noyau NTOS
- Image HAL
Des informations supplémentaires dans les dumps du noyau peuvent inclure :
- État du thread / de la mémoire
- Journalisation en mémoire
Certains dumps en direct peuvent contenir des pages de processus en mode utilisateur.
Des données spécifiques à certains domaines, par exemple des données spécifiques à l’USB pour les pannes USB, peuvent être incluses dans certains dumps en direct.
Fichier de dump en direct partiel du noyau
Un fichier de dump en direct partiel du noyau peut être généré dans des situations où le dump en direct ne peut pas capturer de manière fiable toutes les pages de mémoire prévues. Les informations capturées dans un dump partiel sont filtrées et priorisées, en capturant les pages contenant les données importantes nécessaires pour générer un dump valide avant les autres pages. Par exemple, les pages du noyau sont priorisées par rapport aux pages utilisateur, lorsque le dump en direct inclut des pages utilisateur. Dans certaines situations, il n’y a pas suffisamment de ressources disponibles pour capturer toutes les pages de mémoire optionnelles prévues, de sorte que certaines mémoires peuvent manquer dans le fichier de dump. Le fichier de dump devrait toujours être reconnu par le débogueur WinDbg mais peut afficher des erreurs lors de la tentative de dump de la mémoire. Si le débogueur affiche une erreur lors de la tentative de dump de la mémoire à une adresse, vous pouvez utiliser l’extension !pte pour vérifier si le PTE pour une adresse est valide ou non. Cela peut aider à déterminer si l’adresse mémoire est réellement invalide, ou si la page est valide mais simplement non disponible dans le fichier de dump.
Analyse des fichiers de dump en direct
Lorsqu’un dump en direct se produit, le fichier de dump peut être analysé en utilisant les mêmes techniques que pour les autres fichiers de dump mémoire. Pour comprendre le contenu de la mémoire lors d’une panne, des connaissances en registres mémoire du processeur et en programmation en langage d’assemblage sont nécessaires.
Pour plus d’informations, consultez l’article suivant :
Utilisation de WinDbg pour afficher les informations de code d’arrêt des dumps en direct
Si un code de dump en direct spécifique n’apparaît pas dans cette rubrique, utilisez l’extension !analyze dans le débogueur Windows (WinDbg) avec la syntaxe suivante (en mode noyau), en remplaçant <code> par un code de dump en direct :
!analyze -show <code>
Entrer cette commande amène WinDbg à afficher des informations sur le code de dump en direct spécifié. Si votre base numérique par défaut (radix) n’est pas 16, préfixez <code> avec 0x.
Fournissez les paramètres du code de dump en direct à la commande !analyze pour afficher toutes les informations de paramètre disponibles. Par exemple, pour afficher des informations sur le Bug Check 0x144 BUGCODE_USB3_DRIVER, avec une valeur du paramètre 1 de 0x3003, utilisez !analyze -show 0x144 0x3003 comme indiqué ici.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
Pour télécharger WinDbg, veuillez consulter la section Outils de débogage pour Windows. Pour en savoir plus sur les outils de développement WinDbg, veuillez consulter la section Premiers pas avec le débogage Windows.
Emplacements des fichiers de dump en direct
Les dumps en direct sont par défaut stockés dans le répertoire « C:\WINDOWS\LiveKernelReports ».
Dumps complets : %systemroot%\LiveKernelReports\*.dmp
Minidumps : %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Une structure de répertoires est utilisée pour stocker les dumps en direct pour différents composants.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Clés de registre des dumps en direct
Pour plus d’informations sur les options de configuration des rapports de noyau en direct générés par le système, veuillez consulter la section Paramètres WER.
Utilisation de PowerShell pour déclencher manuellement un dump en direct
Ouvrez une invite PowerShell en tant qu’administrateur.
Obtenez le nom convivial du StorageSubsystem en utilisant la commande PowerShell Get-StorageSubSystem.
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Utilisez Get-StorageDiagnosticInfo pour générer un dump en direct pour le sous-système ci-dessus (ainsi que d’autres journaux de diagnostic). Pour plus d’informations, veuillez consulter la section Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- La sortie indiquera que les informations demandées sont en cours de génération.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- Le dump sera à l’intérieur de
[DestinationPath]\localhost.
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- L’utilisation du débogueur pour exécuter !analyze sur le fichier de dump indiquera qu’il s’agit d’un code de dump en direct de LIVE_SYSTEM_DUMP (161).
Codes de dump en direct du noyau
Le tableau suivant fournit des liens vers des codes de dumps en direct du noyau.
Ces codes d’arrêt peuvent être utilisés pour les vidages en direct ou pour vérifier l’appareil.
| Code | Nom |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |