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