Модернизация приложений
Часть 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 в случае возникновения сбоев, «зависаний» или ошибок уровня ядра операционной системы, выглядит следующим образом:
- Возникновение проблемы.
- Ядро операционной системы вызывает WER.
- WER собирает данные, создает отчет и, при необходимости, запрашивает от пользователя подтверждение на отсылку отчета.
- При получении подтверждения WER отсылает отчет в Microsoft (так называемый Watson Server).
- Если серверу требуются дополнительные данные, WER собирает их и, при необходимости, запрашивает от пользователя подтверждение на отсылку.
- Если приложение зарегистрировано для перезапуска (эту проблему мы обсуждали выше), WER выполняет соответствующую косвенно вызываемую функцию приложения.
- Если существует решение проблемы, приведшей к сбою, пользователь получает уведомление с помощью соответствующих средств операционной системы
- В зависимости от ситуации, в 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 — различные возможности настройки пользовательского интерфейса при создании и отсылке отчетов.
 |
|
