report wer что это
Что такое и как работают отчеты о ошибках
Всем пользователям знакома ситуация, когда приложение Windows завершается некорректно и выдает диалоговое окно с уведомлением. Из этой познавательной статьи Вы узнаете что это такое, где хранятся файлы и как она работает вообще.
С Windows Vista вместо старого «инструмента анализа системных сбоев или аварий» пришла новая Windows Error Reporting (WER) – Служба регистрации ошибок Windows (другие названия – Отчеты о проблемах и их решениях, Отчеты о проблемах и решения).
Эти сигнатуры никуда не удаляются и находятся в системных папках по пути
\Users\Master\AppData\Local\Microsoft\Windows\WER\ReportArchive\
каждый отчет сохраняется в новой (или существующей) папке Report******** (например, Report0b003f38), в файле Report.wer.
Если зайти в этот каталог и просмотреть содержание, то можно увидеть следующее:
Как запустить службу Отчеты о проблемах и их решениях
Пуск –> Панель управления –> Отчеты о проблемах и их решениях
На этом познавательная статья о регистрации и отчетах ошибок считается закрытой.
Microsoft Windows 7: рекомендации по улучшению стабильности приложений
В предыдущей статье данного цикла, посвященной механизму Application Restart and Recovery, мы упомянули механизм Windows Error Reporting (WER). О нем и пойдет речь в настоящей статье данного цикла
В предыдущей статье данного цикла, посвященной механизму Application Restart and Recovery, мы упомянули механизм Windows Error Reporting (WER). О нем и пойдет речь в настоящей статье данного цикла.
Механизм Windows Error Reporting
С помощью механизма Windows Error Reporting (WER) можно собирать данные об ошибках, происходящих в приложениях, и либо отсылать эту информацию на специальный сайт Microsoft (сайт http://winqal.microsoft.com), либо сохранять ее локально. Сбор детальной информации об ошибках и сбоях помогает в устранении недостатков приложений, коррекции ошибок, упрощает выпуск пакетов обновлений и новых версий приложений, обеспечивает общую стабильность и надежность как самих приложений, так и операционной системы.
Отметим, что компания Microsoft сама активно использует механизм Windows Error Reporting как в процессе разработки, так и после выпуска продуктов на рынок. Так, продуктовая группа Microsoft Office исправила 50% ошибок в Office Service Pacl 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 выполняет следующую последовательность действий:
В зависимости от ситуации в 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.
После того как отчет успешно инициализирован, необходимо добавить в него параметры первой и второй групп. Параметры первой группы задаются с помощью функции WerReport-Set-Parameter(), которой передается ссылка на созданный отчет (результат успешного выполнения функции 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 располагаются в двух ветвях реестра:
Наиболее полезные настройки показаны в табл. 3.
Заключение
В данном цикле статей мы обсудили различные вопросы улучшения стабильности работы приложений. Мы рассмотрели технику, позволяющую избежать утечки памяти, предотвратить зависание приложений, обсудили использование механизма Application Restart and Recovery, позволяющего перезапускать приложения, которые либо заблокировали какието ресурсы, либо перестали реагировать на сообщения системы, и механизма Windows Error Reporting, который дает возможность собирать данные о сбоях, происходящих в приложениях.
В следующих статьях, посвященных операционной системе Windows 7 для разработчиков, мы рассмотрим ряд изменений на уровне ядра операционной системы, которые могут представлять интерес для разработчиков приложений.
Как включить или отключить службу отчетов об ошибках Windows 10
Служба отчетов об ошибках Windows 10 предназначена для обеспечения оптимальной работы вашего ПК. Основная идея Windows Error Report (WER) – информировать Microsoft о проблемах пользователей при работе с Windows.
Однако в каждой версии ОС Windows служба включена по умолчанию. Но отдельный пользователь может отключить его, если возникнет такая необходимость. В этой статье рассматривается, как включить или отключить службу отчетов об ошибках в Windows 10.
Как работает служба отчетов об ошибках Windows 10 и почему
В отчете об ошибках Windows 10 основное внимание уделяется обнаружению аппаратных и программных проблем с ПК пользователя и отправке отчетов в Microsoft. Имея базу данных о вероятных жалобах на использование Windows 10, Microsoft может затем отправить решения для устранения неполадок.
При работе с ПК у некоторых пользователей появляются всплывающие окна или оповещения, требующие отправки отчета о проблеме. Отчет об ошибках Windows обычно появляется после сбоя системы, сбоя программы, отказа в правильной загрузке или ошибок операционной системы. Windows обычно предлагает пользователю отправить отчет об ошибке в Интернете, чтобы помочь найти решения в будущем. Отчет о проблеме может содержать название программы, дату, время ошибки и версию.
Должен ли я отключить службу отчетов об ошибках Windows?
Пользователи Windows часто отключают отчеты об ошибках из-за дискового пространства или из-за проблем с конфиденциальностью, но им, возможно, придется проявлять сдержанность. Служба отчетов об ошибках для Windows 10 предлагает двойную выгоду для Microsoft и пользователей ПК.
Каждый отчет об ошибках помогает Microsoft разрабатывать более продвинутые пакеты обновлений для устранения сбоев. Это означает лучшее взаимодействие с Windows 10 на основе собранной информации.
Действия по отключению службы отчетов об ошибках Windows 10
Как и в других версиях, Windows 10 имеет несколько иной графический интерфейс пользователя для отключения отчета об ошибках. Более низкие версии ОС Windows имеют отчеты об ошибках в настройках Центра поддержки. В Windows 10 это функция безопасности и обслуживания, требующая работы с реестрами.
Это простой и понятный процесс. Вот шаги, чтобы следовать:
Примечание:
В некоторых случаях тип запуска, близкий к отключенному, может отображаться серым цветом. Это означает, что пользователю необходимы права администратора для продолжения процесса. Поэтому выйдите и войдите как администратор. Или найдите административную командную строку, нажав клавишу Windows + X, чтобы выбрать командную строку администратора.
Способ второй: использовать редактор реестра
Использование редактора реестра – это еще один способ безопасного отключения службы отчетов об ошибках Windows 10. Этот второй способ отключения службы отчетов об ошибках Windows включает настройку реестра. Но сначала вам нужно проверить наличие сообщений об ошибках:
Действия по отключению службы отчетов об ошибках Windows с помощью редактора реестра
Примечание:
Это довольно просто отключить и включить службу отчетов об ошибках Windows 10 в любое время. А понимание того, как использовать редактор реестра или поиск, делает все намного проще.
Using WER
Beginning with Windows Vista, Windows provides crash, non-response, and kernel fault error reporting by default without requiring changes to your application. The report will include minidump and heap dump information if required. Applications instead use the WER API to send application-specific problem reports to Microsoft.
Because Windows automatically reports unhandled exceptions, application should not handle fatal exceptions. If the faulting or not-responding process is interactive, WER displays a user interface informing the user of the problem. An application is considered unresponsive if it does not respond to Windows messages for five seconds while the user is trying to interact with the application.
Windows Error Reporting flow for crashes, non-response, and kernel faults
The following shows the steps that occur for an application crash, non-response, or kernel fault.
Applications can use the following functions to customize the contents of the report that is sent to Microsoft. The registration functions tell WER to include the specific files and memory blocks in the error report that it creates.
Windows Error Reporting flow for generic event reporting
The following steps show how applications can get an error report for a non-fatal error condition.
Excluding an application from Windows Error Reporting
To exclude your application from Windows error reporting, use the WerAddExcludedApplication function. To restore error reporting for your application, use the WerRemoveExcludedApplication function.
Automatically recovering data and restarting a faulted application
An application can use Application Recovery and Restart to save data and state information before the application exits due to an unhandled exception or when the application stops responding. The application is also restarted, if requested. For details, see Application Recovery and Restart.
Legacy API
An application can report a fault by calling the ReportFault function. However, you should not use the ReportFault function unless you have a very specific requirement that the operating system’s default error reporting behavior cannot fulfill.
If error reporting is enabled, the system displays a dialog box to the user indicating that the application has encountered a problem and will close. If there is a debugger configured in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug key, the user is given the option to launch the debugger. The user is also given the option to send a report to Microsoft. If the user sends the report, the system displays another dialog box thanking the user for the report and providing a link to more information.
The error reporting system supports the following operation modes.
| Operation mode | Description |
|---|---|
| Shared memory reporting | If the application’s security context is the same as the security context of the logged-on user, the error reporting system uses a block of shared memory for communication. This mode cannot be used with manifest reporting mode. |
| Manifest reporting | If the application’s security context is not the same as the security context of the logged-on user, the error reporting system uses a file for communication. This mode is also used for reporting unresponsive applications and kernel faults. This mode cannot be used with shared memory reporting mode. |
| Internet reporting | The error reporting system sends all data to Microsoft through the Internet. This is the default mode of operation. It cannot be used with corporate reporting mode. This mode is used when there is no corporate upload path specified by the administrator. |
| Corporate reporting | The error reporting system sends all data to a file share instead of uploading it directly to Microsoft. This allows corporate IT managers to review data before it is sent to Microsoft. This mode is used when there is a corporate upload path specified by the administrator. It cannot be used with Internet reporting mode. |
| Headless reporting | The error reporting system will not display any dialog boxes to the user. This allows corporate IT managers to collect error reports from their employees at all times. This mode is used when reporting is enabled by the administrator, but notification is disabled. It can be used only with corporate reporting mode. |
To exclude your application from error reporting, use the AddERExcludedApplication function.
About WER
Windows Error Reporting (WER) is a flexible event-based feedback infrastructure designed to gather information about the hardware and software problems that Windows can detect, report the information to Microsoft, and provide users with any available solutions. For information about the improvements to WER, see What’s New in WER.
Beginning with WindowsВ Vista, Windows provides crash, no response, and kernel fault error reporting by default without requiring changes to your application. Applications instead use the WER API to generate error reports for application-specific issues that are not related to crashes, non-responses, or kernel faults.
To generate error reports for application-specific issues, the application must create a short description of the problem using a few basic pieces of information called report parameters. Report parameters include information such as the application name, application version, module name, module version, and error code. The combination of these report parameters describes a unique problem.
When WER checks for a solution, it communicates with the WER server at Microsoft by first asking if the problem is already known. The server responds in one of the following ways:
Using this process, WER gathers more information if needed or sends a solution to the user when available. On WindowsВ Vista, the user can go to Problem Reports and Solutions at any time to view available solutions, check whether new solutions are available, or manage their other WER reports and settings. On WindowsВ 7, the Problem Reports and Solutions is now called the Action Center. Click Start and enter «view» in Search programs and files and then select View all problem reports, View reliability history, or View solutions to problems.