Getting additional call function information with debugdiag

Question

I'm using debugdiag 1.2 with a .dmp file. I've been working with Microsoft support and we get different function trace details - his version is a lot more verbose with function names and parameters.

I wondered if there was something I'm missing to get the same as him?

For example, I will get:

ntdll!NtWaitForMultipleObjects+a    
KERNELBASE!WaitForMultipleObjectsEx+e5    
clr!WaitForMultipleObjectsEx_SO_TOLERANT+62    
clr!Thread::DoAppropriateAptStateWait+53    
clr!Thread::DoAppropriateWaitWorker+186    
clr!Thread::DoAppropriateWait+7d    
clr!WaitHandleNative::CorWaitOneNative+151    
mscorlib_ni+509aa4    
0x000007fd`231e0e5c    
mscorlib_ni+4efd85    
mscorlib_ni+4efae9    
mscorlib_ni+4efaa7    
mscorlib_ni+d529ad

For same dump file, he will get:

ntdll!ZwWaitForMultipleObjects+a 
KERNELBASE!WaitForMultipleObjectsEx+e5 
clr!WaitForMultipleObjectsEx_SO_TOLERANT+62 
clr!Thread::DoAppropriateAptStateWait+53 
clr!Thread::DoAppropriateWaitWorker+186 
clr!Thread::DoAppropriateWait+7d 
clr!WaitHandleNative::CorWaitOneNative+151 
mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+14 
FiftyOne_Foundation!Unknown+3c 
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+285 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+9 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+57 
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart(System.Object)+5d

DebugDiag looks like a hugely useful tool - I'd dearly like to have a good understanding of it. Thanks in advance for your time.

score 1 · Answer 1 · answered Jan 24 '14 at 05:17

The difference is that Microsoft Support uses internal PRIVATE SYMBOLS and when you use Debug Diagnostic tool with PRIVATE symbols, the NATIVE stacks displayed in the report are much more accurate and better because the debugger (dbgeng.dll and dbghelp.dll to be specific) are able to figure out even the managed function names and they show those in the native stack as if they are native functions however if we use the PUBLIC symbols (from msdl.microsoft.com) to analyze the dumps, these function names won't show up in the debug diag report under the native stack section.

You should still be able to see the right function names under the MANAGED callstack of the thread in the report

I can also see that the CLR loaded in the dump is 4.0 or above so you will get better stacks in the report if you use Debug Diagnostic 2.0 as that was written specifically to target 4.0 and above framework runtimes. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=40336

Getting additional call function information with debugdiag

1 Answers1