Essayer d'analyser un fichier Dump avec WinDbg : PEB est en pagination, ne charge pas les symboles.

Question

Bonjour, j'essaie d'utiliser WinDbg pour regarder un fichier memory.dmp du noyau dans le but de diagnostiquer un crash. Lorsque j'ouvre le fichier de crash et que je récupère les symboles, j'obtiens le message suivant

BugCheck A, {2, ff, 4e, fffff801a42ebff2}

CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
Probably caused by : ntkrnlmp.exe ( nt!KxWaitForLockOwnerShipWithIrql+12 )

Followup:     MachineOwner
---------

0: kd> .reload
Loading Kernel Symbols
..................................CompressedPageDataReader warning: failed      to get _SM_PAGE_KEY symbol.

Loading User Symbols
PEB is paged out (Peb.Ldr = 000000e1`114f4018).  Type ".hh dbgerr001" for details

Je suppose que cela signifie qu'il ne peut pas charger certains des symboles. Lorsque j'essaie le processus !vad pour corriger l'erreur de la page PEB, j'obtiens les résultats suivants

0: kd> !vad 000000e1114f4018 1

VAD @ ffffca0f084164e0
Start VPN              e111400  End VPN          e1115ff  Control Area  0000000000000000
FirstProtoPte 0000000000000000  LastPte f943916c00000002  Commit Charge               21 (0n33)
Secured.Flink                0  Blink                  0  Banked/Extend                0
File Offset              50005  
  ViewUnmap NoChange PrivateMemory READWRITE  

ce qui ne correspond pas à ce que l'internet me dit que le résultat devrait être.

Lorsque j'essaie la méthode !process j'obtiens

0: kd> !process 000000e1114f4018 1
Searching for Process with Cid == e1114f4018
Invalid Handle: 0x114f4018
***Could not retrieve process handle from the Cid table.  Searching...

qui est également une erreur qui ne charge pas les symboles non plus. Quel est le problème ? Soit dans le chargement des symboles, soit dans le crash lui-même, s'il y a suffisamment d'informations.

NOTE : J'ai essayé les solutions de la page MSDN et elles ne fonctionnent pas comme indiqué. Une partie du problème est que je ne sais pas si j'utilise l'adresse 000000e1`114f4018 qui m'est donnée dans le message d'erreur PEB paged out correctement dans la commande.

NOTE 2 : Voici un lien vers le rapport de crash de WinDBG. Si quelqu'un peut trouver la cause et expliquer comment il l'a trouvée, ce serait formidable.

https://www.scribd.com/document/326672131/Crash-Archive

Answer 1

La sortie du PEB est normale. Pour que le PEB soit présent, le vidage doit être un vidage complet de la mémoire et les pages correspondantes doivent être résidentes au moment du crash.

Cela n'a généralement pas d'importance car le PEB contient l'état du mode utilisateur (modules chargés par l'utilisateur, ligne de commande, variables d'environnement, etc.) qui n'est généralement pas intéressant pour un crash en mode noyau.

Ce qui est intéressant, c'est la sortie de !analyze -v, y compris la pile en mode noyau du thread défectueux. D'après ce que vous avez fourni, nous pouvons au moins voir le code de panne :

BugCheck A, {2, ff, 4e, fffff801a42ebff2}

Le bugcheck A est un IRQL_NOT_LESS_OR_EQUAL, ce qui signifie que vous avez un déréférencement de pointeur invalide à un IRQL élevé (>= DISPATCH_LEVEL). Le premier argument est la mauvaise adresse ("2") et le second est l'IRQL ("0xFF" - en langage WinDbg, cela signifie "interruptions désactivées sur le processeur").

En résumé, cela signifie que quelqu'un a déréférencé l'adresse "2", ce qui n'est clairement pas une bonne chose. Cela s'est produit alors que les interruptions étaient désactivées sur le processeur, vous obtenez donc un IRQL_NOT_LESS_OR_EQUAL. L'astuce consiste alors à examiner la pile d'appel et l'instruction de défaut et à déterminer d'où vient le "2".