Анализ аварийного сброса в windbg

Question

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

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

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

Благодаря

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

В отладке postmortem с помощью 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 5

Вы могли бы начать делать так, чтобы получить обзор, за исключением:

!analyze -v 

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

.ecxr 

А теперь ... просто посмотрите в стопке, регистры, потоки, ...

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

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

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