Система отчета об ошибках 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.
На системах с исходными настройками отчет об ошибке (мини-дамп и 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
Выключена ли служба WER
1 — для выключения WER
DisableQueue
Определение необходимости постановки
отчетов в очередь
1 — для выключения очереди
DontShowUI
Выключение или включение WER UI
1 — для выключения 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) будет записано сообщение. Тем самым будут решены все проблемы тихой смерти процесса: пользователи оповещены, отладка может быть произведена, а администраторы службы могут просмотреть аварийное событие.