2

I got a memory dump. I can get the normal callstack (with line number) When I use Debug Diag to analyze the dump I got this callstack on thread 62.

.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]]

As I understand .NET has some mechanism to shows human readable names instead of adresses. Now I want this line in WinDbg:

CaptureUtilities.AudioProcessing.APProcessorThread.IterateAPStreamProcessorQueue()+49

I open WinDbg and load the dump. I execute ~62 k and get

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, as I understand it is the same. Now we have 

0x00007ffc`4cf2e97b

instead of

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

So I have Microsoft debug symbols, now I need to load my own symbols to see the callstack. The question is - do I need to load all debug symbols for my projects or I need only debug symbols for dll which contains CaptureServices.GenericInfrastructure.ExportLogic? Or maybe I need to load only part of my debug symbols to handle this thread?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
Stepan Loginov
  • 1,667
  • 4
  • 22
  • 49

3 Answers3

1

Try !sosex.mk. It gives a user-friendly stack trace with interleaved managed and native frames. I do not believe that this is a symbol issue. Also, when you have a managed address, you can pass it to !sosex.mln to see what's located there, but I think you're already aware of this command.

Steve Johnson
  • 2,958
  • 13
  • 15
0

The k command as in ~62k is a command for the native call stack. It does dot show any .NET stuff (except the native methods in clr.dll).

To see the .NET stack, you need to load the .NET extension for WinDbg:

.loadby sos clr

And then use a command of that extension to see the .NET call stack. Switch to thread 62 first

~62s
!clrstack
!dumpstack

IMHO those commands will load symbols from PDBs when needed. If you get symbol warnings, see How to fix symbols in WinDbg

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
-1

You need the debug symbols of whatever library that function belongs to.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • Like, I don't even see the confusion, if you want symbolic data for an executable you need its symbol database (usually .pdb in Windows). What is throwing you for a loop here? – Blindy Mar 14 '17 at 17:58
  • Maybe simple example will show my confusion. Lets my project have 3 DLLs (A, D, C) I know that on this thread I stuck in code of A. This code in A called from code of B and C is stand alone (not part of this call stack but part of other call stacks) Which DLLs I need to see the callstack A, A+B, A+B+C? – Stepan Loginov Mar 14 '17 at 20:11
  • Did you realize that this is for .NET and not for native code? It's not as simple as loading PDB files. WinDbg cannot debug .NET on its own. – Thomas Weller Mar 15 '17 at 17:02
  • 1
    @Thomas, what WinDbg can or cannot do is irrelevant, debug symbols are universal in Windows. If WinDbg can't handle JIT'd code, simply use a better debugger. But by all means, downvote a correct answer. Edit: You're also dead wrong, WinDbg can most certainly handle managed call stacks. – Blindy Mar 16 '17 at 14:51
  • 1
    @StepanLoginov, if I'm understanding you correctly, you want to see the call stack in A.dll? Then you need the debug symbols for A.dll (A.pdb, you'll find them in your Debug/Release folders). – Blindy Mar 16 '17 at 14:53
  • As the top #1 Windbg answerer on SO, I doubt I'm wrong, but I'm glad I could learn something new, so if you find out how to show the .NET call stack without an extra extension, I'm willing to spend a +300 bounty. – Thomas Weller Mar 16 '17 at 18:56
  • A quick Google search shows this link: https://blogs.msdn.microsoft.com/alejacma/2009/07/24/managed-debugging-with-windbg-call-stacks-part-1/ -- you can see it's Microsoft's own link from MSDN, from 6 years ago. I don't know about extensions or not, but I don't see an issue with using them if required. – Blindy Mar 20 '17 at 14:37