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