Tous les paramètres VC++ recommandés pour une meilleure analyse PDB sur les versions de version

Question

Existe-t-il des paramètres VC++ que je devrais connaître pour générer de meilleurs fichiers PDB contenant plus d'informations ?

J'ai mis en place un système d'analyse de vidage sur incident basé sur le projet crashrpt.

De plus, mon serveur de build de production a le code source installé sur D:\, mais ma machine de développement a le code source sur C:\.J'ai entré le chemin source dans les paramètres VC++, mais lorsque vous parcourez la pile d'appels d'un crash, il ne passe pas automatiquement à mon code source.Je pense que si j'avais le code source de ma machine de développement sur D:\, cela fonctionnerait.

Answer 1

"Y a-t-il des paramètres VC++ que je devrais connaître"

Assurez-vous de désactiver l’omission du pointeur de trame.Le blog de Larry Osterman a les détails historiques à propos de fpo et des problèmes qu'il provoque avec le débogage.

Les symboles sont chargés avec succès.Il affiche la pile d'appels, mais un double-clic sur une entrée ne m'amène pas au code source.

Quelle version de VS utilisez-vous ?(Ou utilisez-vous Windbg ?) ...dans VS, il devrait certainement demander la source la première fois s'il ne trouve pas l'emplacement.Cependant, il conserve également une liste des sources « introuvables » afin de ne pas vous la demander à chaque fois.Parfois, la liste de choses à ne pas regarder est pénible...pour récupérer l'invite, vous devez accéder à l'explorateur de solutions/au nœud de solution/propriétés/propriétés de débogage et modifier la liste des fichiers dans le volet inférieur.

Enfin, vous utiliserez peut-être des « symboles dépouillés ».Il s'agit de fichiers PDB générés pour fournir des informations de débogage permettant de parcourir la pile d'appels au-delà de FPO, mais avec les emplacements sources supprimés (ainsi que d'autres données).Les symboles publics pour les composants du système d'exploitation Windows sont des pdbs supprimés.Pour votre propre code, ceux-ci causent simplement de la douleur et n'en valent pas la peine, sauf si vous fournissez vos pdbs à des externes.Comment auriez-vous un de ces horribles pdbs dépouillés ?Vous pourriez les avoir si vous utilisez "binplace" avec la commande -a.

Bonne chance!Une véritable histoire de mini-vidage est une aubaine pour le débogage de la production.

Answer 2

Si vous construisez directement à partir de votre système de gestion de code source, vous devez annoter vos fichiers PDB avec les origines des fichiers.Cela vous permet de récupérer automatiquement les fichiers sources exacts lors du débogage.(Il s'agit du même processus que celui utilisé pour récupérer le code source du framework .Net).

Voir http://msdn.microsoft.com/en-us/magazine/cc163563.aspx pour plus d'informations.Si vous utilisez Subversion comme SCM, vous pouvez consulter le projet SourceServerSharp.

Answer 3

Vous pouvez essayer d'utiliser MS-DOS subst commande pour attribuer votre répertoire de code source au D :conduire.

Answer 4

Voici la procédure que j'ai utilisée après des problèmes similaires aux vôtres :

a) J'ai copié sur le serveur de production tous les fichiers EXE et DLL qui ont été créés, chacun avec son PDB correspondant dans le même répertoire, j'ai démarré le système et j'ai attendu que le crash se produise.

b) Copié tous les fichiers EXE, DLL et PDB sur la machine de développement (dans un dossier temporaire) avec le minidump (dans le même dossier).J'ai utilisé Visual Studio pour charger le minidump à partir de ce dossier.

Puisque VS a trouvé les fichiers sources là où ils avaient été initialement compilés, il a toujours été capable de les identifier et de les charger correctement.Comme pour vous, dans la machine de production, le lecteur utilisé n'était pas C :, mais dans la machine de développement, il l'était.

Deux autres conseils :

• Une chose que je faisais souvent était de copier un EXE/DLL reconstruit et d'oublier de copier le nouveau PDB.Cela a ruiné le cycle de débogage, VS ne pourrait pas me montrer la pile d'appels.

• Parfois, je recevais une pile d'appels qui n'avait aucun sens dans VS.Après quelques maux de tête, j'ai découvert que Windbg me montrerait toujours la pile correcte, mais souvent VS ne le faisait pas.Je ne sais pas pourquoi.

Answer 5

Au cas où quelqu'un serait intéressé, un collègue m'a répondu à cette question par e-mail :

Artem a écrit :

Il y a un drapeau pour mini-dumpwriteump () qui peut faire de meilleurs vidages de crash qui permettront de voir un état complet du programme, avec toutes les variables globales, etc.Quant aux piles d'appels, je doute qu'ils puissent être meilleurs à cause des optimisations ...Sauf si vous désactivez (peut-être certaines) optimisations.

De plus, je pense que la désactivation des fonctions en ligne et l'optimisation des programmes entière vous aideront beaucoup.

En fait, il existe de nombreux types de vidage, vous pourriez peut-être en choisir un assez petit mais toujours plus d'informations http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Ces types ne vous aideront pas avec la pile d'appels, ils affectent uniquement la quantité de variables que vous pourrez voir.

J'ai remarqué que certains de ces types de vidage ne sont pas pris en charge dans dbghelp.dll version 5.1 que nous utilisons.Nous pourrions le mettre à jour dans la dernière version 6.9, je viens de vérifier les outils de débogage MSEA pour MS - le plus récent Dbghelp.dll est toujours correct pour redistribuer.

Answer 6

Visual Studio vous demande-t-il le chemin d’accès au fichier source ?Si ce n'est pas le cas, il ne pense pas avoir de symboles pour la pile d'appels.La définition du chemin source devrait fonctionner sans avoir à cartographier l'emplacement d'origine exact.

Vous pouvez savoir si les symboles sont chargés en consultant la fenêtre « modules » dans Visual Studio.

En supposant que vous construisez un PDB, je ne pense pas qu'il existe d'options permettant de contrôler directement la quantité d'informations dans le PDB.Vous pouvez modifier le type d'optimisations effectuées par le compilateur pour améliorer la débogabilité, mais cela coûtera en performances - comme le souligne votre collègue, la désactivation en ligne contribuera à rendre les choses plus évidentes dans le fichier de crash, mais coûtera cher au moment de l'exécution.

Selon la nature de votre application, je recommanderais de travailler avec des fichiers de vidage complet si vous le pouvez, ils sont plus gros, mais vous donnent toutes les informations sur le processus...et à quelle fréquence ça plante de toute façon :)

Answer 7

Visual Studio vous demande-t-il pour le chemin d'accès au fichier source?

Non.

Si ce n'est pas le cas, il ne pense pas qu'il ait des symboles pour le Callstack.La définition du chemin source doit fonctionner sans avoir à cartographier l'emplacement d'origine exact.

Les symboles sont chargés avec succès.Il affiche la pile d'appels, mais un double-clic sur une entrée ne m'amène pas au code source.Je peux bien sûr rechercher dans les fichiers la ligne en question, mais c'est un travail difficile :)