Бесплатный Debug Diagnostic Tool.

Всем привет.

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

При отладке или инсталяции приложений когда возникают сбои и снижается скорость выполнения, происходят отказы, зависание и утечка памяти - обычно требуется исследовать процессы, выполнявшиеся в момент возникновения сбоя. Задача осложняется тем, что многие серверные приложения, такие как Microsoft IIS, Exchange Server, SQL Server,  часто не имеют пользовательского интерфейса и автоматически перезагружаются без указания причин сбоя. Наличие под рукой удобного инструмента для отладки, который бы находил причину сбоя, при этом очень желательно.

Для таких целей Debug Diagnostic Tool (DebugDiag) в большинстве случаев подходит идеально. Почему же DebugDiag?

Чтобы ответить на этот вопрос, давайте сначала спросим себя, почему процесс может дать сбой. Сбой - это неожиданное прекращение работы программы в случае, когда процесс завершается аномально. Обычно сбой бывает вызван необрабатываемым исключением; но происходит это и в том случае, когда процесс обнаруживает проблемную ситуацию и завершается без обработки исключения (например, процесс зацикливается, вызывая чрезмерное использование памяти).

Часто в такой ситуации процесс или служба запускаются повторно (это можно настроить) в надежде, что сбой больше не повторится. Однако, чтобы действительно понять причину, которая вызвала сбой, и устранить ее, необходимо выполнить анализ состояния процессов в момент сбоя. Локализовать это состояние можно, создавая пользовательский файл дампа. Эти файлы генерируются любыми отладчиками Windows, они имеют расширения .dmp, .hdmp или .mdmp. Основные отладчики Windows для процессов — это WinDbg, Cdb и ntsd, их пользовательские дампы для анализа могут содержать ключи к разгадке причин сбоя. Точный анализ файла дампа для процесса может потребовать просмотра экспертом. И вот тут понадобится DebugDiag, который заметно упрощает анализ процесса поиска ошибок.

Инструмент DebugDiag комбинирует многие основные функции каждого отладчика из набора Windows Debugging Tools (ADPlus, Userdump и WinDbg), кроме того, он снабжен прекрасным пользовательским интерфейсом, что облегчает его применение. Самую последнюю версию DebugDiag (на сегодня v2 Update2) можно загрузить по этому адресу. DebugDiag устанавливается как служба, поэтому установленные в нем настройки будут сохраняться после перезагрузки системы. Инструмент выполняет свою работу быстро, его легко применять, он доступен бесплатно. Он позволяет быстро отправить информацию производителям для доработки и выявления ошибок. DebugDiag требует менее 19 Mбайт памяти на диске и работает на Windows XP, Windows Server 2003 и выше.

DebugDiag в действии.

После установки и запуска DebugDiag сразу возникает диалоговое окно мастера Select Rule Type, в котором можно выбрать нужное правило. Это правило зависит от того, что надо проверить. В моем случае целью были сбои в процессе инсталяции антивирусного пакета, поэтому следовало выбрать тип правила Crash (сбой) в диалоговом окне Select Rule Type, потом нажать кнопку Next. Далее выбираем тип процесса для отслеживания в диалоговом окне Select Target Type, например отдельная служба NT, какой-то конкретный процесс (прикладной процесс или все процессы IIS/COM+). Для данного случая я выбрал мониторинг процесса EFAInst так как именно в нем возникала exception.

В следующем окне мастера Advanced Configuration (Optional) настраиваем необязательные расширенные настройки для мониторинга сбоя. В нашем случае мы просто выбрали вариант по умолчанию и нажали Next. Затем появляется диалоговое окно для ввода имени правила и пути, где будет храниться информация пользовательского дампа; нажимаем Next, чтобы сохранить параметры по умолчанию или вносим изменения, например меняем каталог по умолчанию для хранения файлов дампа.

В последнем диалоговом окне можно активировать правило сразу или позднее вручную. Затем нажимаем Finish. Замечу, что можно выбрать параметр activate later, если не планируется проводить мониторинг сейчас, на случай завершения настройки в дальнейшем.

 

Теперь появляется главное окно приложения DebugDiag с тремя вкладками. Выбираем вкладку Rules, чтобы увидеть настроенные правила для этой системы, имя правила, состояние правила (активное или нет) и счетчик пользовательского дампа Userdump Count. Параметр Userdump Count — это число сбоев в проверяемом процессе, которые DebugDiag обрабатывает и сохраняет информацию по адресу в столбце Userdump Path. На вкладке Processes показаны запущенные в данный момент на системе процессы.

Анализ информации. 

После настройки DebugDiag с целью мониторинга отдельного процесса можно перезагрузить систему и выйти из сеанса, не заботясь о нарушении процесса мониторинга. Если есть подозрение, что отслеживаемый процесс дал сбой, можно проверить окно приложения DebugDiag и просмотреть столбец Userdump Count, чтобы убедиться, что пользовательский файл дампа создан.

На снимке показана вкладка Advanced Analysis, в которой надо выбрать сценарий работы для анализа информации пользовательского дампа для процесса мониторинга.

 

Внимание - вкладка Advanced Analysis оказалась доступной только  в версии 1.2 инструмента DebugDiag. Версию 1.2 пока еще можно скачать с сайта Microsoft.

Выбор сценария для анализа информации в пользовательском дампе.

Здесь выбран сценарий Crash/Hang Analyzers (анализаторы сбоя/зависания), так как требуется анализировать сбой процесса. Затем следует добавить анализируемый пользовательский файл дампа, для этого нужно нажать кнопку Add Data Files и перейти на место хранения собранных пользовательских дампов. Выделите нужный файл. dmp и нажмите Open. Теперь виден добавленный файл дампа, и все готово для начала анализа.

Нажмите кнопку Start Analysis, чтобы выполнить выбранный сценарий. DebugDiag показывает результаты анализа и автоматически сохраняет аналитический отчет в папке DebugDiagReports и открывает его в Internet Explorer.

Этот отчет имеет три главных раздела:

1. Сводка результатов анализа Analysis summary — сообщения типа выводимых Event Viewer, в которых записаны ошибки, предупреждения и информация, имеющая отношение к анализу пользовательского дампа вместе с описанием и рекомендациями для устранения ошибки или предупреждения.

2. Подробный анализ Analysis details — показывает таблицу с перечислением всех анализируемых дампов памяти. Для каждого дампа памяти есть список названий отчетов, которые указывают тип выполненного анализа.

3. Результат работы сценария Script summary — сообщает статус выполненного сценария для анализа пользовательского дампа. Если во время работы сценария возникали какие-то ошибки, в этом разделе перечисляются код ошибки, источник, описание и строки, которые вызвали ошибки.

Приближаясь к решению. 

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

Также есть возможность изучить нашу ситуацию с помощью инструментов типа WinDbg и AppVerifier.

Более подробно об этом можно почитать здесь:
https://www.codeproject.com/Articles/707488/Part-1-Windows-Debugging-Techniques-Debugging-Appl

Успехов вам в исследованиях.