Analyse des fichiers .dmp

Question

J'essaie de résoudre un problème d'erreur d'exécution C++ exe qui se produit uniquement en production. Je suis nouveau en C++ et Windbg mais je colle l'analyse ici. J'apprécierais grandement si quelqu'un peut me montrer comment et dans quelles conditions cette erreur se produit et, plus important encore, comment puis-je savoir quelle ligne de code est à l'origine. Je lis beaucoup de forums MAIS Si j'ouvre le fichier dmp dans VS 2008, j'ai un fichier pdb localement et l'exe localement MAIS je ne peux jamais obtenir l'option de menu Aller au code source activée. Réponse rapide quant à la façon d'analyser ce fichier .dmp et comment le comprendre, serait très appréciée .. Merci!

---

• *
• Exception Analyse *
• *

  ---

GetPageUrlData a échoué, serveur a renvoyé l'état HTTP 404 URL demandé: http://watson.microsoft.com/StageOne/MYServer_exe/0_0_0_0/MyServer_exe/0_0_0_0/000194ab.htm?Retriage=1

FA ULTING_IP: Myserver + 194ab 004194ab c6040100 mov byte ptr [ecx + EAX], 0

EXCEPTION_RECORD: FFFFFFFF - (.exr 0xffffffffffffffff) ExceptionAddress: 004194ab (Myserver + 0x000194ab) ExceptionCode: c0000005 (violation d'accès) ExceptionFlags: 00000000 NumberParameters: 2 paramètres [0]: 00000001 Paramètre [1]: 00000000 Tentative d'écriture à l'adresse 00000000

DEFAULT_BUCKET_ID: NULL_POINTER_WRITE

PROCESS_NAME: Myserver.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - L'instruction à 0x% 08lx a référencé la mémoire à 0x% 08lx. La mémoire ne peut pas être% s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - L'instruction à 0x% 08lx a référencé la mémoire à 0x% 08lx. La mémoire ne peut pas être% s.

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000000

WRITE_ADDRESS: 00000000

FOLLOWUP_IP: MYSERVER + 194ab 004194ab c6040100 mov byte ptr [ecx + eax], 0

MOD_LIST:

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

FAULTING_THREAD: 000004e0

PRIMARY_PROBLEM_CLASS: NULL_POINTER_WRITE

BUGCHECK_STR: APPLICATION_FAULT_NULL_POINTER_WRITE

LAST_CONTROL_TRANSFER: de 00418a4e à 004194ab

STACK_TEXT: AVERTISSEMENT: Stack détendre informations pas disponible le. Les images suivantes peuvent être erronées. 087ffa74 00418a4e 0a73b070 087ffc6c 087ffd8c Myserver + 0x194ab 087ffb64 00410767 0a73b070 087ffd74 087ffd8c Myserver + 0x18a4e 087ffc6c 0041089b 0a73b0f8 0a727a78 0a73b108 Myserver + 0x10767 087ffd74 00433913 0a73b0f8 0a727a78 0a73b108 Myserver + 0x1089b 087ffe58 0042fbf3 0a73b0f8 0a727a78 00000044 Myserver + 0x33913 087fffb8 7d4dfe37 000006a0 00000000 00000000 Myserver + 0x2fbf3 087fffec 00000000 0042fae0 000006a0 00000000 kernel32 BaseThreadStart + 0x34

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Myserver + 194ab

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Myserver

IMAGE_NAME: MyServer.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4c2123df

STACK_COMMAND: ~ 86s; .ecxr; kb

FAILURE_BUCKET_ID: NULL_POINTER_WRITE_c0000005_Myserver.exe Unknown

BUCKET_ID: APPLICATION_FAULT_NULL_POINTER_WRITE_Myserver + 194ab

Followup: MachineOwner

Answer 1

k vous donnera la trace de la pile du courant arrêté en fil.
~*kb vous donnera la trace de la pile de tous les fils

Symboles

pourraient vous intéresser pour définir le chemin de recherche de symbole pour inclure des symboles MS, ce qui permettra une meilleure trace de la pile.

Vous pouvez le faire à chaque fois en utilisant .sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols ou plusieurs réglage fixe _NT_SYMBOL_PATH environnement var (par exemple en tant que variable système) à srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

Vous devrez peut-être obtenir les symboles de re charge à l'aide ce qui suit.

.symfix+ c:\symbols 
.reload /f 

ligne Crash

EXCEPTION_RECORD: FFFFFFFF - (.exr 0xffffffffffffffff) ExceptionAddress: 004194ab FAULTING_IP: Myserver + 194ab 004194ab c6040100 mov byte ptr [eax ecx +], 0

Si tout ce que vous voulez est la ligne de l'accident, il ya une application 'CrashFinder' qui va charger votre application et pdb et vous permettre d'entrer 004194ab pour signaler la ligne de l'accident.

Answer 2

Vous pouvez également définir le chemin du symbole, où vous avez vos PDB d'application, et le chemin source, où vous avez vos sources, en utilisant le menu supérieur (Définir le chemin du symbole et Définir le chemin source).

Pour un vidage sur incident, une fois que vous avez mis en place des symboles et chemins source, et chargé le fichier de vidage, vous trouverez utile la commande: !analyze -v

et du rapport que vous avez collé, vérifiez la ligne: STACK_COMMAND: ~86s; .ecxr ; kb Cette ligne vous indique le fil qui a causé le défaut (86). Juste après cette ligne dans la fenêtre de commande pour obtenir la pile pour ce thread: ~86s; .ecxr ; kb

Answer 3

Si vous êtes plus à l'aise avec VS, n'abandonnez pas encore. Vous faire voir le démontage et la pile, et ne manquent que des symboles? Cliquez-vous sur le cadre de la pile qui est votre module et ne voyez toujours pas de code? Pouvez-vous même voir un cadre de pile qui se trouve dans votre module? Avez-vous établi l'accès aux symboles publics MS? (vous devriez probablement de toute façon, même avec WinDbg). WinDbg signale-t-il les symboles de la pile? (Ils ne sont pas répertoriés dans l'extrait que vous avez collé ici). Si ce n'est pas le cas, cela risque fort d'être un problème de symbole. Il existe des moyens de diagnostiquer ces deux sur WinDbg et VS. Avez-vous inspecté les «informations de chargement de symbole» pour les modules que vous souhaitez déboguer? (le plus simple dans VS est un clic droit sur le module dans la fenêtre des modules).

Des conseils doivent être donnés en fonction de toute combinaison de réponses à ces questions. Si vous fournissez plus de détails, cela peut aider à focaliser le conseil.