Windows wer reportqueue что это

Служба отчетов об ошибках Windows и очистка каталога WER ReportQueue в Windows

Служба WER ( Windows Error Reporting ) служит для сбора и отправки отладочной информации о падении системных и сторонних приложений в Windows на сервере Microsoft. По задумке Microsoft, эта информация должна анализироваться и при наличии решений, вариант исправления проблемы должен отправляется пользователю через ответ с отчетом об ошибках Windows. Но по факту мало кто пользуется этим функционалом, хотя Microsoft настойчиво обслуживает службу сбора ошибок WER включенной по умолчанию во всех последних версиях Windows. В большинстве случаев о службе WER вспоминают, когда каталог C: ProgramData Microsoft Windows WER ReportQueue начинает занимать на системном диске довольно много места (вплоть до нескольких десятков Гб), даже не смотря на то что на этом каталоге по умолчанию включена NTFS компрессия.

Служба отчетов об ошибках Windows

Служба отчетов об ошибках Windows представляет собой отдельный сервис Windows, который можно легко отключить команду:

Внутри каталога WER ReportQueue массив ката логов, с именами в формате:

Очистка папок WER ReportQueue в Windows

Как правило, размер каждой папки незначителен, но в некоторых случаях для проблемного процесса создается дамп памяти, который занимает довольно много места. На скриншоте ниже видно, что размер файла дампа memory.hdmp составляет около 610 Мб. Парочка таких дампов — и на исчезло несколько свободных гигибайт.

Для быстрого освобождения места на диске от файлов отладки, сгенерированных службой WER, содержимое следующих каталогов можно безболезненно удалить и руками.

Отключение ошибки окна Отчеты в Windows Server 2012 R2/2008 R2

Отключить запись информации об ошибках Отчеты об ошибках Windows в серверных редакциях Windows можно следующим образом:

Отключение функции сбора и отправки отчетов в Windows 10

Теперь еще раз проверим статус решения проблемы Поиск решения для указанных в отчетах проблем в панели управления. Его статус должен изменится на Отключено.

Отключение отчетов об ошибках Windows через групповые политики

В результате сообщений об ошибках приложений в Windows перестанут формироваться и автоматически отправляться в Microsoft.

Источник

Система Windows Error Reporting

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

Когда фильтр необработанных исключений, упомянутый в предыдущем разделе, отлавливает такое исключение, он создает контекстную информацию (например, текущее значение регистров и стека) и открывает подключение 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 в реестре.

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

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

Источник

. when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

8 мая 2017 г.

Windows Error Reporting и Delphi

Windows Error Reporting (сокращённо: WER) — это набор технологий, встроенных в Windows, который собирает информацию о сбое в приложениях при их вылетах (а также о сбоях ядра) и отправляет её на сервера Microsoft. Разработчик программного обеспечения по этой информации может разработать и опубликовать соответствующее обновление. Затем конечный пользователь, отправляя отчёт, увидит, что для этой ошибки в программе доступно исправление, сможет скачать его и обновить программу.

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

Содержание

Что происходит при сбое

История Windows Error Reporting

16-битные Windows

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

Доктор Ватсон собирал информацию о системе, сбое и состоянии программы («симптомы»). Информация записывалась в отладочный лог-файл, который потом мог быть доставлен разработчикам программы для анализа.

Компилятор Watcom C также стал поставляться со своим собственным аналогом Доктора Ватсона, называвшегося «Доктор Ватком» (Dr. Watcom).

Пример необработанного исключения в Delphi 1, которое было поймано WinSpector:

32-битные Windows

Вплоть до Windows 2000 Доктора Ватсона нужно было запускать вручную до запуска программы, в которой происходил вылет. Доктор Ватсон просто работал в фоне и мог собирать информацию о системе, которая потом сбрасывалась в текстовый отчёт.

После этого при вылете приложения система читала ключ реестра, запускала Доктора Ватсона, он подключался к приостановленному процессу, собирал информацию:

В любом случае, эту информацию можно было затем просмотреть и отправить разработчику программы:

Это был прообраз того, что затем стало службой Windows Error Reporting.

Windows XP

В-третьих, он добавляет события о вылетах в системный журнал.

Наконец, в-четвёртых, он может быть сконфигурирован из апплета Система Панели Управления:

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

Примечание: однако, если вместо этого вы вручную удалите параметр Debugger ключа AeDebug (в котором и зарегистрирован Доктор Ватсон), то настройки, конечно, будут игнорироваться. Система покажет обычное окно о фатальном сбое в приложении:

Если же вы выключите отчёты, но включите опцию «уведомлять о критических ошибках», то Доктор Ватсон будет показывать отчёты о вылетах приложений:

но не будет показывать отчёты, сгенерированные вручную (через ReportFault ). События о вылетах также будут добавлены в системный лог:

Включение же отчётов покажет в диалоге новую опцию: «Отправить отчёт».

при нажатии на которую собранный отчёт отправляется на серверы Microsoft:

а также добавит отдельное событие в системный лог:

Но почему отчёт отправляется Microsoft, а не разработчику программы? Дело в том, что вылет в модуле (exe или DLL) может не быть виной этого модуля. Быть может просто другой модуль неверно нас вызвал. Например, вылет проводника может быть из-за кривого расширения оболочки. Вылет игры может быть обусловлен глюком в видеодрайвере и т.д. Вот почему отчёты отправляются в централизованное хранилище. Там они сортируются и к отчётам допускаются все разработчики, чьи модули (exe или DLL) были упомянуты в отчёте.

Microsoft не использует данные отчётов для каких-либо маркетинговых анализов, анализов частоты ошибок в различных программах т.п. Все данные пользователей защищаются от постороннего доступа и используются только для поиска причины ошибки. Отчёты отправляются по защищённому SSL соединению и хранятся на защищённых серверах, которые не используются ни для каких других целей. Для доступа к отчётам нужно предоставить логин и пароль (задаваемые при регистрации в WinQual). Любой разработчик может видеть только отчёты для своих программ. Все компании, использующие WER, обязуются следовать аналогичным политикам. Разумеется, нет гарантий, что небольшая компания из трёх человек, занимающаяся разработкой shareware-софта, заинтересована в соблюдении вашей конфиденциальности столько, сколько сама Microsoft (хотя она и согласилась следовать соответствующим политикам). Кроме того, по-умолчанию данные отчёта не содержат никаких данных пользователя, кроме тех, которые случайно попадут в дамп. Т.е. персональные данные специально не собираются. В отчёт они могут попасть только случайно. Тем не менее, вы можете посмотреть данные отчёта перед отправкой в случае, если вы работали с важными данными перед вылетом программы.

В частности, после того как Microsoft реализовала механизм отправки отчётов в Windows XP, она позднее провела широкомасштабный анализ присланных данных, который показал, что 80% пользовательских проблем могут быть решены исправлением 20% наиболее «популярных» ошибок. Даже исправление 1% самых частых ошибок устранит 50% пользовательских проблем!

Windows Vista и позднее

Для начала, теперь WER вообще не нужно регистрироваться в системе. По умолчанию ключ AeDebug / Debugger вообще не существует, WER вызывается по умолчанию. Кроме того, в системе теперь есть специальная служба WerSvc («Windows Error Reporting Service» / «Служба регистрации ошибок Windows»), которая по умолчанию стоит на ручном (Manual) запуске и автоматически запускается системой при необходимости.

Бывший Доктор Ватсон теперь поддерживает настройку через групповые политики («Административные шаблоны» / «Компоненты Windows» / «Windows Error Reporting»), включая возможность указания альтернативных серверов для сбора отчётов (корпоративные настройки) и локальных дампов.

API был расширен и теперь приложения могут вручную сообщать не только о вылетах, но и о почти любой feedback-информации, прикреплять к отчёту дополнительные данные и файлы.

В Windows 7 он был сгруппирован с «Обслуживанием» центра решений Windows («Центр безопасности и обслуживания»):

В Windows Vista можно было изменить все те же опции, что и в Windows XP:

Но уже в Windows 7 набор опций был уменьшен:

Жирным отмечены отчёты, которые не были отправлены. Вы можете просмотреть технические сведения по любому отчёту:

отправить любой отчёт или все сразу, а также удалить все отчёты. Опция «Проверить решения» заново отправит сигнатуры всех отчётов (что может быть очень долго!) и сообщит вам, если разработчики программ выпустили какие-либо исправления к этим отчётам.

Следующий вариант «Всегда спрашивать» ( Windows Error Reporting / Disabled = 0; Windows Error Reporting / Concent / DefaultConsent = 1) предложит или закрыть программу или отправить отчёт:

Нажатие на кнопку отправки запустит отправку отчёта:

Заметьте, что в отличие от Windows XP, в Windows Vista помимо собственно лога прикладывается ещё и дамп процесса (.mdmp), который можно потом загрузить в отладчик Visual Studio или WinDbg, чтобы исследовать проблему.

Отключение службы WerSvc может повлиять на поведение отчётов. Например, Windows не сможет определить, был ли уже отправлен отчёт и каждый отчёт будет считать новым. Отправка отчётов внешне будет успешна, но, похоже, отчёты просто встают в очередь на отправку.

В некоторых случаях при вылете приложения Windows также может предложить поменять опции на «авто»:

Что Delphi делает не так

После чего приложение продолжает обычную работу (цикл выборки сообщений).

Иными словами (почти) любой код Delphi оказывается обёрнут в обработчик RTL, все исключения обрабатываются либо вашим кодом, либо RTL, поэтому настоящих необработанных исключений в Delphi не бывает.

Когда приложение Delphi может привести к вызову WER?

Необработанное исключение в не-RTL потоке

Повреждение стека/обработчика

Пример с перезаписью стека справедлив только для x86-32, т.к. на x86-64 стек не используется для блоков try (вместо этого используются табличные исключения, где все блоки try зарегистрированы в отдельной таблице, не хранящейся в стеке).

Переполнение стека

Двойное переполнение стека

Вызов UnhandledExceptionFilter

Замечу, что это поведение (консультация с UnhandledExceptionFilter из System._ExceptionHandler ) есть только под Windows, только при запуске вне отладчика, только при обработке исключения модулем System (т.е. не влияет на TThread и VCL), и почти, но не во всех версиях Delphi (правда, появилось оно очень давно).

Перенаправление на JIT-отладчик

System.JITEnable предназначена для отладки ваших приложений. Если в вашем приложении происходит исключение/вылет, которое вы не можете поймать под отладчиком (происходит только при запуске вне отладчика), то вы можете включить System.JITEnable и запустить вашу программу вне отладчика. Пусть она вылетит, вы подключите к программе посмертный отладчик (отладчик Delphi, конечно же) и исследуете проблему на месте.

Замечу, что даже если System.JITEnable отлична от нуля, то это просто передаст исключение «наверх», т.е. UnhandledExceptionFilter будет вызываться. И если вы (или кто-то ещё) назначит обработчик UnhandledExceptionFilter (через SetUnhandledExceptionFilter ) и он будет возвращать EXCEPTION_EXECUTE_HANDLER (для всех или только избранных исключений), то соответствующие блоки except всё же будут выполняться. Таким образом, вы всегда можете сделать тонкую настройку, выполнять обработку только избранных исключений. И в таком виде System.JITEnable вполне имеет право на жизнь и в production-коде.

Ручной вызов WER

Настройка Delphi-приложений для отправки отчётов

Зачем это делать

Поэтому с концепцией Delphi «ни за что не вылетать» нужно срочно что-то делать.

Лирическое отступление для тех, кому вообще не нравится концепция отправки отчётов

Итак, для начала нам нужна функция, которую мы будем вызывать для необработанных исключений:
Как видите, тут ужасно много всего.

Данный пример использует API уровня Windows XP (хотя будет работать в любой ОС), но вы также можете расширить этот пример на уровень Vista, чтобы полностью настроить поведение WER. В Vista вы можете изменять части диалога, добавлять в отчёт информацию и файлы и многое другое.

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

Вызов же SetWERVisible нужен чтобы окно WER появлялось бы всегда, даже если ошибка произошла в невизуальной части нашего приложения (см. обсуждение этого поведения выше).

И если вы хотите получать отчёты, но не хотите использовать WER, то вы можете использовать полностью аналогичный код:
В этом случае вызов SetUnhandledExceptionFilter становится обязательным, а не опциональным.

Во всех таких случаях нет чистого решения. Вы можете только установить ловушку на нужный код методом сплайсинга.

Настройка посмертного отладчика

Опционально можно добавить ещё два параметра: второй %ld будет заменён на описатель (handle) события, который отладчик может взвести, чтобы возобновить выполнения процесса. При этом считается, что отладчик исправил проблему, и процесс может продолжить работу. Если его не указывать, либо отладчик его не взведёт, то система будет ждать завершения процесса отладчика, после чего возобновит обычную работу WER, т.е. считается, что проблема не исправлена. В большинстве случаев это не очень полезная возможность, которой на практике обычно не пользуются.

Кроме того, вы можете создать строковый параметр Auto и установить его в ‘0’ или ‘1’. Несложно сообразить, что при Auto = 1 диалоговое окно не показывается, посмертный отладчик запускается сразу. При Auto = 0 (умолчание), соответственно, появляется обычное окно с дополнительной кнопкой «Отладка» («Debug»).

Delphi при установке регистрирует себя в качестве посмертного отладчика. Но если потом устанавливается другая среда разработки, то она может перезаписать регистрацию посмертного отладчика. К сожалению, в Delphi нет никакого способа автоматически перерегистрировать посмертный отладчик, вам придётся сделать это вручную.

К примеру, для Delphi 5-7 установите Debugger в: только замените 70 (Delphi 7) на 50 (Delphi 5) или 60 (Delphi 6).

Для более новых версий Delphi используйте: В настоящее время параметр %p не принимает ни одна версия Delphi.

Отладчик Visual Studio не имеет возможности перерегистрации, его нужно регистрировать заново вручную. Для этого используется такая командная строка:

Например, отладчик Visual Studio позволяет выбрать отладчик так:

Этот список позволяет выбрать native-отладчик, управляемый (.NET) или Java-отладчик. Delphi там, само собой, нет. Это я просто пример привёл, как это визуально может выглядеть, если вы захотите сделать такую утилиту самостоятельно.

Использование Threads Snapshot в качестве посмертного отладчика

В качестве посмертного отладчика вы также можете использовать утилиту Threads Snapshot. Она входит в состав трейсера исключений EurekaLog. Если у вас нет EurekaLog, то вы можете скачать бесплатный Tools Pack.

Для установки Threads Snapshot в качестве посмертного отладчика достаточно запустить её с параметром » /install «:

Само собой, запускать нужно под администратором (и с элевацией прав).

Нажатие на кнопку Debug запустит снятие снимка процесса:

Восстановить регистрацию предыдущего посмертного отладчика можно запуском Threads Snapshot с параметром » /uninstall «.

Что я могу извлечь из отчёта WER?

Тип вылета

Код исключения

Класс исключения

В любом случае, в результате имеем:

Для исключений Delphi теперь показывается имя класса и сообщение исключения. Для аппаратных исключений всё осталось по прежнему, дополнительной информации мы не добавляем.

Напомню, эта кастомизация возможна только на Windows Vista и выше. На Windows XP отчёт не изменится.

Смещение/адрес исключения

Как только вы опознали что именно произошло, осталось понять где это произошло. Для этого посмотрите на параметры имя модуля (не приложения!) и смещение (offset) для этого модуля.

Почему вообще используется какое-то смещение? Почему бы в отчёте просто не указать адрес?

Окей, но как же узнать, что за код выполнялся по этому адресу?

Для этого вы можете использовать утилиту Address Lookup. Она входит в состав трейсера исключений EurekaLog. Если у вас нет EurekaLog, то вы можете скачать бесплатный Tools Pack. Запустите утилиту, укажите на модуль вылета и укажите смещение:

Альтернативно, вы можете использовать и саму Delphi. Для этого запустите программу (ровно той версии, что упомянута в отчёте) и поставьте её на паузу (Run / Pause), затем откройте окно со списком модулей: View / Debug / Modules и выясните по какому адресу оказался загружен модуль на вашей машине.

Если вы всё сделали правильно, то IDE откроет нужный модуль и ткнёт вас в строчку с ошибкой.

Однако у этого способа куча минусов. Во-первых, не только версия программы должна полностью совпадать с модулем, в котором произошёл вылет, вам также необходимо иметь копию всех исходников для этой версии, а также быть 100% уверенными, что при перекомпиляции вы получите точно ту же самую программу. В противном случае адреса будут отличаться и этот метод ткнёт вас в неверное место.

Стек, переменные и другая информация

Как мне получать отчёты WER?

Далее, вам потребуется Windows SDK. Не хочу давать прямую ссылку, они меняются. Поищите в Google по ключевым: download Windows SDK. Устанавливаете SDK. Вас там интересует только утилита SignTool.

Примечание: все современные сертификаты используют SHA-256 и не распознаются Windows XP и ниже (которая поддерживает только SHA-1).

Выглядит это примерно так (на скриншотах показан процесс для драйверов на developer.microsoft.com, поэтому и упоминается EV; я не могу сделать скриншоты для обычного сертификата, поскольку этот процесс я уже прошёл; напомню, что в настоящее время вам нужно заходить на sysdev.microsoft.com, где произойдёт аналогичный процесс):

Важно: вы должны использовать только Internet Explorer и у вас должен стоять Adobe Acrobat.

Фактически, тут вам нужно продублировать ваше имя и дату ( Ctrl + C / Ctrl + V ) и нажать «Submit».

Тут вас поджидает сюрприз, ибо установщик запросит установленный Windows Live Essentials, который. не доступен для скачивания. Придётся искать оффлайн установщик по неофициальным каналам. Короче, гуглите.

В любом случае, текущая версия Product Mapping Tool называется аж Microsoft Ecosystem Metadata Exchange (или MEME). Она попросит вас войти в вашу учётку и синхронизируется с сервером Microsoft.

Ну вот с помощью её мы и добавляем каждый выпуск (release) нашей программы. Само собой, добавляем Product, а не Driver. Ну и если у вас прям сложная программа, то можете создать ещё Product Group, но это не обязательно.

После этого можно деплоить и крашиться! После регистрации вид раздела Reports изменится на рабочий:

Учтите только, что отчётам нужно время, чтобы пройти отправку и сортировку, появляются они не сразу. Задержка будет от нескольких дней до месяца.

Вот как будет выглядеть раздел отчётов при поступлении багов:

Вы можете раскрыть любую запись:

Будут показана статистика и возможность скачать отчёты.

У записей также может не быть никаких данных, кроме статистики. Это потому, что они не собраны. Вы должны щёлкнуть «Request more data»:

WERInternalMetadata.xml выглядит примерно так (полный вариант из отчёта с 6-ю файлами; вариант из отчёта с тремя файлами существенно короче):

Что если я хочу использовать отчёты, но не хочу использовать WER?

Что если я не хочу изобретать при этом велосипед?

Тогда вам нужно использовать готовое решение. Для Delphi есть два трейсера исключений с поддержкой отправки отчётов в FogBugz: EurekaLog и madExcept. Конечно, они поддерживают не только FogBugz, но и другие трекеры.

Ну и само собой, трейсеры исключений дадут вам и контекст процессора и стек вызовов.

Источник