Анализ катастрофического отказа выводит в windbg

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

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

Это отличный ресурс для использования WinDbg для анализа сбоев, которые могут быть полезны: http: //www.networkworld.

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

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

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

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

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

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

!analyze -v

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

.ecxr

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

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

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

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

При посмертной отладке с помощью 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

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