При отладке приложений — например, когда возникают сбои и снижается скорость выполнения, происходят отказы, зависание и утечка памяти, — обычно требуется исследовать процессы, выполнявшиеся в момент возникновения сбоя. Задача осложняется тем, что серверные приложения, такие как Microsoft IIS, Exchange Server, SQL Server, COM+ и BizTalk Server, часто не имеют пользовательского интерфейса и автоматически перезагружаются без указания причин сбоя. Наличие под рукой удобного инструмента для отладки, который бы находил причину сбоя, при этом очень желательно. Для таких целей Debug Diagnostic Tool (DebugDiag) в большинстве случаев подходит больше, чем другие средства отладки, например ADPlus, Userdump и WinDbg. Почему именно DebugDiag?
Чтобы ответить на этот вопрос, давайте сначала посмотрим, почему процесс может дать сбой. Сбой — это неожиданное прекращение работы программы в случае, когда процесс завершается аномально. Обычно сбой бывает вызван необрабатываемым исключением; но происходит это и в том случае, когда процесс обнаруживает проблемную ситуацию и завершается без обработки исключения (например, процесс зацикливается, вызывая чрезмерное использование памяти).
Часто в такой ситуации процесс или служба запускаются повторно в надежде, что сбой больше не повторится. Однако, чтобы действительно понять причину, которая вызвала сбой, и устранить ее, необходимо выполнить анализ состояния процессов в момент сбоя. Локализовать это состояние можно, создавая пользовательский файл дампа. Эти файлы генерируются любыми отладчиками Windows, они имеют расширения .dmp,.hdmp или .mdmp. Основные отладчики Windows для процессов — это Windbg, Cdb и ntsd, их пользовательские дампы для анализа могут содержать ключи к разгадке причин сбоя. Точный анализ файла дампа для процесса может потребовать просмотра экспертом. И вот тут понадобится DebugDiag, который заметно упрощает анализ процесса поиска ошибок.
Инструмент DebugDiag комбинирует многие основные функции каждого отладчика из набора Windows Debugging Tools (ADPlus, Userdump и WinDbg), кроме того, он снабжен прекрасным пользовательским интерфейсом, что облегчает его применение. Самую последнюю версию DebugDiag можно загрузить по адресу www.microsoft.com/downloads/details.aspx? familyid=28bd5941-c458–46f1-b24df60151d875a3. DebugDiag устанавливается как служба, поэтому установленные в нем настройки будут сохраняться после перезагрузки системы. Инструмент выполняет свою работу быстро, его легко применять, он доступен. Он позволяет быстро отправить информацию производителям для доработки и выявления ошибок. DebugDiag требует менее 19 Mбайт памяти на диске и работает на Windows Vista/XP/2000/NT и Windows Server 2003; на Windows Server 2008 этот инструмент не проверялся.
DebugDiag в действии
Рассмотрим, как подразделение Microsoft Global Escalation Services использует DebugDiag для работы с вопросами клиентов. Пример: на Web-сайте клиента постоянно случались сбои, и мы думали, что причиной была ошибка процесса Web-сервера Microsoft World Wide Web. Поэтому мы установили DebugDiag и настроили его специально на сбои в службе публикации World Wide Web Publishing Service.
После установки и запуска DebugDiag сразу возникает диалоговое окно мастера Select Rule Type, в котором можно выбрать нужное правило. Это правило зависит от того, что надо проверить. В нашем примере целью были сбои в процессе, поэтому следовало выбрать тип правила Crash (сбой) в диалоговом окне Select Rule Type, потом нажать кнопку Next.
Теперь выбираем тип процесса для отслеживания в диалоговом окне Select Target Type, например отдельная служба NT, какой-то конкретный процесс (прикладной процесс или все процессы IIS/COM+). Для данного случая при поддержке клиента мы выбрали мониторинг отдельной службы и потом службу публикации World Wide Web Publishing Service в диалоговом окне Select Target.
В следующем окне мастера Advanced Configuration (Optional) настраиваем необязательные расширенные настройки для мониторинга сбоя. В нашем случае мы просто выбрали вариант по умолчанию и нажали Next. Затем появляется диалоговое окно для ввода имени правила и пути, где будет храниться информация пользовательского дампа; нажимаем Next, чтобы сохранить параметры по умолчанию или вносим изменения, например меняем каталог по умолчанию для хранения файлов дампа.
В последнем диалоговом окне можно активировать правило сразу или позднее вручную. Затем нажимаем Finish. Замечу, что можно выбрать параметр activate later, если не планируется проводить мониторинг сейчас, на случай завершения настройки в дальнейшем.
Теперь появляется главное окно приложения DebugDiag с тремя вкладками. Выбираем вкладку Rules, чтобы увидеть настроенные правила для этой системы, имя правила, состояние правила (активное или нет) и счетчик пользовательского дампа Userdump Count. Параметр Userdump Count — это число сбоев в проверяемом процессе, которые DebugDiag обрабатывает и сохраняет информацию по адресу в столбце Userdump Path. На вкладке Processes показаны запущенные в данный момент на системе процессы.
Анализ информации
После настройки DebugDiag с целью мониторинга отдельного процесса можно перезагрузить систему и выйти из сеанса, не заботясь о нарушении процесса мониторинга. Если есть подозрение, что отслеживаемый процесс дал сбой, можно проверить окно приложения DebugDiag и просмотреть столбец Userdump Count, чтобы убедиться, что пользовательский файл дампа создан.
На экране 1 показана вкладка Advanced Analysis, в которой надо выбрать сценарий работы для анализа информации пользовательского дампа для процесса мониторинга.
Здесь выбран сценарий Crash/Hang Analyzers (анализаторы сбоя/зависания), так как требуется анализировать сбой процесса. Затем следует добавить анализируемый пользовательский файл дампа, для этого нужно нажать кнопку Add Data Files и перейти на место хранения собранных пользовательских дампов. Выделите нужный файл. dmp и нажмите Open. Теперь виден добавленный файл дампа, и все готово для начала анализа.
Нажмите кнопку Start Analysis, чтобы выполнить выбранный сценарий. DebugDiag показывает результаты анализа и автоматически сохраняет аналитический отчет в папке DebugDiagReports и открывает его в Internet Explorer. Этот отчет имеет три главных раздела:
-
Сводка результатов анализа Analysis summary — сообщения типа выводимых Event Viewer, в которых записаны ошибки, предупреждения и информация, имеющая отношение к анализу пользовательского дампа вместе с описанием и рекомендациями для устранения ошибки или предупреждения.
-
Подробный анализ Analysis details — показывает таблицу с перечислением всех анализируемых дампов памяти. Для каждого дампа памяти есть список названий отчетов, которые указывают тип выполненного анализа.
-
Результат работы сценария Script summary — сообщает статус выполненного сценария для анализа пользовательского дампа. Если во время работы сценария возникали какие-то ошибки, в этом разделе перечисляются код ошибки, источник, описание и строки, которые вызвали ошибки.
В случае сбоя Web-службы публикации World Wide Web Publishing Service мы нашли решение в разделе рекомендаций Analysis summary (см. экран 2).
Приближаясь к решению
Скорее всего, DebugDiag не может решить все проблемы с процессами в Windows, но все же, как правило, этот инструмент предоставляет информацию, которая приближает к решению. Иногда можно получить только имя файла .dll, который вызвал сбой, и узнать его автора. Эти данные уже могут служить основой поиска решения в Internet или в службе технической поддержки.
Майкл Моралес (morales@microsoft.com) — старший инженер службы поддержки Microsoft Global Escalation Services. Специализируется на проблемах отладки и производительности Windows