Windows/C++: Est-il possible de trouver la ligne de code où l'exception a été levée à avoir “l'Exception " Offset”
L'un de nos utilisateurs d'avoir une Exception sur notre produit de démarrage.
Elle nous a envoyé le message d'erreur suivantes de Windows:
Problem Event Name: APPCRASH
Application Name: program.exe
Application Version: 1.0.0.1
Application Timestamp: 4ba62004
Fault Module Name: agcutils.dll
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 48dbd973
Exception Code: c0000005
Exception Offset: 000038d7
OS Version: 6.0.6002.2.2.0.768.2
Locale ID: 1033
Additional Information 1: 381d
Additional Information 2: fdf78cd6110fd6ff90e9fff3d6ab377d
Additional Information 3: b2df
Additional Information 4: a3da65b92a4f9b2faa205d199b0aa9efEst-il possible de localiser l'endroit exact dans le code source où l'exception s'est produite d'avoir cette information?
Qu'est-ce que la technique courante pour les programmeurs en C++ sur Windows pour localiser le lieu d'une erreur qui s'est produite sur l'ordinateur de l'utilisateur?
Notre projet est compilé avec la Version de configuration, fichier PDB est généré.
J'espère que ma question n'est pas trop naïf.
Vous devez vous connecter pour publier un commentaire.
Oui, c'est possible. Démarrer le débogage avec exactement les mêmes fichiers binaires comme dirigé par votre utilisateur, assurez-vous que la DLL est chargée et que vous avez une correspondance de fichier PDB pour elle. Regarder en Debug + Windows + Modules de la DLL à l'adresse de base. Ajouter le décalage. Debug + Windows + Démontage et entrer dans le calcul de l'adresse dans le champ Adresse (préfixe 0x). Qui vous montre exactement machine code d'instruction qui a provoqué l'exception. Droit-cliquez sur + Aller À code Source pour voir la correspondance de ligne du code source.
Pendant que vous montre l'état, ce n'est généralement pas assez bon pour diagnostiquer la cause. L'exception 0xc0000005 est une violation d'accès, il a de nombreuses causes possibles. Souvent, vous n'avez même pas le code, le programme a peut-être sauté dans l'oubli en raison d'une corruption de la pile. Ou le vrai problème se trouve loin, certains pointeur de la manipulation qui a corrompu le tas. Vous avez aussi généralement vraiment besoin d'une trace de pile qui vous montre comment le programme a pris fin, jusqu'à la déclaration qui a bombardé.
Ce que vous avez besoin est un minidump. Vous pouvez facilement obtenir un à partir de votre utilisateur si elle s'exécute Vista ou Win7. Démarrer TaskMgr.exe onglet Processus, sélectionnez le bombardement de programme pendant qu'il est encore l'affichage de l'accident de dialogue. Cliquez-droit et de Créer un Fichier de Vidage.
À faire ce bon, vous voulez vraiment pour automatiser cette procédure. Vous trouverez des conseils dans ma réponse dans ce fil.
ildasmtel que décrit ici (tout fichier Pdb est dans le même répertoire)Si vous avez un minidump, l'ouvrir dans Visual Studio, ensemble MODPATH pour les dossiers appropriés avec l'original binaires et Pdb, et dites à "exécuter". Vous pouvez aussi avoir besoin de lui dire de charger des symboles à partir de la Microsoft serveurs de symboles. Il affiche la pile d'appel à l'emplacement de l'erreur. Si vous essayez de regarder le code source pour un emplacement de pile, il peut vous demander quand la source est; si oui, sélectionnez le dossier source. MODPATH est situé dans le debug propriétés de ligne de commande pour le "projet" qui a le nom du fichier minidump.
Je sais que ce fil est très vieux, mais c'était l'un des meilleurs Google de réponse, donc j'ai voulu ajouter mon $.02.
Bien qu'un mini-dump est la plus utile, aussi longtemps que vous avez compilé votre code avec des symboles activé (suffit d'envoyer le fichier sans le .apb, et garder le .apb!) vous pouvez regarder ce ligne ce fut à l'aide de la MSVC Débogueur ou le Débogueur Windows. MSN article sur:
http://blogs.msdn.com/b/danielvl/archive/2010/03/03/getting-the-line-number-for-a-faulting-application-error.aspx
windbg -z <executable>tout-zne doit être utilisé que pour les décharges. Inutile de lien.Code Source de l'information n'est pas conservé dans compilé en code C++, contrairement à l'exécution des métadonnées-connaissance des langues (comme l' .NET ou Java). Le fichier PDB est un symbole de l'index qui peuvent aider un débogueur carte code compilé en arrière à la source, mais il doit être fait pendant l'exécution du programme, et non pas à partir d'un fichier de vidage sur incident. Même avec un PDB, Relâchez-le code compilé est soumis à un certain nombre d'optimisations qui peuvent empêcher le débogueur de l'identification de la source code.
Le débogage des problèmes qui manifeste seulement sur les machines des utilisateurs est généralement une question d'attention à l'état de la journalisation et de beaucoup de détails de temps et d'efforts peignage sur la source. En fonction de votre relation avec l'utilisateur (par exemple, si vous êtes à l'intérieur de l'entreprise de développement informatique), vous pourriez être en mesure de faire une image de machine virtuelle de la machine de l'utilisateur et de l'utiliser à des fins de débogage, ce qui peut aider à accélérer le processus extrêmement précisément par la réplication du logiciel installé et de la norme de processus en cours d'exécution sur le poste de travail utilisateur.