symbole privé chargé mais aucun numéro de ligne affiché?

Question

J'utilise Windbg pour charger un vidage sur incident à partir du code managé (C#, une application console construite pour Any CPU), et un vidage sur incident est créé sur la plate-forme x64. Je débogue sur la plate-forme x64. J'ai besoin de la commande suivante pour charger le symbole privé de mon application:

Voici les commandes que j'utilise dans Windbg. Ma confusion est, lors de l'utilisation de la commande suivante, aucune information de numéro de ligne n'est montrée dans la trace de la pile. Des idées ce qui ne va pas? Ai-je besoin de définir le chemin source?

0:016> ~6 e!clrstack 

EDIT 1: J'ai rencontré quelques problèmes avec l'utilisation pe et U pour trouver trace de la pile où l'exception est levée!.

Voici mon processus de débogage. Au début, j'utilise! Pe pour imprimer la trace de pile pour l'objet exception, quand j'utilise! U pour diassembler le code. Le problème que je trouve est! U va diassembler tout le code de fonction de FooService.ProcessOrders(), et je veux trouver l'endroit exact où dans la fonction FooService.ProcessOrders l'accident se produit. Je trouve aussi que le code IL annoté ne contient que des appels de fonction que j'ai faits (pour le code C# non-fonction, par exemple a = a * 2, seul le langage assembleur est affiché), pas exactement IL mappé à chaque ligne de code C# 1) est-ce le bon comportement attendu? (2) Quelle est la solution ou une autre suggestion pour trouver le code C# exact de mon analyse posté ici?

!pe 0000064280155325 

StackTrace (generated): 
    SP    IP    Function 

    000000001A56DA70 00000642B74E3B7A System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(System.Data.Common.DbAsyncResult, System.String, Boolean) 
    000000001A56DB10 00000642B74E3FCC System.Data.SqlClient.SqlCommand.ExecuteNonQuery() 
    000000001A56DB90 0000064280155325 FooService.ProcessOrders() 
    000000001A56F3E0 0000064280153A21 FooService.RountineJob() 

!U 0000064280155325 

merci à l'avance, George

Answer 1

WinDbg/SOS ne correspond pas les numéros de ligne à la sortie de !clrstack. Donc, tant que lm vous indique que vous avez des symboles pdb privés pour vos propres assemblages, la configuration est correcte. Malheureusement, les versions actuelles de WinDbg/SOS ne prennent pas en charge le débogage au niveau de la source au même titre que le code natif.

EDIT: Concernant les exceptions. Quand vous faites un !pe, il vous dira la pile d'appels ainsi que les décalages dans les méthodes pertinentes. Si vous prenez l'adresse de la colonne IP de la sortie !pe et faites un !U sur cela, vous verrez le code JITTED pour la méthode pertinente. La colonne IP sera la dernière adresse du code qui a généré l'exception (vous devez donc faire un peu de calcul pour trouver la bonne instruction).

La sortie désassemblée est annotée avec des appels .NET, il n'est donc pas difficile de faire correspondre cela avec le code source ou le code source. Cela devrait vous aider à identifier exactement quelle instruction throw vous recherchez. Cela étant dit, vous allez rendre le débogage beaucoup plus facile si vous divisez les méthodes en plusieurs méthodes plus petites. Si vous faites cela, le nom de la méthode est généralement suffisant pour localiser l'emplacement de l'exception. Je réalise que ce n'est pas toujours une option, mais cela vaut la peine d'être considéré.