Получение дополнительной информации о функции вызова с помощью debugdiag

Question

Я использую debugdiag 1.2 с файлом .dmp. Я работаю с поддержкой Microsoft, и мы получаем различные функции трассировки функции - его версия намного сложнее с именами функций и параметрами.

Я задавался вопросом, было ли что-то, что мне не хватает, чтобы получить то же самое, что и он?

Например, я получаю:

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 

Для того же файла дампа, то он получит:

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 выглядит как очень полезный инструмент - я бы очень хотел иметь хорошее понимание этого. Спасибо заранее за ваше время.

Answer 1

Разница заключается в том, что Microsoft Support использует внутренние PRIVATE СИМВОЛЫ и при использовании инструмента Debug Diagnostic с ЧАСТНЫХ символами нативной стеки, отображаемые в отчете, являются гораздо более точным и лучше, потому что отладчик (dbgeng.dll и dbghelp. dll, которые могут быть конкретными) могут определять даже имена управляемых функций, и они показывают те, которые находятся в собственном стеке, как если бы они были нативными функциями, однако, если мы используем PUBLIC-символы (с msdl.microsoft.com) для анализа дампов, эти имена функций не будут отображаться в отчете debug diag в разделе собственного стека.

Вы должны все еще быть в состоянии видеть правильные имена функций при управляемом стеке вызовов нити в отчете

Я также могу видеть, что CLR загружен в отвале 4.0 или выше, так что вы получите лучшие стеки в отчете, если вы используете Debug Diagnostic 2.0, поскольку это было написано специально для целевых версий 4.0 и выше. Вы можете скачать его с http://www.microsoft.com/en-us/download/details.aspx?id=40336