Pages Menu
Categories Menu

Опубликовано | Нет комментариев

Система Windows Error Reporting

Система отчета об ошибках Windows Error Reporting (WER) является сложным механизмом, автоматизирующим представление сбоев процессов пользовательского режима и режима системных сбоев.

Windows Error Reporting может быть настроена путем перехода в Панель управления (Control Panel) и выбора Центр поддержки (Action Center) -> Настройка центра поддержки (Change Action Center) -> Параметры отчета о неполадках (Problem Reporting Settings).

Когда фильтр необработанных исключений, упомянутый в предыдущем разделе, отлавливает такое исключение, он создает контекстную информацию (например, текущее значение регистров и стека) и открывает подключение ALPC-порта к WER-службе. Эта служба приступает к анализу состояния аварийной программы и выполняет соответствующие действия по уведомлению пользователя. Во многих случаях это означает запуск программы WerFault.exe, которая выполняется с полномочиями текущего пользователя, и пока система не настроена на обратное, выводит окно сообщения, информирующее пользователя об аварии. На системах с установленным отладчиком показаны дополнительные возможности по отладке показанного процесса, что можно увидеть на рисунке.

При щелчке на пункте отладки (Debug) будет запущен отладчик (зарегистрированный в строке Debugger, рассмотренном ранее параметре AeDebug), чтобы подключиться к аварийному процессу.

Windows-Error-Reporting

Диалоговое окно Windows Error Reporting.

На системах с исходными настройками отчет об ошибке (мини-дамп и XML-файл с различными подробностями, например, с номерами версий DLL-библиотек, загруженных в процессе) отправляется на интернет-сервер Microsoft, занимающийся анализом аварийных ситуаций. Затем, когда служба уведомляется о решении для проблемы, она выводит подсказку, информирующую пользователя о его действиях, которые нужно выполнить для решения проблемы.

Входящее сообщение будет также отображено в Центре поддержки. Кроме того, в Мониторе стабильности системы (ReliabilityMonitor) будут также показаны все экземпляры аварий приложений и системы.

ПРИМЕЧАНИЕ. WER будет активно (визуально) информировать пользователя аварийного приложения только в том случае, когда приложение имеет как минимум одно видимое интерактивное окно. В противном случае авария будет занесена в журнал, но пользователю придется вручную зайти в Центр поддержки для просмотра соответствующей записи. Такое поведение призвано избавить пользователя от путаницы, не выводя диалогового окна WER, относящегося к невидимым аварийным процессам, о которых пользователь может не знать, например, о службе, выполняемой в фоновом режиме.

В окружениях, где системы не подключены к Интернету или где администратор хочет контролировать, какие именно отчеты об ошибках будут представлены Microsoft, место назначения отчета об ошибках может быть настроено на внутренний файловый сервер. Средство MicrosoftSystemCenterDesktopErrorMonitoringпонимает структуру каталогов, созданных WindowsErrorReporting, и предоставляет администратору возможность получить избирательные отчеты об ошибках и отправить их компании Microsoft.

Если все рассмотренные операции должны были произойти в контексте сбойного потока, то есть как часть изначально установленного фильтра необработанных исключений, то иногда для слишком поврежденного потока может не получиться выполнить все эти довольно сложные шаги, и сбой может возникнуть в самом фильтре необработанных исключений. Такую «тихую смерть процесса» нельзя будет зарегистрировать, что затруднит отладку, а также выразится в невидимых сбоях в тех случаях, когда на машине не будет ни одного пользователя.

Чтобы избежать подобных проблем, если сбой произошел в самом фильтре необработанных исключений, имеющийся в Windows механизм WER выполняет эту работу вне аварийного потока, что позволяет зарегистрировать любую аварию процесса или потока и уведомить о ней пользователя.

WER содержит множество настраиваемых параметров, к которым пользователь может получить доступ через редактор групповой политики (Group Policy) или внося изменения в реестр вручную. В таблице представлен список вариантов настройки WER в реестре, показано их использование и возможные значения.

Эти значения находятся в подразделе HKLM\SOFTWARE\Microsoft\Windows\ Windows Error Reporting для настроек компьютера и в аналогичном пути в разделе HKEY_CURRENT_USER для настройки для каждого пользователя.

Настройки WER в реестре.

НастройкаСмыслЗначение
ConfigureArchiveСодержание архивных данных1 — для параметров, 2 — для всех данных
Consent\DefaultConsentКакие данные должны требовать согласия1— для любых данных, 2 — только для параметров, 3 — для параметров и безопасных данных, 4 — для всех данных.
Consent\DefaultOverrideBehaviorДолжен ли
DefaultConsent замещать значения согласия дополнительного модуля WER
1 — для разрешения замещения
Consent\PluginNameЗначение согласия для конкретного дополнительного модуля WERТо же самое, что и для
DefaultConsent
CorporateWERDirectoryКаталог для общего хранилища WERСтрока, содержащая путь
CorporateWERPortNumberПорт, используемый для
общего хранилища WER
Номер порта
CorporateWERServerИмя, используемое для общего хранилища WERСтрока, содержащая имя
CorporateWERUseAuthenticationИспользование для
общего хранилища WER встроенной аутентификации Windows (Windows
Integrated Authentication)
1— для разрешения встроенной аутентификации
CorporateWERUseSSLИспользование для
общего хранилища WER протокола защищенных сокетов (SSL)
1 — для разрешения SSL
DebugApplicationsСписок приложений, требующих от пользователя выбора между отладкой (Debug) и продолжением (Continue)
1— для предоставления
пользователю возможности
выбора
DisableArchiveВключен ли архив1 — для выключения архива
DisabledВыключена ли служба WER1 — для выключения WER
DisableQueueОпределение необходимости постановки
отчетов в очередь
1 — для выключения очереди
DontShowUIВыключение или включение WER UI1 — для выключения UI
DontSendAdditionalDataПредотвращение отправки дополнительных данных об аварии
1 — не отправлять
ExcludedApplications\AppNameСписок приложений, исключенных из WERСтрока, содержащая список
приложений
ForceQueueНужно ли отчеты отправлять в очередь пользователя1 — для отправки отчетов в очередь
LocalDumps\DumpFolderПуть, который нужно использовать для хранения дапм-файловСтрока, содержащая путь
LocalDumps\DumpCountМаксимальное количество дапм-файлов в путиСчетчик
LocalDumps\DumpTypeТип дампа, генерируемого при аварии0 — для специального дампа, 1 — для мини-дампа, 2 — для полного дампа
LocalDumps\CustomDumpFlagsДля специальных дампов, указывает их специализациюЗначения, определенные в MINIDUMP_TYPE
LoggingDisabledВключение или выключение ведения журнала1 — для выключения ведения журнала
MaxArchiveCountМаксимальный размер архива (в файлах)Значение в диапазоне 1–5000
MaxQueueCountМаксимальный размер очередиЗначение в диапазоне 1–500
QueuePesterIntervalДни между запросами, чтобы пользователь мог проверить решенияКоличество дней

ПРИМЕЧАНИЕ. Значения, перечисленные в параметре LocalDumps, могут также быть настроены для каждого приложения путем добавления имени приложения в пути подраздела между LocalDumps и соответствующим значением. Но они не могут быть настроены для каждого пользователя, поскольку существуют только в пути HKLM.

Как уже говорилось, для связи с аварийными процессами служба WER использует ALPC-порт. Этот механизм использует общесистемный порт ошибки, который служба WER регистрирует через функцию NtSetInformationProcess (использующую DbgkRegisterErrorPort). В результате все процессы Windows теперь имеют порт ошибки, который на самом деле является объектом ALPC-порта, зарегистрированным службой WER. Ядро, которое уведомляется об исключении в первую очередь, использует этот порт для отправки сообщения службе WER, которая затем анализирует аварийный процесс.

Это означает, что даже в тяжелых случаях повреждения состояния потока WER все равно сможет получить уведомления и запустить WerFault.exe для вывода пользовательского интерфейса, не перекладывая эту работу на сам аварийный поток. Кроме того, WER сможет сгенерировать аварийный дамп процесса, и в журнал событий (Event Log) будет записано сообщение. Тем самым будут решены все проблемы тихой смерти процесса: пользователи оповещены, отладка может быть произведена, а администраторы службы могут просмотреть аварийное событие.

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.

↓