Windbg Minidump Tutorial - Configuration et lecture des fichiers Minidump

Ceci est un tutoriel sur la façon de mettre en place et de lire vos fichiers Minidump lorsque vous recevez un BSOD (écran bleu de la mort) dans les tentatives pour obtenir un aperçu supplémentaire quant à la cause du problème. La première chose est d'abord. Téléchargez les derniers outils de débogage à partir du site de Microsoft.

Ensuite, allez dans Démarrer / Démarrer recherche. Je tape

la commande cmd.

Puis accédez au répertoire:

C: Program Outils FilesDebugging pour Windows (x86)

en utilisant la commande:

cd c: programme filesdebugging outils pour les fenêtres (86)

Il est insensible à la casse lorsque vous utilisez la commande cd.

Puis tapez:
windbg.exe zc: windowsminidumpmini06190901.dmp c "! analysent v"

Votre fichier Minidump est situé dans C: WindowsMinidumpMini06200901.dmp. Ce sera sous la forme "MiniMMDDYY01.dmp".

Symboles du noyau ont tort. S'IL VOUS PLAÎT CORRECTIF SYMBOLES DE FAIRE L'ANALYSE

Si quelque part dans le résultat de l'analyse de vérification d'erreur que vous voyez une erreur comme:

Les symboles kernel sont FAUX. S'il vous plaît corriger les symboles pour faire l'analyse.

Ensuite, il est fort probable que vous utilisez des symboles précédents et incompatibles ou des fichiers corrompus ou vous n'avez pas les symboles propres à l'emplacement spécifié quand le programme a été Windbg essayer d'analyser le fichier minidump. Donc, ce que je n'ai été d'ouvrir le programme WinDBG situé dans C: Program Outils FilesDebugging pour Windows (x86) (sous Vista et je crois que c'est le même endroit pour XP).

RÉGLAGE DU CHEMIN DE FICHIER VIA LE SYMBOLE DE LIGNE DE COMMANDE WINDBG:

Il s'agit d'une étape importante pour s'assurer que votre fichier chemin de symbole est correctement réglé afin que vous ne obtenir les symboles du noyau sont FAUX erreur ou d'autres types d'erreurs. Réglez maintenant le chemin du fichier de symboles (fichier / chemin du fichier de symboles) à:

SRVe: symboles [chemin vers Microsoft symboles path]

Cependant, pour une raison quelconque, j'ai trouvé que, pour définir le chemin d'accès du fichier de symboles dans le "Fichier / File Path Symbole", vous ne pouvez pas changer directement avec le domaine de la "Chemin du fichier Fichier / Symbole". J'ai donc trouvé ce que vous devez le changer à travers la fenêtre de commande WinDbg en allant à:

"Affichage / Commande"

En bas de la fenêtre de commande à côté de la "kd>" invite tapez ceci dans:

. Sympath SRVe: symboles [chemin vers Microsoft symboles path].

La partie entre les deux astérisques () est l'endroit où les symboles de serveurs de Microsoft sera téléchargé. Il est assez volumineux (environ 22 Mo) alors assurez-vous que vous avez suffisamment d'espace disque.

MISE EN CHEMIN DE FICHIER DE SYMBOLES DANS LA VARIABLE ENVIRONNEMENT:

Alternativement, vous pouvez le mettre dans votre variable d'environnement soit dans votre système ou environnement variable utilisateur. Pour ce faire, cliquez sur la touche Windows + e. La touche Windows est la clé vers la droite de la touche GAUCHE CTRL du clavier. Cela permettra d'ouvrir l'Explorateur Windows.

Puis cliquer sur "Paramètres système avancés" en haut à gauche de la fenêtre. Cette étape s'applique à Vista. Pour les utilisateurs de XP, cliquez simplement sur l'onglet Avancé.

Puis cliquez sur le "variable d'environnement" situé en bas de la fenêtre.

Puis cliquez sur le bouton "Nouveau" sous Variables système. Encore une fois, vous pouvez créer l'environnement comme une variable d'environnement utilisateur à la place.

Dans le champ "Nom de la variable" type:
_NT_SYMBOL_PATH

Dans le champ "Valeur de la variable" type:
symsrvsymsrv.dlle: symboles [chemin vers Microsoft symboles path]

Si vous définissez le chemin du fichier symbole en tant que variable d'environnement système, je crois que vous pourriez avoir à redémarrer votre ordinateur pour qu'elle prenne effet.

SORTIE DE COMMANDE WINDBG

Donc, ce qui suit est la sortie de mon accident:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. Tous droits réservés.

Chargement du fichier de vidage [c: windowsminidumpmini06260901.dmp]
Mini fichier de vidage du noyau: Seuls les registres et trace de la pile sont disponibles

Chemin de recherche de symbole est: SRVe: symboles [chemin symboles Microsoft]
Chemin de recherche est exécutable:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) libre compatible x86
Produit: Winnt, suite: SingleUserTS TerminalServer personnels
Construit par: 6001.18226.x86fre.vistasp1_gdr.0903021506
Nom de la machine:
Base de noyau = 0x8201d000 PsLoadedModuleList = 0x82134c70
Durée de la session de débogage: Ven Juin 26 16:25:11.288 2009 (GMT7)
Système Uptime: 0 jours 21:39:36.148
Chargement Symboles noyau
.................................................. .............
.................................................. ..............
.................................................. .........
Chargement Symboles utilisateur
Chargement de la liste module non chargé
............................

Analyse Bugcheck

Utilisez-le! Analysent v pour obtenir des informations de débogage détaillées.

BugCheck A, {8cb5bcc0, 1b, 1, 820d0c1f}

Impossible de charger le SystemRootsystem32DRIVERSSymIMv.sys image, erreur Win32 0N2

AVERTISSEMENT: Impossible de vérifier horodatage pour SymIMv.sys

ERROR: Module de chargement terminé, mais les symboles ne pouvait pas être chargé pour SymIMv.sys
Impossible de charger le SystemRootsystem32DRIVERSNETw3v32.sys image, erreur Win32 0N2

AVERTISSEMENT: Impossible de vérifier horodatage pour NETw3v32.sys

ERROR: Module de chargement terminé, mais les symboles ne pouvait pas être chargé pour NETw3v32.sys
Traitement de commande initiale! Analysent v '
Probablement causée par: tdx.sys (tdx! TdxMessageTlRequestComplete +94)

Suivi: MachineOwner

0:! Kd> analyser les v

Analyse Bugcheck

IRQL_NOT_LESS_OR_EQUAL (a)
Une tentative a été faite pour accéder à un paginable (ou totalement invalide) adresse à un
interrompre niveau de la demande (IRQL) qui est trop élevé. Il s'agit généralement d'
causés par des conducteurs qui utilisent des adresses incorrectes.
Si un débogueur du noyau est disponible obtenir le trace de la pile.
Arguments:
Arg1: 8cb5bcc0, mémoire référencée
Arg2: 0000001b, IRQL
Arg3: 00000001, bitfield:

bit 0: valeur 0 = opération de lecture, 1 = opération d'écriture

bit 3: valeur 0 = pas exécuter une opération, 1 = exécuter une opération (uniquement sur les puces qui soutiennent ce niveau de l'état)
Arg4: 820d0c1f, adresse qui référencé la mémoire

Détails de débogage:

WRITE_ADDRESS: GetPointerFromAddress: incapable de lire 82154868
Impossible de lire la mémoire à MiSystemVaType 82134420

8cb5bcc0

CURRENT_IRQL: 1b

FAULTING_IP:
nt! KiUnwaitThread 19
820d0c1f 890A mov dword ptr [edx], ecx

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

Nom_processus: Système

TRAP_FRAME: 4526c4 (piège 0xffffffff4526c4.)
ErrCode = 00000002
eax = ebx = 00000000 85c5d4d8 ecx = 8cb5bcc0 edx = 8cb5bcc0 esi = 85c5d420 edi = ed9c7048
eip = esp = 452738 820d0c1f ebp = 45274c iopl = 0 nv up ei pl nz na pe nc
cs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00010206
! nt KiUnwaitThread 0 x19:
820d0c1f 890A mov dword ptr [edx], ecx ds: 0023:8 cb5bcc0 =????????
Réinitialisation portée par défaut

LAST_CONTROL_TRANSFER: de 820d0c1f à 82077d24

STACK_TEXT:
4526c4 820d0c1f badb0d00 8cb5bcc0 87952ed0 nt! KiTrap0E 0 x2ac
45274c 8205f486 00000002 85c5d420 ed9c7048 nt! KiUnwaitThread 0 x19
452770 8205f52a ed9c7048 ed9c7008 00000000 nt! KiInsertQueueApc 0 x2a0
452790 00000000 00000000 8205742b ed9c7048 nt! KeInsertQueueApc 0 X4b
4527c8 8f989cd0 e79e1e88 e79e1f70 00000000 nt! IopfCompleteRequest 0 x438
4527e0 8a869ce7 00000007 00000000 00000007 tdx! TdxMessageTlRequestComplete 0 x94
452804 8a869d33 e79e1f70 e79e1e88 00000000 tcpip! UdpEndSendMessages 0 xfa
45281c 8a560c7f e79e1e88 00000001 00000000 tcpip! UdpSendMessagesDatagramsComplete 0 x22
...

STACK_COMMAND: ko

FOLLOWUP_IP:
tdx! TdxMessageTlRequestComplete 94
8f989cd0 6804010000 104h-poussoirs

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: tdx TdxMessageTlRequestComplete 94

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: tdx

IMAGE_NAME: tdx.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 479190ee

FAILURE_BUCKET_ID: 0xA_tdx TdxMessageTlRequestComplete 94

BUCKET_ID: 0xA_tdx TdxMessageTlRequestComplete 94

Suivi: MachineOwner

Il ressemble à un tas de charabia hiéroglyphique. Cependant, si vous regardez attentivement, vous pouvez avoir un aperçu plus loin dans l'éventuel problème ou cause d'elle. Le système est nom_processus suggérant un processus système. Le MODULE_NAME est tdx.

SORTIE DE COMMANDE KD: lmvm TDX

Le tdx est cliquable pour moi qui exécute la commande:
kd> lmvm tdx

comme une commande kd. «LM» dans «lmvm" est le module chargé. Le "v" est verbeux. Le 'm' est une reconnaissance de motif. Depuis le manuel chm débogueur il le déclare comme suit:

Motif m
Spécifie un modèle que le nom du module doit correspondre. Pattern peut contenir une variété de caractères génériques et les prescripteurs. Pour plus d'informations sur la syntaxe de ces informations, consultez Syntaxe de chaîne de caractères génériques.

Vous pouvez trouver beaucoup d'informations dans le manuel chm lorsque vous téléchargez le windbg auprès de Microsoft. Il sera situé ici:
C: Program Outils FilesDebugging pour Windows (x86) Debugger.chm

La sortie de la commande ci-dessus est la suivante:
0: kd> lmvm tdx
commencer à la fin le nom du module
8f97f000 8f995000 tdx (pdb symboles) c: Program Outils FilesDebugging pour Windows (x86) symtdx.pdbCFB0726BF9864FDDA4B793D5E641E5531tdx.pdb

Chargé fichier image symbole: tdx.sys

Fichier mappé en mémoire l'image: c: Program Outils FilesDebugging pour Windows (x86) symtdx.sys479190EE16000tdx.sys

Chemin de l'image: SystemRootsystem32DRIVERStdx.sys

Nom de l'image: tdx.sys

Timestamp: Ven Jan 18 21:55:58 2008 (479190EE)

CheckSum: 0001391F

ImageSize: 00016000

Version du fichier: 6.0.6001.18000

Version du produit: 6.0.6001.18000

Les indicateurs de fichiers: 0 (Masque 3F)

Fichier OS: 40004 NT Win32

Type de fichier: 3.6 Pilote

Date du fichier: 00000000.00000000

Traductions: 0409.04b0

CompanyName: Microsoft Corporation

ProductName: Microsoft ® Windows ®

InternalName: tdx.sys

OriginalFilename: tdx.sys

ProductVersion: 6.0.6001.18000

FileVersion: 6.0.6001.18000 (longhorn_rtm.0801181840)

FileDescription: Pilote Traduction TDI

LegalCopyright: © Microsoft Corporation. Tous droits réservés.

Nous avons donc glaner un aperçu un peu plus. Qui prend le module et la cause possible du problème.

Je regarde le STACK_TEXT et il ya des références à tcpip et NETIO qui semble faire allusion à un problème de réseau. Alors j'ai googlé autres avec un problème BSOD et tdx.sys et il ya un correctif pour ce problème. Cependant, un grand mot d'avertissement, veuillez ne pas télécharger le correctif si ce problème particulier ne s'applique pas à vous. Microsoft suggère d'utiliser les procédures de mise à jour de Microsoft qui incluent tous les correctifs.

Pour obtenir le lien vers le correctif pour le problème du réseau Google "correctif Microsoft 934611".

Je n'ai pas télécharger ce correctif, mais a plutôt choisi de mettre à jour mon service pack. Actuellement, Vista est le Service Pack 2. Je n'avais que le Service Pack 1. Donc je vais voir si cela résout le problème.

Pour vérifier ce Service Pack que vous avez installé et quelle version bits (32 bits ou 64 bits), consulter:

"Démarrer / Ordinateur". Faites un clic droit "Poste de travail" puis cliquez sur "Propriétés". Vous verrez les informations du Service Pack sous la rubrique "Edition Windows". Sous la rubrique «Système» (environ à mi-chemin à travers la page), vous verrez "Type de système:" qui permet d'afficher si vous avez des versions 32 bits ou 64 bits installé.

Pour obtenir le Service Pack 2 pour Windows Vista Google "Microsoft Vista sp2"....