Модернизация приложений

Часть 6. Обеспечение стабильности приложений: механизм Windows Error Reporting

Алексей Федоров

Механизм Windows Error Reporting

Использование механизма Windows Error Reporting

Примеры использования Windows Error Reporting

 

В части 5 нашей статьи мы рассказывали о механизме Application Restart and Recovery. Сегодня мы продолжим обсуждение темы обес-печения стабильности приложений и поговорим о механизме Windows Error Reporting.

Механизм Windows Error Reporting

В предыдущих частях мы уже упоминали о механизме Windows Error Reporting (WER), с помощью которого можно собирать данные об ошибках, происходящих в приложениях, и либо отсылать эту информацию на специальный сайт Microsoft (сайт http://winqal.microsoft.com), либо сохранять локально. Сбор детальной информации об ошибках и сбоях помогает в устранении недостатков приложения и коррекции ошибок, упрощает выпуск пакетов обновлений и новых версий приложений, обеспечивает общую стабильность и надежность как самих приложений, так и операционной системы.

Отметим, что компания Microsoft сама активно использует механизм Windows Error Reporting как в процессе разработки, так и после выпуска продуктов на рынок. Так, продуктовая группа Microsoft Office исправила 50% ошибок в Office Service Pack 2, а продуктовая группа Visual Studio — 74% ошибок в Beta 1 Visual Studio 2005, 29% ошибок в Windows XP было исправлено в Windows XP Service Pack 1. В настоящее время более 2 тыс. компаний используют сервисы Windows Error Reporting для улучшения качества своих приложений.

Механизм Windows Error Reporting впервые появился в Windows XP, был существенно расширен в Windows Vista и получил дальнейшее развитие в Windows Server 2008, Vista Service Pack 1 и Windows 7, а также Windows Server 2008 R2.

Так, на уровне Windows Vista у разработчиков появилась возможность получать не только информацию о сбоях, произошедших в приложениях, но и данные о производительности, а также более гибко создавать, настраивать и отсылать отчеты о проблемах. Кроме того, улучшились средства онлайнового анализа данных и упростился механизм коммуникаций с пользователями — через механизм Problem Reports and Solutions (в Windows Vista: вызов — Start →Control Panel →System and Maintenance →Problem Reports and Solutions →View Problem History) и Action Center (в Windows 7).

Далее, в Windows Server 2008 и Vista Service Pack 1 теперь можно создавать локальные дампы, а в Windows 7 и Windows Server 2008 R2 добавлена возможность генерации исключений, которые не будут обрабатываться традиционными обработчиками и будут приводить к немедленному завершению приложения и автоматическому запуску механизма Windows Error Reporting, а также возможность задания внешнего процесса — обработчика исключений, который будет вызываться для получения названия события, параметров отчета об ошибке и опционального запуска отладчика.

Использование механизма Windows Error Reporting

Кратко рассмотрим, как разработчики могут использовать механизм Windows Error Reporting для получения информации о сбоях и других проблемах со своими приложениями. Начиная с Windows Vista, Windows по умолчанию предоставляет отчет о сбоях, «зависаниях» и ошибках уровня ядра операционной системы (kernel faults) для всех приложений — внесения изменений в код приложений не требуется. При необходимости отчет включает мини-дамп памяти и дамп «кучи» приложения, приложениям требуется использование программных интерфейсов в тех случаях, когда необходима отсылка какой­то специфической для приложения дополнительной информации. Поскольку ядро Windows автоматически собирает в отчет информацию о необработанных исключениях, приложениям не требуется обрабатывать исключения, приводящие к фатальным ошибкам.

Последовательность действий, выполняемых механизмом Windows Error Reporting в случае возникновения сбоев, «зависаний» или ошибок уровня ядра операционной системы, выглядит следующим образом:

  1. Возникновение проблемы.
  2. Ядро операционной системы вызывает WER.
  3. WER собирает данные, создает отчет и, при необходимости, запрашивает от пользователя подтверждение на отсылку отчета.
  4. При получении подтверждения WER отсылает отчет в Microsoft (так называемый Watson Server).
  5. Если серверу требуются дополнительные данные, WER собирает их и, при необходимости, запрашивает от пользователя подтверждение на отсылку.
  6. Если приложение зарегистрировано для перезапуска (эту проблему мы обсуждали выше), WER выполняет соответствующую косвенно вызываемую функцию приложения.
  7. Если существует решение проблемы, приведшей к сбою, пользователь получает уведомление с помощью соответствующих средств операционной системы
  8. В зависимости от ситуации, в CAB-файле могут присутствовать различные типы дампов, которые можно различить по расширению имени файла (табл. 1).

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

Для включения в состав отчета файла используется функция WerRegisterFile(), которой в качестве параметров передаются: полное имя файла, его тип (одно из значений WER_REGISTER_FILE_TYPE) и два флага: WER_DELETE_FILE_WHEN_DONE, указывающий на то, что файл должен быть удален после отсылки отчета, и WER_ANONYMOUS_ DATA, указывающий на то, что в файле не содержатся приватные данные. Возможные значения параметра WER_REGISTER_FILE_ TYPE приведены в табл. 2.

Отметим, что задача генерации дампа памяти возлагается на разработчика приложения — для ее решения можно применять, например, отладочные механизмы, описанные в Windows SDK (см. функцию MiniDumpWriteDump()).

Для исключения файла из отчета следует использовать функцию WerUnRegisterFile(), указав ей в качестве параметра имя исключаемого файла.

В большинстве сценариев отсылка дополнительных файлов происходит только при получении соответствующего запроса от сервера. В случае отсылки дополнительных файлов необходимо применять флаг WER_ADD_ REGISTERED_DATA при вызове функции WerReportSubmit() — о ней мы расскажем далее.

Для включения в состав отчета копии области памяти используется функция WerRegisterMemoryBlock(), в качестве параметров которой передаются адрес начала включаемого блока памяти и размер этого блока в байтах (максимальный размер блока памяти — WER_MAX_MEM_BLOCK_SIZE). Для отмены включения копии области памяти в отчет следует применять функцию WerUnRegisterMemoryBlock(). В случае отсылки данных из памяти необходимо использовать флаг WER_ADD_REGISTERED_DATA при вызове функции WerReportSubmit().

Функции WerSetFlags() и WerGetFlags() могут использоваться соответственно для управления состоянием процесса в момент генерации отчета от ошибках и для получения информации о настройках.

Процесс генерации и отсылки отчета состоит из нескольких шагов. Инициализация отчета выполняется вызовом функции WerReportCreate(), с помощью которой указывается тип события, для которого создается отчет, тип отчета (WerReportNonCritical — для сбоев с возможностью восстановления и WerReportCritical — для сбоев, повлекших аварийное завершение приложения), ссылка на информацию, включаемую в отчет (см. структуру WER_REPORT_INFORMATION), и переменная, которая будет содержать ссылку на созданный отчет, — ReportHandle.

После того как отчет успешно инициализирован, необходимо добавить в него параметры первой и второй групп. Параметры первой группы задаются с помощью функции WerReportSetParameter(), которой передается ссылка на созданный отчет (результат успешного выполнения функции WerReportCreate), набор флагов, имя параметра и его значение (16-битная строка в Unicode, заканчивающаяся нулем).

Для включения в состав отчета дополнительных параметров применяется функция WerReportAddSecondaryParameter(), которой передаются ссылка на отчет, имя параметра и его значение.

Помимо возможности включения в состав отчетов файлов и снимков областей памяти, предусмотрена передача в составе отчета и дампов памяти — для этого можно использовать функцию WerReportAddDump(), в качестве параметров которой указываются ссылка на отчет, ссылки на процесс и поток, для которых был создан дамп, тип дампа (одно из значений WER_DUMP_TYPE), информация об исключении (указатель на структуру типа WER_EXCEPTION_INFORMATION), дополнительные опции (тип данных WER_DUMP_CUSTOM_OPTIONS) и флаги. Отметим, что процесс, для которого создается дамп, должен иметь права доступа STANDARD_RIGHTS_READ и PROCESS_QUERY_INFORMATION.

Для включения в состав отчета файлов мы применяем функцию WerReportAddFile(), которой передаем ссылку на отчет, полное имя файла, тип файла (WER_FILE_ TYPE) и дополнительные флаги.

Помимо этого разработчикам предоставляется возможность настройки пользовательского интерфейса — выбора информации, отображаемой в системной диалоговой панели. Для этих целей служит функция WerReportSetUI Option(), которой передается ссылка на отчет, тип интерфейса отчета (WER_REPORT_UI) и значение отображаемой строки. Приложение может модифицировать любое из полей интерфейсного элемента, заданного параметром WER_REPORT_UI; каждый вызов функции позволяет модифицировать только одно поле. Функция WerReportSetUIOption() может вызываться в любой момент работы приложения до непосредственной отсылки отчета.

После того как отчет сформирован и настроен, мы используем функцию WerReportSubmit() для отсылки отчета. В качестве параметров этой функции передаются ссылка на отчет, тип пользовательского интерфейса (наличие прав администратора, подтверждение отсылки и т.п.) и набор флагов. После того как отчет отослан, следует закрыть ссылку на него, используя функцию WerReportCloseHandle().

Для отключения приложения от механизма Windows Error Reporting следует использовать функцию WerAddExcludedApplication(), а для повторного подключения — функцию WerRemoveExcludedApplication().

Настройки Windows Error Reporting располагаются в двух ветвях реестра:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting;
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting.

Наиболее полезные настройки показаны в табл. 3.

Примеры использования Windows Error Reporting

В Windows SDK включен ряд примеров применения механизма Windows Error Reporting, которые можно использовать в качестве отправной точки для создания собственных приложений:

  • AddDump — применение программных интерфейсов Windows Error Reporting для создания отчета, содержащего файл дампа текущего процесса;
  • AddFile — использование программных интерфейсов Windows Error Reporting для создания отчета, содержащего дополнительный файл;
  • RegisterFile — применение функции WerRegisterFile() для подключения к отчету дополнительных файлов;
  • RegisterMemoryBlock — использование функции WerRegisterMemoryBlock() для включения в состав мини-дампа содержимого блока памяти;
  • RuntimeExceptionModule — применение технологии runtime exception, которая появилась в Windows 7 и Windows Server 2008 R2. Модуль, обрабатывающий ошибки во время исполнения, — это внепроцессная библиотека, загружаемая WER при возникновении сбоя. Данная библиотека реализует и экспортирует следующие функции:
    • OutOfProcessExceptionEventCallback(),
    • OutOfProcessExceptionEventSignatureCallback(),
    • OutOfProcessExceptionEventDebuggerLaunchCallback();
  • UICustomization — различные возможности настройки пользовательского интерфейса при создании и отсылке отчетов.

 

В начало В начало

КомпьютерПресс 07'2011