Comment voir les piles d'appels .NET?

J'ai un vidage de mémoire. Je peux obtenir la callstack normale (avec le numéro de ligne) Lorsque j'utilise Debug Diag pour analyser la décharge que je suis arrivé ce callstack le fil 62.Comment voir les piles d'appels .NET?

.NET Call Stack 

[[HelperMethodFrame_1OBJ] (System.Threading.WaitHandle.WaitOneNative)] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean) 
mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+21 
mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+31 
CaptureServices.GenericInfrastructure.ExportLogic.ChannelsThread.ChannelsStateThread()+bb 
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+15e 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+17 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+52 
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+52 
[[GCFrame]] 
[[DebuggerU2MCatchHandlerFrame]]

Comme je comprends .NET a un mécanisme de montre des noms lisibles par l'homme au lieu des adresses. Maintenant, je veux cette ligne dans WinDbg:

CaptureUtilities.AudioProcessing.APProcessorThread.IterateAPStreamProcessorQueue()+49

J'ouvre WinDbg et charge la décharge. J'exécute ~62 k et obtenir

Child-SP   RetAddr   Call Site 
00000016`4965e0c8 00007ffc`b59113ed ntdll!NtWaitForMultipleObjects+0xa 
00000016`4965e0d0 00007ffc`abde77be KERNELBASE!WaitForMultipleObjectsEx+0xe1 
00000016`4965e3b0 00007ffc`abde7658 clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x62 
00000016`4965e410 00007ffc`abde7451 clr!Thread::DoAppropriateWaitWorker+0x1e4 
00000016`4965e510 00007ffc`abdebd15 clr!Thread::DoAppropriateWait+0x7d 
00000016`4965e590 00007ffc`a94ecdf1 clr!WaitHandleNative::CorWaitOneNative+0x165 
00000016`4965e7c0 00007ffc`a94ecdc1 mscorlib_ni+0x48cdf1 
00000016`4965e7f0 00007ffc`4cf2e97b mscorlib_ni+0x48cdc1 
00000016`4965e830 00007ffc`a94e674e 0x00007ffc`4cf2e97b 
00000016`4965e890 00007ffc`a94e65e7 mscorlib_ni+0x48674e 
00000016`4965e960 00007ffc`a94e65a2 mscorlib_ni+0x4865e7 
00000016`4965e990 00007ffc`a94ed1f2 mscorlib_ni+0x4865a2 
00000016`4965e9e0 00007ffc`abc36a53 mscorlib_ni+0x48d1f2 
00000016`4965ea20 00007ffc`abc36913 clr!CallDescrWorkerInternal+0x83

Ok, si je comprends bien le même. Maintenant, nous avons

0x00007ffc`4cf2e97b

au lieu de

CaptureServices.GenericInfrastructure.ExportLogic.ChannelsThread.ChannelsStateThread()+bb

J'ai donc des symboles de débogage Microsoft, maintenant je dois charger mes propres symboles pour voir le callstack. La question est - ai-je besoin de charger tous les symboles de débogage pour mes projets ou j'ai besoin seulement des symboles de débogage pour dll qui contient CaptureServices.GenericInfrastructure.ExportLogic? Ou peut-être que je n'ai besoin de charger qu'une partie de mes symboles de débogage pour gérer ce thread?

Source

2017-03-14 Stepan Loginov

D'où avez-vous trouvé 'IterateAPStreamProcessorQueue'? Ce n'est pas dans la pile d'appels –

-1

Vous avez besoin des symboles de débogage de la bibliothèque à laquelle appartient cette fonction.

Source

2017-03-14 17:57:18 Blindy

Comme, je ne vois même pas la confusion, si vous voulez des données symboliques pour un exécutable, vous avez besoin de sa base de données de symboles (généralement .pdb sous Windows). Qu'est-ce qui vous lance ici? – Blindy

Peut-être un simple exemple montrera ma confusion. Permet à mon projet d'avoir 3 DLLs (A, D, C) Je sais que sur ce fil j'ai coincé dans le code de A. Ce code dans A appelé du code de B et C est autonome (ne fait pas partie de cette pile d'appels partie d'autres piles d'appels) De quelles DLL ai-je besoin pour voir les callstacks A, A + B, A + B + C? –

Saviez-vous que c'est pour .NET et non pour le code natif? Ce n'est pas aussi simple que de charger des fichiers PDB. WinDbg ne peut pas déboguer .NET seul. –

La commande k comme dans ~62k est une commande pour la pile d'appel natif. Il montre dot n'importe quel truc. NET (sauf les méthodes natives dans clr.dll).

Pour voir la pile .NET, vous devez charger l'extension .NET pour WinDbg:

.loadby sos clr

Et puis utiliser une commande de cette extension pour voir la pile d'appels .NET. Commutateur à visser 62 premier

~62s 
!clrstack 
!dumpstack

IMHO ces commandes se charge des symboles de PDBs en cas de besoin. Si vous obtenez des avertissements de symbole, voir How to fix symbols in WinDbg

Source

2017-03-15 17:00:59

Essayez !sosex.mk. Il fournit une trace de pile conviviale avec des images gérées et natives entrelacées. Je ne crois pas que ce soit un problème de symbole. En outre, lorsque vous avez une adresse gérée, vous pouvez la passer à !sosex.mln pour voir ce qui s'y trouve, mais je pense que vous connaissez déjà cette commande.

Source

2017-03-15 20:23:04

Comment voir les piles d'appels .NET?

Répondre

Questions connexes