Интерпретация стеков в мини-дампах Windows

StackOverflow https://stackoverflow.com/questions/77887

Вопрос

Как человек, который только начинает постигать тонкости компьютерной отладки, я ни за что на свете не смогу понять, как прочитать текст стека дампа в Windbg.Я понятия не имею, с чего начать, как их интерпретировать и как к этому подступиться.Кто-нибудь может подсказать направление этой бедной душе?

ie (на самом деле, единственный дамп, который у меня есть под рукой)

>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

Я знаю, что проблема связана с драйвером дисплея Nvidia, но что я хочу знать, так это как на самом деле прочитать стек (например, что такое b69dd8f4?):-[

Это было полезно?

Решение

Во-первых, вам необходимо настроить соответствующие символы.Символы позволят вам сопоставить адреса памяти с именами функций.Чтобы сделать это, вам необходимо создать локальную папку на вашем компьютере, в которой вы будете хранить локальный кэш символов (например: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 ++) покажет вам класс, содержащий код
  • ФУНКЦИОНАЛЬНОЕ НАЗВАНИЕ:Метод, который был вызван.Если у вас есть правильные символы, вы также увидите параметры.

Вы также можете увидеть что-то вроде

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()

Из этого стека вызовов вы можете следовать, что "main" вызвал "method1", который затем вызвал "method2", и это не удалось.

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

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).Поскольку у вас нет соответствующих символов, вы не можете увидеть имя метода.Я сомневаюсь, что NVIDIA предлагает публичный доступ к своим символам, поэтому, полагаю, вы не сможете получить отсюда много информации.

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

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

На случай, если вы хотите узнать больше об отладке WinDbg, я рекомендую перейти по следующим ссылкам:

Другие советы

Действительно хороший учебник по интерпретации трассировки стека доступен здесь:

http://www.codeproject.com/KB/debug/cdbntsd2.aspx

Однако даже с таким руководством может быть очень сложно (или почти невозможно) интерпретировать дамп стека без доступных / загруженных соответствующих символов.

Возможно, будет полезно включить пример стека, который вы пытаетесь прочитать.Хороший совет - убедиться, что у вас есть правильные символы отладки для всех модулей, показанных в стеке.Сюда входят символы для модулей в операционной системе, Microsoft сделала свой сервер символов общедоступным.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top