Анализируя аварийный дамп в windbg

Question

Я использую сторонний API с закрытым исходным кодом, который выдает исключение о том, что "все именованные каналы заняты".

Я бы хотел отладить это дальше (а не просто проходить), чтобы я мог на самом деле узнать, что происходит под одеялом.

Я сделал дамп этого процесса с помощью WinDbg. Какие команды мне теперь следует использовать для анализа этого дампа?

Спасибо

Answer 1

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

!analyze -v

Теперь вы можете загрузить контекстную запись исключения:

.ecxr

А теперь ... просто взгляните на стек, регистры, потоки, ...

kb     ;will show you the stack trace of the crash.
dv     ;local variables

В зависимости от подсказок, которые вы получаете, вы должны следовать в другом направлении. Если вам нужна быстрая ссылка на WinDbg, я бы порекомендовал вам эту ссылку .

Надеюсь, вам пригодятся некоторые из этих команд и информация.

Answer 2

В посмертной отладке с Windbg может быть полезно выполнить некоторые общие диагностические команды, прежде чем решить, куда копать глубже. Это должны быть ваши первые шаги:

.logopen <filename>    (See also .logappend)
.lastevent             See why the process halted and on what thread
u                      List disassembly near $eip on offending thread
~                      Status of all threads
Kb                     List callstack, including parameters
.logclose

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

Answer 3

Обычно это происходит, когда клиент вызывает CreateFile для существующего канала, и все существующие экземпляры канала заняты. На этом этапе CreateFile возвращает ошибку, и код ошибки ERROR_PIPE_BUSY. На этом этапе правильно вызывать WaitNamedPipe со значением времени ожидания, чтобы дождаться, когда экземпляр канала станет доступным.

Проблема обычно возникает, когда более одного клиента пытается подключиться к указанному каналу одновременно.

Answer 4

Это отличный ресурс для использования WinDbg для анализа сбоев, которые могут быть полезны: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

Статья предназначена для Windows 10, но содержит ссылки на аналогичную информацию для более ранних версий Windows.

Answer 5

Я предполагаю, что сторонний dll является нативным (в противном случае просто используйте Reflector)

Прежде чем использовать WinDbg для анализа дампа, попробуйте использовать Process-Monitor (SysInternals, freeware) для мониторинга активности вашего процесса. если это не удается из-за проблемы, связанной с файловой системой, вы можете точно увидеть, что вызвало проблему, и что именно она пыталась сделать, прежде чем потерпеть неудачу.

Если Process-Monitor недостаточно, вы можете попытаться отладить ваш процесс. но чтобы увидеть какую-то значимую информацию о сторонних dll, вам понадобятся ее pdb.

После установки правильных символов отладки вы можете просматривать стек вызовов с помощью команды k или одного из ее вариантов (опять же, я полагаю, вы говорите о собственном коде). если ваш процесс действительно дает сбой из-за этой dll, то проверьте параметры, которые вы передаете в его функцию, чтобы убедиться, что проблема не на вашей стороне. Я предполагаю, что дальше по стеку вызовов вы достигаете некоторого Win32 API - изучите параметры, которые передает функция dll, пытаясь увидеть, «пахнет» ли что-то. Если у вас есть закрытый символ dll, вы также можете проверить его локальные переменные (dv), которые могут дать вам больше информации.

Надеюсь, я дал вам хорошую отправную точку.