Интерпретация стеков в Windows Minidumps

Во-первых, необходимо было настроить надлежащие символы. Символы позволят Вам соответствовать адресам памяти к именам функций. Чтобы сделать это, необходимо создать локальную папку в машине, в которой Вы сохраните локальный кэш символов (например: C:\symbols). Затем необходимо указать путь сервера символов. Чтобы сделать это просто переходит в: Файл> Путь Файла символов и тип:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Можно найти больше информации о том, как правильно настроить символы здесь.

После того как Вы правильно настроили сервер Символов, можно открыть мини-дамп от: Файл> Открытый Дамп Катастрофического отказа.

После того как мини-дамп открыт, он покажет Вам на левой стороне командной строки поток, который выполнялся, когда дамп был сгенерирован. Если Вы хотите видеть то, что этот поток выполнял тип:

kpn 200

Это могло бы занять некоторое время первое, Вы выполняете его, так как оно должно загрузить необходимые общедоступные связанные с Microsoft символы в первый раз. После того как все символы загружаются, Вы получите что-то как:

01 MODULE!CLASS.FUNCTIONNAME1(...)
02 MODULE!CLASS.FUNCTIONNAME2(...)
03 MODULE!CLASS.FUNCTIONNAME3(...)
04 MODULE!CLASS.FUNCTIONNAME4(...)

Где:

• ПЕРВОЕ ЧИСЛО: Указывает на число кадра
• МОДУЛЬ: DLL, который содержит код
• КЛАСС: (Только на коде C++), покажет Вам класс, который содержит код
• FUNCTIONAME: метод, который назвали. Если у Вас будут корректные символы, то Вы будете также видеть параметры.

Вы могли бы также видеть что-то как

01 MODULE!+989823

Это указывает, что у Вас нет надлежащего Символа для этого DLL, и поэтому Вы только можете видеть смещение метода.

Так, что такое стек вызовов?

Предположите, что у Вас есть этот код:

void main()
{
  method1();
}

void method1()
{
  method2();
}

int method2()
{
  return 20/0;
}

В этом коде method2 в основном выдаст Исключение, так как мы пытаемся разделиться на 0, и это заставит процесс отказывать. Если бы мы получили мини-дамп, когда это произошло, мы видели бы следующий стек вызовов:

01 MYDLL!method2()
02 MYDLL!method1()
03 MYDLL!main()

Можно следовать из этого стека вызовов, что "основной" названный "method1", который затем названный "method2" и он привел к сбою.

В Вашем случае у Вас есть этот стек вызовов (который я предполагаю, результат рабочей команды "Кбита"),

b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94
b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255
b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0
b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

Первый столбец указывает на Дочерний Указатель Кадра, второй столбец указывает на Обратный адрес метода, который выполняется, следующие три столбца показывают первые 3 параметра, которые были переданы методу, и последняя часть является именем DLL (nv4_disp) и смещение метода, который выполняется (+0x48b94). Так как у Вас нет символов, Вы не можете видеть имя метода. Я сомневаюсь, что tha NVIDIA предлагает открытый доступ их символам, таким образом, я предполагаю, что Вы не можете получить много информации отсюда.

Я рекомендую выполнить "kpn 200". Это покажет Вам полный стек вызовов, и Вы смогли видеть источник метода, который вызвал этот катастрофический отказ (если бы это была Microsoft DLL, то у Вас должны быть надлежащие символы на шагах, которые я предоставил Вам).

По крайней мере, Вы знаете, что это связано с ошибкой NVIDIA ;-) Попытайтесь обновить DLLs этого драйвера к последней версии.

В случае, если Вы хотите узнать больше о WinDBG, отлаживающем, я рекомендую следующие ссылки:

• Если повреждено это, зафиксируйте его, Вы должны
• Вебкаст TechNet: Windows подвешивает и разрушает анализ дампа
• Delicious.com популярные ссылки на WinDBG