Получение дополнительной информации о функции вызова с помощью 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

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

Вы по-прежнему должны видеть правильные имена функций в стеке MANAGED потока в отчете.

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