Служба Windows Error Reporting (WER) служит для сбора и отправки отладочной информации о падении системных и сторонних приложений в Windows на сервера Microsoft. По задумке Microsoft, эта информация должна анализироваться и при наличии решения, вариант исправления проблемы должен отправляется пользователю через Windows Error Reporting Response. Но по факту мало кто пользуется этим функционалом, хотя Microsoft настойчиво оставляет службу сбора ошибок WER включенной по умолчанию во всех последних версиях Windows. В большинстве случае о службе WER вспоминают, когда каталог C:\ProgramData\Microsoft\Windows\WER\ReportQueue\ начинает занимать много места на системном диске (вплоть до нескольких десятков Гб), даже не смотря на то что на этом каталоге по умолчанию включена NTFS компрессия.
Содержание:
- Служба Windows Error Reporting
- Очистка папки WER\ReportQueue в Windows
- Отключение Window Error Reporting в Windows Server
- Отключаем сбор и отправки отчетов об ошибках в Windows 10
- Отключение Windows Error Reporting через GPO
Служба Windows Error Reporting
Служба Windows Error Reporting при появлении ошибки показывает диалоговое окно, предлагающее отправить отчет об ошибке в корпорацию Microsoft. Когда в Windows вы видите сообщение об ошибке
YourApp has stop working
, в это время в служба Windows Error Reporting запускает утилиту WerFault.exe для сбора отладочных данных (могут включать в себя дамп памяти).
Данные пользователя сохраняются в профиль пользователя:
%USERPROFILE%\AppData\Local\Microsoft\Windows\wer
Системные данные – в системный каталог:
%ALLUSERSPROFILE%\Microsoft\Windows\WER\
Служба Windows Error Reporting представляет собой отдельный сервис Windows. Вы можете проверить состояние службы командой PowerShell:
Get-Service WerSvc
Внутри каталога WER\ReportQueue\ содержится множество каталогов, с именами в формате:
- Critical_6.3.9600.18384_{ID}_00000000_cab_3222bf78
- Critical_powershell.exe_{ID}_cab_271e13c0
- Critical_sqlservr.exe__{ID}_cab_b3a19651
- NonCritical_7.9.9600.18235__{ID}_0bfcb07a
- AppCrash_cmd.exe_{ID}_bda769bf_37d3b403
Как вы видите, имя каталога содержит степень критичности события и имя конкретного exe файла, который завершился аварийно. Во всех каталогах обязательно имеется файл Report.wer, который содержит описание ошибок и несколько файлов с дополнительной информацией.
Очистка папки WER\ReportQueue в Windows
Как правило, размер каждой папки в WER незначителен, но в некоторых случаях для проблемного процесса генерируется дамп памяти, который занимает довольно много места. На скриншоте ниже видно, что размер файла дампа memory.hdmp составляет около 610 Мб. Парочка таким дампов – и на диске исчезло несколько свободных гигибайт.
Чтобы очистить все эти ошибки и журналы штатными средствами, откройте панель управления и перейдите в раздел ControlPanel -> System and Security -> Security and Maintenance -> Maintenance -> View reliability history -> View all problem reports (Control Panel\System and Security\Security and Maintenance\Problem Reports) и нажмите на кнопку Clear all problem reports.
Для быстрого освобождения места на диске от файлов отладки, сгенерированных службой WER, содержимое следующих каталогов можно безболезненно очистить вручную.
- C:\ProgramData\Microsoft\Windows\WER\ReportArchive\
- C:\ProgramData\Microsoft\Windows\WER\ReportQueue\
Следующие команды PowerShell удалят из каталога каталогов WER все файлы, старше 15 дней:
Get-ChildItem -Path 'C:\ProgramData\Microsoft\Windows\WER\ReportArchive' -Recurse | Where-Object CreationTime -lt (Get-Date).AddDays(-15) | Remove-Item -force -Recurse
Get-ChildItem -Path 'C:\ProgramData\Microsoft\Windows\WER\ReportQueue' -Recurse | Where-Object CreationTime -lt (Get-Date).AddDays(-15) | Remove-Item -force –Recurse
Для очистки каталогов WER в пользовательских профилях используйте такой скрипт:
$users = Get-ChildItem c:\users|where{$_.name -notmatch 'Public|default'}
foreach ($user in $users){
Get-ChildItem "C:\Users\$User\AppData\Local\Microsoft\Windows\WER\ " –Recurse -ErrorAction SilentlyContinue | Remove-Item –force –Recurse
}
Отключение Window Error Reporting в Windows Server
В Windows Server 2019/2016/2012R2 вы можете управлять состоянием WER с помощью PowerShell. Вы можете отключить службу Windows Error Reporting:
Get-Service WerSvc| stop-service –passthru -force
Set-Service WerSvc –startuptype manual –passthru
Но есть более корректные способы отключения WER в Windows. В версии PowerShell 4.0 добавлен отдельный модуль WindowsErrorReporting из трех командлетов:
Get-Command -Module WindowsErrorReporting
Проверить состояние службы Windows Error Reporting можно командой:
Get-WindowsErrorReporting
Для отключения WER, выполните:
Disable-WindowsErrorReporting
В Windows Server 2012 R2 можно отключить запись информации об ошибках Windows Error Reporting через панель управления (Control Panel -> System and Security -> Action Center -> раздел Maintenance -> Settings -> выберите опцию I don’t want to participate, and don’t ask me again
Отключаем сбор и отправки отчетов об ошибках в Windows 10
В Windows 10 нельзя отключить Error Reporting через панель управления. В графическогм интерфейсе можно только проверить ее статус (Система и безопасность ->Центр безопасности и обслуживания -> секция Обслуживание). Как вы видите, по умолчанию параметр Поиск решения для указанных в отчетах проблем включен (Control Panel -> System and Security -> Security and Maintenance -> Maintenance -> Report problems = On).
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting нужно создать новый параметр типа DWORD (32 бита) с именем Disabled и значением 1.
Можно отключить сбор ошибок WER для конкретных пользователей:
reg add "HKCU\Software\Microsoft\Windows\Windows Error Reporting" /v "Disabled" /t REG_DWORD /d "1" /f
Или отключить WER для всех:
reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting" /v "Disabled" /t REG_DWORD /d "1" /f
Измените параметр реестра и проверьте статус параметра Поиск решения для указанных в отчетах проблем в панели управления. Его статус должен изменится на Отключено.
Отключение Windows Error Reporting через GPO
Также вы можете управлять настройками службы Windows Error Reporting через групповые политики.
Запустите редактор локальной (
gpedit.msc
) или доменной GPO (
gpmc.msc
) и перейдите в ветку реестра Computer Configuration -> Administrative Templates -> Windows Components -> Windows Error Reporting (Компоненты Windows -> Отчеты об ошибках Windows). Для отключения сбора и отправки ошибок через WER включите политику Disable Windows Error Reporting (Отключить отчеты об ошибках Windows).
Аналогичная политика есть в пользовательском разделе политик (User Configuration).
Обновите GPO (перезагрузка не потребуется).
В результате в Windows перестанут формироваться сообщения об ошибках Windows и отправляться в Microsoft.
***
Что такое Windows Error Reporting
Когда в возникают проблемы с оборудованием или программами (например, аппаратное или программное перестаёт работать или работает некорректно), Windows создает отчёт о проблеме, который предназначен для отправки в Microsoft (чтобы отыскать решение проблемы).
Начиная с операционной системы , на смену «инструменту анализа сбоев или аварий» Dr. Watson пришла Windows Error Reporting (WER) – Служба регистрации ошибок Windows (другие названия – Отчеты о проблемах и их решениях, Отчеты о проблемах и решения).
Служба регистрации ошибок Windows представлена следующими файлами (все расположены в каталоге \Windows\System32\):
– wer.dll (Библиотека сообщений об ошибках Windows);
– wercon.exe (Отчеты о проблемах и их решениях);
– wercplsupport.dll (Отчеты о проблемах и их решениях);
– werdiagcontroller.dll (WER Diagnostic Controller);
– WerFault.exe (Отчет об ошибках Windows);
– WerFaultSecure.exe (Отчеты об ошибках Windows);
– wermgr.exe (Windows Problem Reporting);
– wersvc.dll (Служба регистрации ошибок Windows);
– wertargets.wtl.
Когда происходит сбой какого-либо процесса (программы), служба Windows Error Reporting запускает – в сеансе ошибочного процесса – свою (WerFault.exe),
передавая идентификатор (PID) процесса в командную строку WerFault:
При этом отображается окно Microsoft Windows с сообщением об ошибке – «Прекращена работа <Название_программы>. При следующем подключении к Интернету Windows может провести поиск способа устранения этой ошибки»:
При нажатии на кнопку Показать подробности проблемы можно ознакомиться с сигнатурой проблемы:
Сигнатуры проблем сохраняются в отчётах об ошибках, которые хранятся в каталоге \Users\Master\AppData\Local\Microsoft\Windows\WER\ReportArchive\, каждый отчет – в отдельной папке Report******** (например, Report0a003e48), в файле Report.wer.
Примерное содержимое файла Report.wer:
Version=1
EventType=APPCRASH
EventTime=129234418886148269
ReportType=2
Consent=1
Response.type=4
Sig[0].Name=Имя приложения
Sig[0].Value=iexplore.exe
Sig[1].Name=Версия приложения
Sig[1].Value=8.0.6001.18928
Sig[2].Name=Штамп времени приложения
Sig[2].Value=4bdfa327
Sig[3].Name=Имя модуля с ошибкой
Sig[3].Value=mshtml.dll
Sig[4].Name=Версия модуля с ошибкой
Sig[4].Value=8.0.6001.18928
Sig[5].Name=Штамп времени модуля с ошибкой
Sig[5].Value=4bdfb76d
Sig[6].Name=Код исключения
Sig[6].Value=c0000005
Sig[7].Name=Смещение исключения
Sig[7].Value=000da33f
DynamicSig[1].Name=Версия ОС
DynamicSig[1].Value=6.0.6002.2.2.0.768.3
DynamicSig[2].Name=Код языка
DynamicSig[2].Value=1049
DynamicSig[22].Name=Дополнительные сведения 1
DynamicSig[22].Value=fd00
DynamicSig[23].Name=Дополнительные сведения 2
DynamicSig[23].Value=ea6f5fe8924aaa756324d57f87834160
DynamicSig[24].Name=Дополнительные сведения 3
DynamicSig[24].Value=fd00
DynamicSig[25].Name=Дополнительные сведения 4
DynamicSig[25].Value=ea6f5fe8924aaa756324d57f87834160
UI[2]=C:\Program Files\Internet Explorer\iexplore.exe
UI[3]=Прекращена работа Internet Explorer
UI[4]=Windows может провести поиск способа устранения этой ошибки в Интернете.
UI[5]=Искать решение проблемы в Интернете и закрыть программу
UI[6]=Проверить наличие способа исправления ошибки в Интернете позднее и закрыть программу
UI[7]=Закрыть программу
FriendlyEventName=Остановка работы
ConsentKey=APPCRASH
AppName=Internet Explorer
AppPath=C:\Program Files\Internet Explorer\iexplore.exe
***
Как запустить службу Отчеты о проблемах и их решениях
Нажмите Пуск –> Панель управления –> Отчеты о проблемах и их решениях;
– в окне Отчеты о проблемах и их решениях в меню Задачи доступны следующие опции:
· Искать новые решения (необходимо открытое соединение с Интернетом);
· Показать проверяемые проблемы (прокручиваемый список проблем, для которых требуется найти решение);
· Показать журнал проблем (проблемы, обнаруженные Windows);
· Изменить параметры (выбор способа проверки на наличие решений в случае неполадок – Автоматически выполнять поиск решений или Запрашивать проверку на возможные проблемы);
· Очистить журнал проблем и их решений (очистка журнала проблем для освобождения дискового пространства).
***
Честно говоря, автору статьи ни разу не удалось решить проблемы Windows с помощью Службы регистрации ошибок (да и статус вдохновляет на самостоятельный поиск решений таких проблем!). Значимость этой службы мне видится в том, что она помогает самостоятельно.
Сидоров
***
•
•
•
•
•
•
Модернизация приложений
Механизм Windows Error Reporting
Использование механизма Windows Error Reporting
Примеры использования Windows Error Reporting
В части 5 нашей статьи мы рассказывали о механизме Application Restart and Recovery. Сегодня мы продолжим обсуждение темы обес-печения стабильности приложений и поговорим о механизме Windows Error Reporting.
Механизм Windows Error Reporting
В предыдущих частях мы уже упоминали о механизме Windows Error Reporting (WER), с помощью которого можно собирать данные об ошибках, происходящих в приложениях, и либо отсылать эту информацию на специальный сайт Microsoft (сайт http://winqal.microsoft.com), либо сохранять локально. Сбор детальной информации об ошибках и сбоях помогает в устранении недостатков приложения и коррекции ошибок, упрощает выпуск пакетов обновлений и новых версий приложений, обеспечивает общую стабильность и надежность как самих приложений, так и операционной системы.
Отметим, что компания Microsoft сама активно использует механизм Windows Error Reporting как в процессе разработки, так и после выпуска продуктов на рынок. Так, продуктовая группа Microsoft Office исправила 50% ошибок в Office Service Pack 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 в случае возникновения сбоев, «зависаний» или ошибок уровня ядра операционной системы, выглядит следующим образом:
- Возникновение проблемы.
- Ядро операционной системы вызывает WER.
- WER собирает данные, создает отчет и, при необходимости, запрашивает от пользователя подтверждение на отсылку отчета.
- При получении подтверждения WER отсылает отчет в Microsoft (так называемый Watson Server).
- Если серверу требуются дополнительные данные, WER собирает их и, при необходимости, запрашивает от пользователя подтверждение на отсылку.
- Если приложение зарегистрировано для перезапуска (эту проблему мы обсуждали выше), WER выполняет соответствующую косвенно вызываемую функцию приложения.
- Если существует решение проблемы, приведшей к сбою, пользователь получает уведомление с помощью соответствующих средств операционной системы
- В зависимости от ситуации, в 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.
После того как отчет успешно инициализирован, необходимо добавить в него параметры первой и второй групп. Параметры первой группы задаются с помощью функции WerReportSetParameter(), которой передается ссылка на созданный отчет (результат успешного выполнения функции 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 располагаются в двух ветвях реестра:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting;
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting.
Наиболее полезные настройки показаны в табл. 3.
Примеры использования Windows Error Reporting
В Windows SDK включен ряд примеров применения механизма Windows Error Reporting, которые можно использовать в качестве отправной точки для создания собственных приложений:
- AddDump — применение программных интерфейсов Windows Error Reporting для создания отчета, содержащего файл дампа текущего процесса;
- AddFile — использование программных интерфейсов Windows Error Reporting для создания отчета, содержащего дополнительный файл;
- RegisterFile — применение функции WerRegisterFile() для подключения к отчету дополнительных файлов;
- RegisterMemoryBlock — использование функции WerRegisterMemoryBlock() для включения в состав мини-дампа содержимого блока памяти;
- RuntimeExceptionModule — применение технологии runtime exception, которая появилась в Windows 7 и Windows Server 2008 R2. Модуль, обрабатывающий ошибки во время исполнения, — это внепроцессная библиотека, загружаемая WER при возникновении сбоя. Данная библиотека реализует и экспортирует следующие функции:
- OutOfProcessExceptionEventCallback(),
- OutOfProcessExceptionEventSignatureCallback(),
- OutOfProcessExceptionEventDebuggerLaunchCallback();
- UICustomization — различные возможности настройки пользовательского интерфейса при создании и отсылке отчетов.
КомпьютерПресс 07’2011
Windows Error Reporting (сокращённо: WER) — это набор технологий, встроенных в Windows, который собирает информацию о сбое в приложениях при их вылетах (а также о сбоях ядра) и отправляет её на сервера Microsoft. Разработчик программного обеспечения по этой информации может разработать и опубликовать соответствующее обновление. Затем конечный пользователь, отправляя отчёт, увидит, что для этой ошибки в программе доступно исправление, сможет скачать его и обновить программу.
В этой статье я хотел бы посмотреть на его историю, концепцию и как вы можете использовать его на практике для своих приложений Delphi (или, наоборот, не использовать).
Содержание
- Что происходит при сбое
- История Windows Error Reporting
- 16-битные Windows
- 32-битные Windows
- Windows XP
- Windows Vista и позднее
- Приложение скрытно завершается — что делать?
- Что Delphi делает не так
- Когда приложение Delphi может привести к вызову WER?
- Необработанное исключение в не-RTL потоке
- Повреждение стека/обработчика
- Переполнение стека
- Двойное переполнение стека
- Вызов UnhandledExceptionFilter
- Перенаправление на JIT-отладчик
- Ручной вызов WER
- Настройка Delphi-приложений для отправки отчётов
- Зачем это делать
- Лирическое отступление для тех, кому вообще не нравится концепция отправки отчётов
- Настройка посмертного отладчика
- Использование Threads Snapshot в качестве посмертного отладчика
- Что я могу извлечь из отчёта WER?
- Тип вылета
- Код исключения
- Класс исключения
- Смещение/адрес исключения
- Стек, переменные и другая информация
- Как мне получать отчёты WER?
- Что если я хочу использовать отчёты, но не хочу использовать WER?
- Что если я не хочу изобретать при этом велосипед?
- Дополнительные материалы для чтения
Что происходит при сбое
Сбой в приложении как правило представляет собой исключение, которое может быть или программным (вызываемым явно через raise, т.е. происходящим синхронно) или аппаратным (прерыванием от процессора, т.е. происходящим асинхронно — например, ошибочная попытка доступа к памяти).
Когда происходит исключение, система ищет обработчики в таком порядке:
- Если к программе подключен отладчик, система передаёт управление ему. Отладчик решает: остановить ли программу, продолжить ли её выполнение, или же показать уведомление.
- Если отладчик не подключен, система передаёт управление на блок обработки пользовательского кода (
try/finallyиtry/except). Как правило, такие обработчики либо обрабатывают исключения сами, реализуя логику отката, либо показывают сообщение об ошибке пользователю.
В частности, в Delphi даже если вы явно не написали в своём коде блокtry/except— всё равно RTL Delphi содержит такой блок, который ловит все исключения и показывает сообщение об ошибке (см. также раздел «Что Delphi делает не так» ниже):
- Если пользовательского блока нет, либо они закончились (обработчики могут быть вложены и выполняются по очереди — это называется SEH, Structured Exception Handling, структурированная обработка исключений), система передаёт управление глобальному обработчику необработанных исключений (unhandled exception handler).
Тут надо заметить, что в Delphi приложениях это бывает крайне редко (см. раздел «Что Delphi делает не так» ниже). - Если глобального обработчика нет — программа «вылетает», т.е. система завершает процесс.
- Поскольку сообщение показывается из самого процесса, то в особо запущенных случаях процесс может быть завершён без показа сообщения.
(для простоты я опустил случай подключения отладчика ядра)
16-битные Windows
В далёкие-далёкие времена не было никаких утилит диагностики. Если программа вылетала — она вылетала совсем. В тяжёлых случаях программа могла утянуть с собой всю систему.
К примеру, General Protection Fault (GPF, общее нарушение защиты, Unrecoverable Application Error, UAE) — это прерывание (fault), возникающее в случае попытки приложения получить доступ к не принадлежащей ему области памяти (сегодня известно как исключение Access Violation большинству разработчиков Delphi). При получении этого сигнала от процессора операционная система останавливает выполнение приложения, сообщает пользователю и продолжает выполнение других приложений. Но если в процессе обработки GPF (в обработчике GPF) будет возбуждено ещё одно GPF, процессор отправит сигнал «повторный GPF» (double fault), останавливая уже операционную систему. Если при этом снова произойдёт GPF (triple fault), процессор прекратит работу и его нельзя будет перезапустить (нужен будет перезапуск всего компьютера).
В те времена основным способом исправить ошибку в программе было воспроизведение проблемы под отладчиком.
Первая программа диагностики появилась в бета-версии 16-битной Windows 3.0. Она была создана Доном Корбиттом (Don Corbitt), который раньше работал в Borland и был частью TeamB, но потом ушёл в Microsoft, где и написал Доктора Ватсона (Dr. Watson) — первую утилиту сбора информации о вылете приложения в Windows. Как вы, вероятно, уже предположили, имя «Доктор Ватсон» взято у Доктора Ватсона — персонажа историй Артура Конана Дойля про Шерлока Холмса.
Доктор Ватсон собирал информацию о системе, сбое и состоянии программы («симптомы»). Информация записывалась в отладочный лог-файл, который потом мог быть доставлен разработчикам программы для анализа.
Конечно же, Доктор Ватсон очень понравился разработчикам программ. Мэтт Питрек (автор «Windows Internals» и «Undocumented Windows», тоже, кстати, работал в то время в Borland и тоже входил в TeamB) написал свою собственную версию, изначально называвшуюся «Доктор Франк» («Dr. Frank») — в честь Франка Борленда, основателя Borland. Доктор Франк имел кучу дополнительных возможностей, которые делали его круче Доктора Ватсона. Borland-у понравилась идея утилиты и они включили Доктора Франка в состав Borland C++ 3.1 — к сожалению, переименовав его в WinSpector.
Компилятор Watcom C также стал поставляться со своим собственным аналогом Доктора Ватсона, называвшегося «Доктор Ватком» (Dr. Watcom).
Пример необработанного исключения в Delphi 1, которое было поймано WinSpector:
См. также:
- Как изначально назывался Доктор Ватсон?
- Дополнение к посту Реймонда о Докторе Ватсоне
32-битные Windows
Вплоть до Windows 2000 Доктора Ватсона нужно было запускать вручную до запуска программы, в которой происходил вылет. Доктор Ватсон просто работал в фоне и мог собирать информацию о системе, которая потом сбрасывалась в текстовый отчёт.
В Windows 2000 был предусмотрен новый механизм. С помощью ключа реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug (HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug — для 32-битных программ в 64-битной системе) стало возможным указывать т.н. «посмертный отладчик» (postmortem debugger) или JIT-отладчик (Just-In-Time — «как раз вовремя») — для подключения к процессу при его вылете. Этот ключ реестра — документирован в MSDN и TechNet. Вы могли зарегистрировать Доктора Ватсона в качестве такого отладчика, вызвав:
drwtsn32.exe -i
В результате чего Доктор Ватсон регистрировал сам себя:
После этого при вылете приложения система читала ключ реестра, запускала Доктора Ватсона, он подключался к приостановленному процессу, собирал информацию:
При этом, если параметр Auto ключа реестра AeDebug был равен True (1), то зарегистрированный отладчик запускался сразу, иначе — система выводила обычное сообщение, но с одной дополнительной кнопкой: «Отмена» — для запуска отладчика. Да, вот так коряво была добавлена эта возможность в Windows. Никто не удосужился даже сделать подходящий диалог.
Примечание: строго говоря, ключ реестра AeDebug был ещё в WinNT, а в линейке 9x его функциональность выполнял похожий раздел в Win.ini, тем не менее, ключ -i у Доктора Ватсона впервые появился именно в Windows 2000.
В любом случае, эту информацию можно было затем просмотреть и отправить разработчику программы:
Это был прообраз того, что затем стало службой Windows Error Reporting.
P.S. Разумеется, если у вас был установлен полноценный отладчик, то никто не мешал вам зарегистрировать этот отладчик как посмертный, вместо Доктора Ватсона — что, собственно говоря, и делают Delphi (и Visual Studio). Более того, если в системе зарегистрирован посмертный отладчик, то любое приложение может форсированно его вызвать, сделав вызов системной функции DebugBreak, которая состоит всего из одной ассемблерной команды: $CC — программная (пользовательская) точка останова. Разумеется, если посмертный отладчик не зарегистрирован и программа не отлаживается, то такой код приведёт к обычному вылету приложения.
См. также:
- Вызывая Доктора Ватсона
- Почему Windows Error Reporting называется Доктором Ватсоном?
Windows XP
В Windows XP Доктор Ватсон был существенно расширен и вылизан. Кроме того, он сменил имя на «Problem Reports and Solutions» и представлен dwwin.exe (Microsoft Application Error Reporting) и FaultRep.dll.
Во-первых, в Windows XP Доктор Ватсон зарегистрирован по умолчанию в качестве посмертного отладчика, его не нужно регистрировать вручную (несмотря на то, что Доктор Ватсон зарегистрирован в AeDebug / Debugger как drwtsn32.exe, фактически drwtsn32.exe является переходником к dwwin.exe, который и выполняет всю работу).
Во-вторых, он может быть вызван из программы вручную — через функцию ReportFault.
В-третьих, он добавляет события о вылетах в системный журнал.
Наконец, в-четвёртых, он может быть сконфигурирован из апплета Система Панели Управления:
Как вы можете видеть, тут есть куча опций — выключить, включить частично, полностью, указать исключения или белый список. Достаточно широкий набор опций.
Если вы выключите отчёты полностью (сняв даже галочку с «уведомлять о критических ошибках»), то при вылете приложения система просто завершит процесс, не показав никакого сообщения и даже не сделав отметку в системном журнале. Это полезно, если система работает в основном без присутствия пользователя, либо когда появление дополнительных окон крайне не желательно (например, режим киоска).
Примечание: однако, если вместо этого вы вручную удалите параметр
DebuggerключаAeDebug(в котором и зарегистрирован Доктор Ватсон), то настройки, конечно, будут игнорироваться. Система покажет обычное окно о фатальном сбое в приложении:
Если же вы выключите отчёты, но включите опцию «уведомлять о критических ошибках», то Доктор Ватсон будет показывать отчёты о вылетах приложений:
но не будет показывать отчёты, сгенерированные вручную (через ReportFault). События о вылетах также будут добавлены в системный лог:
Включение же отчётов покажет в диалоге новую опцию: «Отправить отчёт».
при нажатии на которую собранный отчёт отправляется на серверы Microsoft:
а также добавит отдельное событие в системный лог:
Но почему отчёт отправляется Microsoft, а не разработчику программы? Дело в том, что вылет в модуле (exe или DLL) может не быть виной этого модуля. Быть может просто другой модуль неверно нас вызвал. Например, вылет проводника может быть из-за кривого расширения оболочки. Вылет игры может быть обусловлен глюком в видеодрайвере и т.д. Вот почему отчёты отправляются в централизованное хранилище. Там они сортируются и к отчётам допускаются все разработчики, чьи модули (exe или DLL) были упомянуты в отчёте.
Microsoft не использует данные отчётов для каких-либо маркетинговых анализов, анализов частоты ошибок в различных программах т.п. Все данные пользователей защищаются от постороннего доступа и используются только для поиска причины ошибки. Отчёты отправляются по защищённому SSL соединению и хранятся на защищённых серверах, которые не используются ни для каких других целей. Для доступа к отчётам нужно предоставить логин и пароль (задаваемые при регистрации в WinQual). Любой разработчик может видеть только отчёты для своих программ. Все компании, использующие WER, обязуются следовать аналогичным политикам. Разумеется, нет гарантий, что небольшая компания из трёх человек, занимающаяся разработкой shareware-софта, заинтересована в соблюдении вашей конфиденциальности столько, сколько сама Microsoft (хотя она и согласилась следовать соответствующим политикам). Кроме того, по-умолчанию данные отчёта не содержат никаких данных пользователя, кроме тех, которые случайно попадут в дамп. Т.е. персональные данные специально не собираются. В отчёт они могут попасть только случайно. Тем не менее, вы можете посмотреть данные отчёта перед отправкой в случае, если вы работали с важными данными перед вылетом программы.
А зачем вообще нужно отправлять отчёты о вылетах приложения? Дело в том, что в противном случае разработчик увидит только небольшую часть проблем в своём приложении, про большинство проблем он не будет знать (ведь про них не сообщают). Если разработчик не знает про проблему — он её и не исправит.
Кроме того, автоматическая система сбора отчётов может сообщить вам, какая ошибка встречается в вашей программе чаще всего. Иными словами, вы можете сразу же исправить ту ошибку, которая действительно важная, которая мешает жить наибольшему количеству ваших пользователей. Т.е. вы можете исправить одну ошибку вместо сотни других — но эффект будет тот же самый.
В частности, после того как Microsoft реализовала механизм отправки отчётов в Windows XP, она позднее провела широкомасштабный анализ присланных данных, который показал, что 80% пользовательских проблем могут быть решены исправлением 20% наиболее «популярных» ошибок. Даже исправление 1% самых частых ошибок устранит 50% пользовательских проблем!
См. также:
- EDD — Exception Driven Development, Разработка управляемая исключениями
Windows Vista и позднее
Неудивительно, что в Windows Vista служба отправки отчётов из Windows XP была снова обновлена. Она получила новое название Windows Error Reporting (WER) и представлена wermgr.exe и WER.dll.
Для начала, теперь 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 10 вообще нет настроек).
Сами настройки (из реестра) никуда не делись, их всё ещё можно поменять. Просто был убран UI — хотя всегда есть вариант использовать групповые политики.
В реестре эти настройки находятся здесь:
HKCU\Software\Microsoft\Windows\Windows Error ReportingHKLM\Software\Microsoft\Windows\Windows Error Reporting
HKLM\Software\WOW6432Node\Microsoft\Windows\Windows Error Reporting
и официально документированы тут.
Как я уже сказал, самое значительное изменение — появление локального центра сбора отчётов. Отчёты/дампы теперь хранятся локально в %ALLUSERSPROFILE%\Microsoft\Windows\WER\ (например: C:\ProgramData\Microsoft\Windows\WER\; а также они могут быть в %LOCALAPPDATA%\CrashDumps\) и могут быть отправлены в любой момент времени. Их можно просмотреть в так называемом «журнале стабильности работы»:
Жирным отмечены отчёты, которые не были отправлены. Вы можете просмотреть технические сведения по любому отчёту:
отправить любой отчёт или все сразу, а также удалить все отчёты. Опция «Проверить решения» заново отправит сигнатуры всех отчётов (что может быть очень долго!) и сообщит вам, если разработчики программ выпустили какие-либо исправления к этим отчётам.
Замечу, что «журнал стабильности работы» — это отдельный, независимый журнал. Он никак не связан с системным логом «Приложения» (Event Log). События о вылетах добавляются и туда, и туда, но очищать журналы можно индивидуально.
Поскольку WER теперь нельзя отключить удалением ключа AeDebug / Debugger, то записи в системном логе и журнале стабильности работы будут добавляться всегда — даже если служба WerSvc будет отключена (Disabled).
Вариант «Никогда не проверять решения» (Windows Error Reporting / Disabled = 1), как и ожидается, покажет простое сообщение об ошибке — с единственной опцией: закрыть программу.
Следующий вариант «Всегда спрашивать» (Windows Error Reporting / Disabled = 0; Windows Error Reporting / Concent / DefaultConsent = 1) предложит или закрыть программу или отправить отчёт:
Нажатие на кнопку отправки запустит отправку отчёта:
Тут надо заметить, что, на самом деле, в этот момент идёт не отправка непосредственно отчёта, а только проверка, нужно ли его отправлять. Т.е. на сервер отправляются идентификационные данные — т.н. первый уровень (Level One), состоящий из основных параметров, идентифицирующих вылет (имя приложения, модуля, их версии, адрес/смещение, тип вылета, время и т.п.). Если сервер сообщит, что эту проблему ещё никто не встречал, либо если разработчик захотел собрать дополнительные отчёты, то вам будет предложено отправить сам отчёт (это называется «отправка дополнительной информации») — т.н. второй уровень (Level Two), состоящий из детализированного отчёта, включая слепки памяти (минидампы процесса):
Заметьте, что в отличие от Windows XP, в Windows Vista помимо собственно лога прикладывается ещё и дамп процесса (.mdmp), который можно потом загрузить в отладчик Visual Studio или WinDbg, чтобы исследовать проблему.
В противном случае (о сбое уже сообщили, уровень два не отправляется) программа просто завершается (возможно, с финальным диалогом — см. ниже).
Соответственно, при выборе любой из двух «автоматических» опций (DefaultConsent = 2 для «авто-проверять» / «Parameters only»; и = 3 для «и отправлять» / «Parameters and safe data»), начальный вопрос «отправлять» / «закрывать» пропускается, а сразу идёт отправка. Разница между 2 и 3 состоит в том, что при 2 Windows автоматически отправляет только данные «уровня один» — параметры для идентификации отчёта. Все данные «уровня два» (т.е. сам отчёт) при этом отправляются только после явного разрешения пользователя. Вариант 3 же автоматически отправляет и «уровень один» и «уровень два», без запроса разрешения пользователя — но только данные, которые система смогла опознать как, вероятно, не содержащие личную информацию. Для отправки любой другой дополнительной информации Windows всё же спросит разрешения пользователя. На практике эти два положения обычно не отличаются.
Замечу, что DefaultConsent также может принимать значение 4 — автоматически отправлять вообще все данные без запроса пользователя. Это значение нельзя установить через UI в Windows Vista/7, хотя система его прекрасно понимает (т.е. диалог «отправка дополнительной информации» никогда не показывается). Но это значение стоит по умолчанию в последних версиях Windows (например, Windows 10).
Отключение службы WerSvc может повлиять на поведение отчётов. Например, Windows не сможет определить, был ли уже отправлен отчёт и каждый отчёт будет считать новым. Отправка отчётов внешне будет успешна, но, похоже, отчёты просто встают в очередь на отправку.
В некоторых случаях при вылете приложения Windows также может предложить поменять опции на «авто»:
Важно: если вы разрабатываете невизуальное приложение (или если ваше приложение вылетает до показа первого окна), то в случае, если вы установите опцию WER в любую из двух (трёх) «авто» позиций, диалог не будет показан, если в системе уже есть точно такой же вылет и отчёт по нему был отправлен! Иными словами, если (невидимое) приложение вылетело в первый раз — система сделает локальный отчёт и отправит его (автоматически). Диалог будет показан. Если же то же самое приложение вылетает ровно на этом же месте с той же проблемой второй раз — система просто втихую закроет (невидимое) приложение без показа сообщения! Очистка старых отчётов приведёт к тому, что вылет снова будет считаться «новым» и приведёт к показу сообщения об ошибке. Визуальные (оконные) приложения показывают диалог всегда. Вы также можете форсировать диалог для невизуальных приложений сделав вызов
WerSetFlags(WER_FAULT_REPORTING_ALWAYS_SHOW_UI);при старте своего приложения.(И наоборот, если вы сделаете вызов
SetErrorMode(SEM_NOGPFAULTERRORBOX);или (недокументированный)WerSetFlags(WER_FAULT_REPORTING_NO_UI);, то ваше приложение не будет показывать диалог WER, даже если оно визуальное.)
В любом случае, в конечном итоге — если финальный диалог о вылете должен быть показан, то он выглядит так:
Если при этом вы зарегистрировали посмертный отладчик через AeDebug / Debugger, то будет показана дополнительная кнопка отладки:
Это последний диалог, после которого приложение будет закрыто (за исключением случаев, когда приложение самостоятельно инициировало обращение к WER — в этом случае дальнейшие действия определяет приложение).
См. также:
- Как компания может получить доступ к данным Windows Error Reporting?
Приложение скрытно завершается — что делать?
Как должно быть уже понятно, это возможно в следующих случаях:
- Приложение само явно вызвало
TerminateProcessилиExitProcess(прямо или опосредованно — например, черезHalt). - Приложение явно завершило все свои потоки (вышло из процедур потоков или же явно вызвало
TerminateThreadилиExitThread). Это не бывает в Delphi, поскольку компилятор Delphi вставляет неявный вызовHaltв конец главного потока (т.е. всегда вызываетExitProcessв конце работы главного потока), но это может случиться, если внешний процесс уничтожит главный поток в вашей программе. - Какой-то внешний процесс закрыл или уничтожил или ваш процесс или все потоки в нём.
- В вашей программе произошло необработанное (фатальное) исключение, но в Доктор Ватсон / WER отключен диалог об ошибках.
- В вашей программе произошло необработанное (фатальное) исключение, в системе зарегистрирован сторонний посмертный отладчик с автоматическим запуском, который не показал сообщения об ошибке.
- В вашей программе произошло необработанное (фатальное) исключение, которое настолько серьёзно, что система даже не смогла показать сообщение, а посмертный отладчик не зарегистрирован.
Что же в таком случае делать?
В целом нужно попытаться определить, завершилось ли приложение штатно (вызвало Exit/Terminate, либо это сделал кто-то за него), либо же вылетело с необработанным исключением. Подробный список — ниже.
Примечание: в списке ниже ключ реестра Windows Error Reporting\что-то обозначает ключ HKCU\Software\Microsoft\Windows\Windows Error Reporting\что-то, а при его отсутствии — HKLM\Software\Microsoft\Windows\Windows Error Reporting\что-то, либо HKLM\Software\Wow6432Node\Microsoft\Windows\Windows Error Reporting\что-то (для 32-битных приложений на 64-битной машине).
- Попробуйте запустить приложение под отладчиком. Убедитесь, что в отладчике не отключены уведомления об исключениях. Если приложение под отладчиком не вылетает или подключить отладчик нет возможности — см. шаги ниже.
- Первым делом удалите регистрацию посмертного отладчика в ключе реестра
AeDebug, либо хотя бы сбросьте параметрAutoв 0. - [Vista+] Убедитесь, что «Служба регистрации ошибок Windows» («Windows Error Reporting Service»,
WerSvc) не отключена (не находится в состоянии Disabled; по-умолчанию у неё тип запуска — Manual, но для надёжности вы можете её запустить вручную). - Запустите Доктор Ватсон в Windows 2000, настройки отчётов в Windows XP, настройки WER в Windows Vista и позднее — и включите визуальные оповещения (Windows 2000), отчёты об ошибках (Windows XP), запрос согласия, т.е. не включайте автоматическую отправку (Windows Vista и выше).
- [Vista+] Проверьте настройки групповых политик WER. Убедитесь, что UI не отключен, логгинг не отключен, согласие (consent) не установлено в автоматическую отправку без запросов (
DefaultConcent= 1). Не забудьте проверить как политики машины, так и пользователя. - [Vista+] Убедитесь, что ключа реестра
Windows Error Reporting\DebugApplications\*нет или он установлен в 1. - [Vista+] Убедитесь, что ключа реестра
Windows Error Reporting\DontShowUIнет или он установлен в 0. - [Vista+] Убедитесь, что ключа реестра
Windows Error Reporting\LoggingDisabledнет или он установлен в 0. - [Vista+] Очистите все отчёты в журнале стабильности системы.
- Убедитесь, что вы не вызываете
SetErrorModeс одним из следующих флагов:SEM_FAILCRITICALERRORS,SEM_NOGPFAULTERRORBOX,SEM_NOOPENFILEERRORBOX. Для надёжности сделайте вызовSetErrorMode(0);первым действием при запуске своего приложения. - [Win7+] Убедитесь, что вы не вызываете
SetThreadErrorModeс одним из следующих флагов:SEM_FAILCRITICALERRORS,SEM_NOGPFAULTERRORBOX,SEM_NOOPENFILEERRORBOXдля ваших потоков. Для надёжности сделайте вызовSetThreadErrorMode(0);первым действием ваших потоков. - [Vista+] Убедитесь, что ваш код не делает вызов
WerSetFlags(WER_FAULT_REPORTING_NO_UI);. - [Vista+] Сделайте вызов
WerSetFlags(WER_FAULT_REPORTING_ALWAYS_SHOW_UI);первым действием при запуске своего приложения. - Убедитесь, что глобальная переменная
System.JITEnableравна 0. Для надёжности присвойте её 0 первым действием при старте приложения. - Запустите ваше приложение и дайте ему вылететь. Если никакого диалога так и не появилось, то выполните нижеследующие шаги.
- Проверьте, есть ли записи о вылете приложения в системном логе «Приложения».
- Проверьте, нет ли свежих записей в «журнале стабильности системы» или логов в
%APPDATA%\Microsoft\Windows\WER\ReportArchive\/%APPDATA%\CrashDumps\. - Попробуйте назначить свой глобальный обработчик необработанных исключений через системную функцию
SetUnhandledExceptionFilter. - Установите точки останова или хуки (в рамках вашего процесса) на
TerminateProcess,ExitProcess, а если это не помогло — то и наTerminateThreadиExitThread. - Установите точки останова или хуки на системную функцию
kernel32.KiUserExceptionDispatcher— если эта функция будет вызвана непосредственно перед вылетом, то 99% за то, что у вас произошло крайне серьёзное необработанное исключение, при котором система даже не смогла показать сообщение. - Наконец, попробуйте установить глобальный хук (все процессы) на
TerminateProcess,TerminateThread, чтобы узнать, не завершает ли ваш процесс кто-то ещё. - Также попробуйте пересобрать приложение под x86-64 или использовать другую версию Delphi (как более новую, так и более старую).
Вы также можете использовать вспомогательные отладочные инструменты.
Что Delphi делает не так
Концепция обработки ошибок в Delphi была создана в Delphi 1 и существенно не менялась с тех пор. Напомню, что в те времена не было возможности подключения посмертного отладчика, сбора информации о сбое и автоматической отправки отчёта. Поэтому если приложение вылетало — оно вылетало с концами.
Поэтому Delphi исторически реализует концепцию «ни за что не вылетать». Делает это она путём расстановки блоков try/except везде, где только возможно. В частности, в оконных приложениях VCL обработка каждого сообщения заключена в явный блок try/except с вызовом Application.HandleException для обработки каждого необработанного (unhandled) исключения:
procedure TWinControl.MainWndProc(var Message: TMessage);
begin
try
try
WindowProc(Message);
finally
FreeDeviceContexts;
FreeMemoryContexts;
end;
except
Application.HandleException(Self);
end;
end;
Application.HandleException просто показывает сообщение (.Message) исключения (в новых версиях Delphi — вместе с вложенными):
После чего приложение продолжает обычную работу (цикл выборки сообщений).
Если VCL (или аналогичный фреймворк) не используется, либо если исключение происходит вне цикла выборки сообщений, то управление получает глобальный обработчик исключений RTL System._ExceptionHandler, который вызывает пользовательский обработчик из System.ExceptProc:
var ExceptProc: procedure(ExceptObject: TObject; ExceptAddr: Pointer); // Unhandled exception handler
В 99% случаев этот обработчик установлен в SysUtils.ExceptHandler, который показывает сообщение через SysUtils.ShowException, а затем завершает работу приложения с кодом возврата равным 1:
procedure ExceptHandler(ExceptObject: TObject; ExceptAddr: Pointer); begin ShowException(ExceptObject, ExceptAddr); Halt(1); end;
SysUtils.ShowException показывает упрощённо-техническое сообщение:
Если же модуль SysUtils не подключен, либо исключение возникло до инициализации модуля SysUtils, то System.ExceptProc будет не назначен (равен nil), так что System._ExceptionHandler попытается обработать сообщение самостоятельно. Поскольку объект исключения определяется в том же модуле SysUtils, модуль System не может оперировать объектом исключения. Вместо этого он завершит приложение с «кодом ошибки» 217 (необработанное исключение) — через System._RunError:
procedure _RunError(errorCode: Byte); begin ErrorAddr := ReturnAddress; Halt(errorCode); end;
Что приведёт к завершению приложения. При этом System.Halt увидит, что установлен код ошибки, поэтому он сообщит об этом:
procedure _Halt0;
begin
// ...
if ErrorAddr <> nil then
begin
MakeErrorMessage;
WriteErrorMessage;
ErrorAddr := nil;
end;
// ...
ExitProcess(ExitCode);
end;
Примечание: код 217, на самом деле, означает закрытие консольного приложения через Ctrl + Break. По совместительству он же используется для указания необработанного исключения. Также код может быть 230 — настоящий код для необработанных исключений, используется на не-Windows платформах. 204 — код для Invalid Pointer, вызывается менеджером памяти, если передать ему неверный указатель (например, указатель на уже удалённую память). А также частый код 216 — если необработанное исключения является аппаратным Access Violation. Для других аппаратных исключений также есть свои собственные коды, но на практике в 99% случаев вы увидите только 216, 217 или 204.
Если ваш код будет создавать дополнительные фоновые потоки через BeginThread (а равно и через любые обёртки к нему, например, TThread или многопоточный фреймворк), то RTL также оборачивает функцию потока в try/except блок с вызовом System._ExceptionHandler. А TThread и вовсе оборачивает .Execute в явный try/except блок с сохранением необработанного исключения в свойство .FatalException, таким образом полностью гася его обработку и оставляя её на ваше усмотрение.
Иными словами (почти) любой код Delphi оказывается обёрнут в обработчик RTL, все исключения обрабатываются либо вашим кодом, либо RTL, поэтому настоящих необработанных исключений в Delphi не бывает.
В те времена (Windows 3.x) это считалось несомненным плюсом — и таковым и преподносилось в рекламе Borland: «посмотрите, как надёжны наши приложения — они не вылетают». А если вылетают — показывают что-то более удобоваримое, чем просто GPF.
В современном мире повсеместного распространения интернета это оказывается уже не так здорово, как казалось когда то. Если ваше приложение не вылетает — оно не вызывает WER. Не вызывает WER — не отправляет отчёт. Не отправляет отчёт — вы не получаете отчёт. Результат? Вы или вообще не в курсе, что с вашим приложением что-то не так, либо получаете письмо от пользователя «программа не работает». Разве не было бы лучше немедленно узнавать о вылетах вашего приложения? Получать чёткие отчёты вида «проблема в строке 42»? Сортировать отчёты по частоте возникновения, чтобы видеть самые «горячие» проблемы?
Поэтому указанное поведение Delphi — зло, от которого нужно избавляться. Мы посмотрим на это чуть позже.
Когда приложение Delphi может привести к вызову WER?
А пока — посмотрим на то, как приложение Delphi может вызывать WER, даже хотя оно почти полностью завёрнуто в обработчики исключений, и необработанным исключениям возникнуть, вроде бы, неоткуда.
Необработанное исключение в не-RTL потоке
Для начала, самый простой случай — код в потоке, создаваемом системной функцией CreateThread, по очевидным причинам не будет иметь обработчика исключений RTL (в отличие от RTL-функции BeginThread).
function CrashMe(Arg: Pointer): Integer; stdcall;
begin
raise Exception.Create('Apocalypse');
Result := 0;
end;
...
TH := CreateThread(nil, 0, @CrashMe, nil, 0, TID);
или
function CrashMe(Arg: Pointer): Integer; stdcall; var P: Pointer; begin P := nil; P^ := 0; Result := 0; end; ... TH := CreateThread(nil, 0, @CrashMe, nil, 0, TID);
Оба эти примера кода приведут к вылету приложения: будет вызван WER, создан/отправлен отчёт о вылете, приложение будет закрыто.
P.S. Кстати, этот метод — простейший способ заставить работать Restart & Recovery для приложений-служб. Просто реализуйте логику службы в потоках, создаваемых через CreateThread в OnStart. Не используйте OnExecute.
Повреждение стека/обработчика
Случай посложнее. Иногда система просто не может вызвать обработчики исключений: и тогда единственное, что она может сделать — вызвать глобальный обработчик (WER).
Например:
procedure TForm1.Button1Click(Sender: TObject);
var
S: array [0..1] of Integer;
I: Integer;
begin
I := -6; // пусть мы ошиблись в вычислении индекса I
try
S[I] := 1; // вместо записи в массив мы стираем обработчик исключений, установленный try
S[I + 1] := 2;
S[I + 2] := 3;
Abort; // <- полный вылет программы, т.к. система не смогла найти обработчик
except
ShowMessage('Aborted');
end;
end;
Ошибки переполнения буфера могут привести к перезаписи важных адресов на стеке потока. В результате блоки try будут испорчены. И если в этот момент произойдёт исключение, система увидит на стеке мусор вместо указателя на блок except. Обработчик вызвать не удастся, так что будет вызван только WER.
Пример с перезаписью стека справедлив только для x86-32, т.к. на x86-64 стек не используется для блоков try (вместо этого используются табличные исключения, где все блоки try зарегистрированы в отдельной таблице, не хранящейся в стеке).
Переполнение стека
Тем не менее, можно привести и аналогичные примеры. Например:
procedure P; begin P; end; procedure TForm1.Button1Click(Sender: TObject); begin P; end;
Этот код вызывает просто переполнение стека (stack overflow). Часто — это обычное исключение, которое будет поймано ближайшим обработчиком и обработано. В данном случае — будет показано сообщение через Application.HandleException. Тем не менее, для обработки исключения тоже нужно свободное место на стеке. И если обработчик займёт слишком много места на стеке — получится исключение внутри обработчика исключения. Новое исключение будет передано выше, пока не дойдёт до самого верхнего уровня, где и будет обработано WER.
К примеру, сообщение о переполнении стека с высокой долей вероятности будет успешно показано из приложения Delphi 7 на Windows XP, поскольку обработчик представляет собой простой MessageBox(E.Message). Но в комбинации Delphi 10.1 Berlin на Windows 10 — приложение, вероятнее всего, вылетит в WER, поскольку там и обработчик немного сложнее и MessageBox устроен сложнее.
Двойное переполнение стека
Но даже если мы сведём обработчик к тривиальному:
procedure P;
begin
P;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
try
P;
except // <- тривиальный (пустой) обработчик
end;
end;
который, очевидно, всегда будет выполняться успешно, т.к. не занимает места на стеке. Даже если мы возьмём наименьшую версию Delphi и Windows — всё равно приложение может вылететь.
Да, первое нажатие на кнопку возбудит исключение stack overflow, которое успешно будет обработано (пустым) обработчиком исключений. Но вспомните, что исключение stack overflow возбуждается только когда стек дорастает до защитной страницы, после доступа к которой защита снимается и возбуждается первое исключение (stack overflow). Если затем стек растёт и далее — то никакой защитной страницы уже нет, запись в стек наткнётся на зарезервированную страницу без доступа. Иными словами, если нажать кнопку второй раз — исключения stack overflow уже не будет. Будет фатальное Access Violation, будет вызван WER.
Вызов UnhandledExceptionFilter
Далее, поведение программы зависит и от версии Delphi. Указанная выше (в предыдущем разделе) логика с безусловным вызовом System.ExceptProc из System._ExceptionHandler справедлива лишь для старых версий Delphi. Относительно новые версии Delphi ведут себя так только при запуске под отладчиком. Если же программа запущена вне отладчика, то System._ExceptionHandler сначала вызовет системный UnhandledExceptionFilter — и вызовет System.ExceptProc только лишь если он вернул EXCEPTION_EXECUTE_HANDLER. Если же UnhandledExceptionFilter вернул EXCEPTION_CONTINUE_SEARCH, то System._ExceptionHandler не будет обрабатывать исключение и передаст его выше (т.е. исключение будет необработанным и его перехватит ОС, где в дело вступит WER). Если никто специально UnhandledExceptionFilter не назначал (Delphi его не назначает), то за его поведение отвечает WER, т.е. поведение зависит от ОС и настроек WER. К примеру, обработчик может ничего не делать и вернуть EXCEPTION_CONTINUE_SEARCH — и тогда исключение будет поднято выше, и вы увидите только диалог WER, но не run-time error. Часто обработчик сам обработает исключение (покажет диалог WER) и вернёт EXCEPTION_EXECUTE_HANDLER. И тогда вы увидите и диалог WER, и диалог run-time error. Воистину странное сочетание для пользователя!
Замечу, что это поведение (консультация с UnhandledExceptionFilter из System._ExceptionHandler) есть только под Windows, только при запуске вне отладчика, только при обработке исключения модулем System (т.е. не влияет на TThread и VCL), и почти, но не во всех версиях Delphi (правда, появилось оно очень давно).
Т.е. предполагается, что если вы запустили программу вне отладчика, она вылетела, то это поведение позволит вам подключить отладчик Delphi для диагностики проблемы (напомню, многие среды разработки, и Delphi в их числе, регистрируют свои отладчики в качестве посмертных через ключ реестра AeDebug). Именно поэтому эта опция ничего не делает, если вы уже отлаживаете свою программу: в конце концов, задача опции — подключить отладчик, а если вы уже отлаживаетесь, то подключать ничего не надо.
Перенаправление на JIT-отладчик
Далее, начиная с Delphi 5 в модуле System появляется новая глобальная переменная:
var
JITEnable: Byte = 0; { 1 to call UnhandledExceptionFilter if the exception is not a Pascal exception.
>1 to call UnhandledExceptionFilter for all exceptions }
по-умолчанию она равна 0 и означает, что все обработчики исключений работают как обычно. Если эта переменная отлична от нуля, то блоки except не будут вызываться если, во-первых, программа не отлаживается, во-вторых, исключение — аппаратное (для System.JITEnable = 1) или произвольное (System.JITEnable = 2). Переменная System.JITEnable не изменяется кодом RTL/VCL и предназначена для изменения вами.
Иными словами, эта настройка ничего не делает, если программа запущена под отладчиком. В этом случае программа будет работать как обычно, все блоки except будут выполняться, все обработчики будут запускаться. Но если программа запущена без отладчика, то эта опция позволяет выбрать как/чем обрабатывать исключения — встроенными обработчиками или отдавать исключения наружу. 1, соответственно, отдаёт наружу только аппаратные исключения (типа Access Violation), 2 — любые.
Ну, а когда вышла Windows XP (а затем — и Vista), ровно эта же переменная (System.JITEnable) позволила вызывать WER и инициировать, таким образом, отправку отчётов.
Т.е.
procedure TForm1.Button1Click(Sender: TObject); var P: PInteger; begin JITEnable := 1; P := nil; P^ := 0; // <- вызовет WER (вне отладчика) end;
procedure TForm1.Button1Click(Sender: TObject);
begin
JITEnable := 1;
raise Exception.Create('Error Message'); // <- запустит обработчик исключений VCL
// Application.HandleException, что
// покажет сообщений "Error Message"
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
JITEnable := 2;
raise Exception.Create('Error Message'); // <- вызовет WER (вне отладчика)
end;
procedure TForm1.Button1Click(Sender: TObject);
var
P: PInteger;
begin
JITEnable := 1;
try
P := nil;
P^ := 0; // <- вызовет WER (вне отладчика)
except
MessageBox(0, 'Error!', 'Caption', MB_OK); // <- не будет выполнен (вне отладчика)
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
P: PInteger;
begin
JITEnable := 1;
try
P := AllocMem(1024);
try
P := nil;
P^ := 0; // <- вызовет WER (вне отладчика)
finally
FreeMem(P); // <- не будет выполнен (вне отладчика)
end;
except
MessageBox(0, 'Error!', 'Caption', MB_OK); // <- не будет выполнен (вне отладчика)
end;
end;
Очевидно, что переменная System.JITEnable не предназначена для использования в production-версии вашего кода. По крайней мере, при значении 2 — точно. Ведь в вашем коде написаны какие-то обработчики исключений, стоят блоки try/except, ваш код предполагает, что обработчики будут выполняться, ведь они выполняют какую-то работу по откату. Но если вы включаете опцию System.JITEnable, то ни один из ваших обработчиков не будет вызван.
System.JITEnable предназначена для отладки ваших приложений. Если в вашем приложении происходит исключение/вылет, которое вы не можете поймать под отладчиком (происходит только при запуске вне отладчика), то вы можете включить System.JITEnable и запустить вашу программу вне отладчика. Пусть она вылетит, вы подключите к программе посмертный отладчик (отладчик Delphi, конечно же) и исследуете проблему на месте.
Замечу, что даже если System.JITEnable отлична от нуля, то это просто передаст исключение «наверх», т.е. UnhandledExceptionFilter будет вызываться. И если вы (или кто-то ещё) назначит обработчик UnhandledExceptionFilter (через SetUnhandledExceptionFilter) и он будет возвращать EXCEPTION_EXECUTE_HANDLER (для всех или только избранных исключений), то соответствующие блоки except всё же будут выполняться. Таким образом, вы всегда можете сделать тонкую настройку, выполнять обработку только избранных исключений. И в таком виде System.JITEnable вполне имеет право на жизнь и в production-коде.
Ручной вызов WER
В конце концов, ваш код может просто вызвать WER вручную — через его API. Примеры вызова мы посмотрим ниже.
Настройка Delphi-приложений для отправки отчётов
Зачем это делать
Итак, как уже должно быть понятно, отправка отчётов при вылете приложения — есть хорошо, т.к. позволяет разработчикам программ узнавать о вылетах и проблемах в приложениях без участия пользователя, даёт точные технические описания и позволяет делать сортировку/статистику.
Кроме того, вызов системного обработчика ошибок (будь это WER или что-то ещё) — необходимое условие в некоторых отдельных случаях. Например, при сертификации своей программы для Windows, для реакции системных сервисов перезапуска (Restart & Recovery, в т.ч. в службах).
Поэтому с концепцией Delphi «ни за что не вылетать» нужно срочно что-то делать.
Лирическое отступление для тех, кому вообще не нравится концепция отправки отчётов
Если по каким-либо причинам вы не хотите отправлять отчёты и хотите всегда показывать своё сообщение пользователю:
- Не используйте
CreateThread. Всегда используйтеBeginThread.- Не изменяйте
System.JITEnable.- Установите:
function ExecuteRTLHandlers(const Exception: TExceptionPointers): Integer; stdcall; const EXCEPTION_EXECUTE_HANDLER = 1; begin Result := EXCEPTION_EXECUTE_HANDLER; end; initialization SetUnhandledExceptionFilter(@ExecuteRTLHandlers); end.и/или:
- Заключайте каждую функцию потока, созданного
CreateThread/BeginThread/QueueUserWorkItem(и аналогичными функциями), в явный блокtry/except.- Заключайте в блоки
try/exceptкаждую секциюinitialization, каждую секциюfinalizationи блокbegin/end.dpr проекта.В блоке
exceptвы можете вызыватьSysUtils.ShowExceptionили свой собственный код.- Вызовите
SetErrorMode(SEM_NOGPFAULTERRORBOX);при старте процесса (опционально можно добавить и другие флаги). См. также.- Обработайте терминальное исключение главного потока:
uses SysUtils; // ... procedure CatchException; begin if ExceptObject = nil then Exit; ShowException(ExceptObject, ExceptAddr); TerminateProcess(GetCurrentProcess, 216); end; initialization // ... finalization CatchException; end.или:
Заключайте в блокиtry/exceptкаждую секциюinitialization, каждую секциюfinalizationи блокbegin/end.dpr проекта. В блокеexceptвы можете вызыватьSysUtils.ShowExceptionили свой собственный код.- Опционально: замените все обработчики исключений на свои. Убедитесь, что вы дополнительно показываете в сообщении/диалоге: имя модуля, его версию и смещение исключения внутри этого модуля (см. ниже).
Примечание: а если вы принципиально не против идеи отчётов, но не хотите использовать WER, то — см. ниже.
Для всех же нормальных разработчиков — давайте посмотрим, что мы можем сделать.
Во-первых, в первом приближении очень хорошо сработала бы такая комбинация:
function WERPassThrough(const Exception: TExceptionPointers): Integer; stdcall;
function IsUnhandledExceptionCode(const AExceptionCode: DWORD): Boolean;
begin
Result := (AExceptionCode = EXCEPTION_ACCESS_VIOLATION) or
(AExceptionCode = EXCEPTION_PRIV_INSTRUCTION) or
(AExceptionCode = EXCEPTION_ILLEGAL_INSTRUCTION) or
(AExceptionCode = EXCEPTION_NONCONTINUABLE_EXCEPTION) or
(AExceptionCode = EXCEPTION_DATATYPE_MISALIGNMENT) or
(AExceptionCode = EXCEPTION_BREAKPOINT) or
(AExceptionCode = EXCEPTION_SINGLE_STEP) or
(AExceptionCode = EXCEPTION_INVALID_HANDLE);
end;
const
EXCEPTION_CONTINUE_SEARCH = 0;
EXCEPTION_EXECUTE_HANDLER = 1;
begin
if IsUnhandledExceptionCode(Exception.ExceptionRecord.ExceptionCode) then
Result := EXCEPTION_CONTINUE_SEARCH
else
Result := EXCEPTION_EXECUTE_HANDLER;
end;
initialization
JITEnable := 1;
SetUnhandledExceptionFilter(@WERPassThrough);
end.
В данном случае мы вызываем WER для всех перечисленных кодов аппаратных исключений и RTL обработчики — для всего остального. Список, конечно, приведён как пример, и его нужно изменить под ваше приложение. Например, если вы делаете определение запуска виртуальной машины через выполнение секретной инструкции, то код EXCEPTION_PRIV_INSTRUCTION (и, возможно, EXCEPTION_ILLEGAL_INSTRUCTION) нужно убрать. Если вы проверяете аргументы выражений, то коды числовых исключений (деление на ноль, переполнение и т.п.) хорошо бы добавить. В тривиальном случае можно также считать что любое аппаратное исключение нужно передать WER. В сложном случае — фильтровать не только аппаратные, но и программные исключения (установив JITEnable в 2).
Но это решение — половинчатое. Ведь нам хотелось бы вызывать WER для всех необработанных исключений, вне зависимости от их типа, и не вызывать для всех остальных (опять же, вне зависимости от типа). Поэтому решение с JITEnable стоит отложить.
К сожалению, в Delphi не предусмотрено никакой возможности отменить только «глобальные» блоки try/except, нет никакого аналога опции JITEnable. Вместо этого нам придётся назначить свой обработчик и вызывать WER вручную — через API. Сама Microsoft такой подход считает допустимым, но не рекомендованным. Рекомендованный — конечно же, просто не ловить исключения, которые вы не знаете как обрабатывать.
Итак, для начала нам нужна функция, которую мы будем вызывать для необработанных исключений:
const
cDelphiException = $0EEDFADE; // копия из SysUtils
type
PtrUInt = {$IFDEF UNICODE}NativeUInt{$ELSE}Cardinal{$ENDIF};
var
ReportFault: function(const pep: TExceptionPointers; dwOpt: DWORD): Cardinal; stdcall;
resourcestring
// Копия из SysConst с заменой %s (класс исключения) на %8.8x (код)
SException = 'Exception %8.8x in module %s at %p.' + sLineBreak + '%s%s' + sLineBreak;
procedure UnhandledExceptionHandler(EP: TExceptionPointers; const AErrorCode: Cardinal = 0); overload;
// Копия ShowException из SysUtils с заменой ExceptObject: TObject на Code: Cardinal
procedure ShowExceptionRecord(const ACode: Cardinal; const AAddr: Pointer);
function ExceptionErrorMessage(ExceptCode: Cardinal; ExceptAddr: Pointer; Buffer: PChar; Size: Integer): Integer;
function ConvertAddr(Address: Pointer): Pointer; assembler;
asm
TEST EAX,EAX
JE @@1
SUB EAX, $1000
@@1:
end;
var
MsgPtr: PChar;
MsgEnd: PChar;
MsgLen: Integer;
ModuleName: array[0..MAX_PATH] of Char;
Temp: array[0..MAX_PATH] of Char;
Format: array[0..255] of Char;
Info: TMemoryBasicInformation;
ConvertedAddress: Pointer;
begin
VirtualQuery(ExceptAddr, Info, sizeof(Info));
if (Info.State <> MEM_COMMIT) or
(GetModuleFilename(THandle(Info.AllocationBase), Temp, Length(Temp)) = 0) then
begin
GetModuleFileName(HInstance, Temp, Length(Temp));
ConvertedAddress := ConvertAddr(ExceptAddr);
end
else
PtrUInt(ConvertedAddress) := PtrUInt(ExceptAddr) - PtrUInt(Info.AllocationBase);
StrLCopy(ModuleName, AnsiStrRScan(Temp, '\') + 1, Length(ModuleName) - 1);
MsgPtr := '';
MsgEnd := '';
if ExceptObject is Exception then
begin
MsgPtr := PChar(Exception(ExceptObject).Message);
MsgLen := StrLen(MsgPtr);
if (MsgLen <> 0) and (MsgPtr[MsgLen - 1] <> '.') then MsgEnd := '.';
end;
LoadString(FindResourceHInstance(HInstance), PResStringRec(@SException).Identifier, Format, Length(Format));
StrLFmt(Buffer, Size, Format, [ExceptCode, ModuleName, ConvertedAddress, MsgPtr, MsgEnd]);
Result := StrLen(Buffer);
end;
var
Title: array[0..63] of Char;
Buffer: array[0..1023] of Char;
OemBuffer: array of AnsiChar;
BufSize, OemBufSize: Integer;
Dummy: Cardinal;
begin
BufSize := ExceptionErrorMessage(ACode, AAddr, Buffer, Length(Buffer));
if IsConsole then
begin
Flush(Output);
OemBufSize := WideCharToMultiByte(CP_OEMCP, 0, Buffer, BufSize, nil, 0, nil, nil);
SetLength(OemBuffer, OemBufSize);
WideCharToMultiByte(CP_OEMCP, 0, Buffer, BufSize, @OemBuffer[0], OemBufSize, nil, nil);
WriteFile(GetStdHandle(STD_ERROR_HANDLE), OemBuffer[0], OemBufSize, Dummy, nil);
WriteFile(GetStdHandle(STD_ERROR_HANDLE), sLineBreak, 2, Dummy, nil);
end
else
begin
LoadString(FindResourceHInstance(HInstance), PResStringRec(@SExceptTitle).Identifier, Title, Length(Title));
MessageBox(0, Buffer, Title, MB_OK or MB_ICONSTOP or MB_TASKMODAL);
end;
end;
// Далее идёт уже наш код
const
// Возможные коды ошибок для WER API:
frrvOk = 0; // The function succeeded.
frrvOkManifest = 1; // The function succeeded and the error reporting client was launched in manifest reporting mode.
frrvOkQueued = 2; // The function succeeded and the fault report was queued for later reporting.
frrvErr = 3; // The function failed but the error reporting client was launched.
frrvErrNoDW = 4; // The error reporting client was unable to launch. The system will perform its default actions, such as displaying the standard exception dialog box and launching the debugger.
frrvErrTimeout = 5; // The function timed out.
frrvLaunchDebugger = 6; // The function succeeded and the user launched the debugger.
frrvOkHeadless = 7; // The function succeeded and the error reporting client was launched in silent reporting mode (no UI is used).
frrvCancelled = 15; // Не документирован
var
WERResult: Cardinal;
ErrorCode: Cardinal;
EO: TObject;
EA: Pointer;
MBI: TMemoryBasicInformation;
begin
// Сначала определим код, с которым завершится наше приложение
if AErrorCode <> 0 then
ErrorCode := AErrorCode
else
ErrorCode := EP.ExceptionRecord.ExceptionCode;
// Для программных исключений адрес возбуждения = адресу Kernel32.RaiseException
// Это довольно бесполезно для диагностики
// Поэтому мы подменяем адрес возбуждения на "настоящий"
// В случае Delphi исключений он сохранён в параметрах исключения
if EP.ExceptionRecord.ExceptionCode = cDelphiException then
EP.ExceptionRecord.ExceptionAddress := SysUtils.PExceptionRecord(EP.ExceptionRecord).ExceptAddr;
// Вызываем WER
if Assigned(ReportFault) then
begin
// В этом месте появится обычное окно WER "В программе - ошибка, идёт поиск решения"
WERResult := ReportFault(EP, 0);
case WERResult of
frrvOk, frrvOkManifest, frrvOkQueued, frrvOkHeadless:
// Успех
TerminateProcess(GetCurrentProcess, ErrorCode);
frrvLaunchDebugger:
begin
// Нужно запустить отладчик из ключа реестра AeDebug
// Оставляю это в качестве домашнего задания,
// чтобы не засорять пример
end;
frrvCancelled:
TerminateProcess(GetCurrentProcess, ErrorCode);
else begin end; // ошибки frrvErr*, в том числе - frrvErrNoDW, если WER отключен
end;
end;
// Если WER нет или произошла ошибка - покажем обычное сообщение средствами SysUtils
// Для этого нам нужен объект исключения на руках
// Для Delphi исключений объект уже есть - извлекаем его
EO := nil;
if EP.ExceptionRecord.ExceptionCode = cDelphiException then
begin
EO := TObject(SysUtils.PExceptionRecord(EP.ExceptionRecord).ExceptObject);
EA := SysUtils.PExceptionRecord(EP.ExceptionRecord).ExceptAddr;
end;
// На всякий случай проверим объект:
// размещён ли он в доступной странице памяти.
// Менеджер памяти Delphi может уже завершить работу к этому моменту.
if (EO = nil) or
(VirtualQuery(EO, MBI, SizeOf(MBI)) = 0) or
(MBI.State <> MEM_COMMIT) then
EO := nil;
// Для аппаратных исключений объекта нет, либо объект был уже удалён - покажем своё сообщение
if EO = nil then
ShowExceptionRecord(EP.ExceptionRecord.ExceptionCode, EP.ExceptionRecord.ExceptionAddress)
else
ShowException(EO, EA);
// Завершим приложение в любом случае - с выбранным кодом ошибки
TerminateProcess(GetCurrentProcess, ErrorCode);
end;
procedure UnhandledExceptionHandler(const E: Exception); overload;
var
EP: TExceptionPointers;
ER: System.TExceptionRecord;
ErrorCode: Cardinal;
begin
// API требует ExceptionPointers - это пара ExceptionRecord и Context.
// Для внешнего исключения ExceptionRecord уже есть
if E is EExternal then
EP.ExceptionRecord := Windows.PExceptionRecord(EExternal(E).ExceptionRecord)
else
// Для Delphi-исключения ExceptionRecord не хранится, мы его конструируем заново
begin
FillChar(ER, SizeOf(ER), 0);
ER.ExceptionCode := cDelphiException;
ER.ExceptionAddress := ExceptAddr;
ER.NumberParameters := 2;
ER.ExceptAddr := ExceptAddr;
ER.ExceptObject := Pointer(E);
EP.ExceptionRecord := Windows.PExceptionRecord(@ER);
end;
// К сожалению, контекст процессора взять негде
EP.ContextRecord := nil;
// Определяем код ошибки для завершения процесса
// В основном этот кусок нужен ради EOSError.ErrorCode
// При желании сюда же можно добавить EDatabaseError и EOleSysError/EOleException
if E is EOSError then
ErrorCode := EOSError(E).ErrorCode
else
ErrorCode := 0;
UnhandledExceptionHandler(EP, ErrorCode);
end;
procedure InitWER;
var
LibFaultrep: HMODULE;
begin
// Получаем точку входа в API - доступна с WinXP
LibFaultrep := LoadLibrary('faultrep.dll'); // Do Not Localize
if LibFaultrep <> 0 then
ReportFault := GetProcAddress(LibFaultrep, 'ReportFault'); // Do Not Localize
end;
Как видите, тут ужасно много всего.
Центральным местом тут является всего одна функция — ReportFault, которую и нужно нам вызвать. Проблема в том, что на вход функция просит пару ExceptionRecord и Context — это низкоуровневые понятия, которые недоступны из обычного блока except в Delphi. Поэтому большая часть кода посвящена преобразованию между этими двумя понятиями. К сожалению, весьма важный кусок информации — контекст процессора, не доступен. Чтобы его получить, нам придётся прибегнуть к нетривиальным ловушкам, рассмотрение которых выходит за рамки этой статьи.
Очень важно, что этот код должен работать без выделения памяти (в куче). Во-первых, нам не известно состояние менеджера памяти в момент вызова нашего обработчика. Может быть, обработчик был вызван как раз потому, что произошло исключение в менеджере памяти. И что тогда? Снова выделять память? Во-вторых, менеджер памяти может быть уже финализирован к моменту вызова вашего обработчика. Например, если исключение возникло в секции initialization модуля, то сначала сработает блок except процедуры InitUnits модуля System, который завершит модули (и менеджер памяти — в том числе), а затем уже вызовет UnhandledExceptionFilter (и, следовательно — наш обработчик). Выделение памяти у уже отработавшего менеджера памяти, опять же, ничем хорошим не закончится.
Именно по этой причине вызов GetProcAddress вынесен из кода UnhandledExceptionHandler — он выделяет память (см. реализацию GetProcAddress в модуле Windows).
Подсказка: если вы всё же хотите выделать память в своём обработчике — попробуйте установить альтернативный менеджер памяти. Для простоты это может быть переходник к HeapAlloc или VirtualAlloc.
(Это я ещё не про все подводные камни рассказал. Да, как видите, глобальная обработка исключений — не самое простое дело.)
Если вызов WER был неудачен (например, WER отключен), либо WER вообще отсутствует (Windows 2000 и ранее), то мы пытаемся показать сообщение как оно показывалось бы ранее — методом ShowException модуля SysUtils. Проблема опять же в том, что делать, если на руках нет объекта исключения Delphi, который можно было бы показать. Напомню, что в этом случае модуль System показывает run-time ошибку (обычно — 217, 216 или 204, как мы обсуждали это выше) — что, на мой взгляд, достаточно бесполезно. Поэтому вместо этого я предлагаю показывать код исключения — что и делает функция ShowExceptionRecord, которая является слегка видоизменённой ShowException.
Данный пример использует API уровня Windows XP (хотя будет работать в любой ОС), но вы также можете расширить этот пример на уровень Vista, чтобы полностью настроить поведение WER. В Vista вы можете изменять части диалога, добавлять в отчёт информацию и файлы и многое другое.
Итак, имея на руках функцию UnhandledExceptionHandler, мы можем назначить её в качестве глобального обработчика исключений:
type
TDummyObject = class(TObject)
private
class procedure WERPassThrough(Sender: TObject; E: Exception);
end;
class procedure TDummyObject.WERPassThrough(Sender: TObject; E: Exception);
begin
UnhandledExceptionHandler(E);
end;
// Опционально:
function WERPassThrough(const E: TExceptionPointers): Integer; stdcall;
begin
UnhandledExceptionHandler(E);
Result := 0;
end;
// Опционально
procedure SetWERVisible;
const
WER_FAULT_REPORTING_ALWAYS_SHOW_UI = 16;
var
WerSetFlags: function(dwFlags: DWord): HRESULT; stdcall;
begin
WerSetFlags := GetProcAddress(GetModuleHandle(kernel32), 'WerSetFlags');
if Assigned(WerSetFlags) then
WerSetFlags(WER_FAULT_REPORTING_ALWAYS_SHOW_UI);
end;
initialization
InitWER;
Application.OnException := TDummyObject.WERPassThrough;
SetUnhandledExceptionFilter(@WERPassThrough); // опционально
SetWERVisible; // опционально
end.
В данном примере UnhandledExceptionHandler устанавливается обработчиком для оконных приложений VCL, а для остальных мест — мы подразумеваем, что будет использован стандартный обработчик модуля System, который должен вызвать (в не самых древних Delphi) стандартный системный UnhandledExceptionFilter. Соответственно, мы назначаем свой обработчик, чтобы перехватить этот вызов и показать WER.
Конечно, в последнем случае гораздо проще просто ничего не делать, т.к., как мы помним из написанного выше, в не самых древних версиях Delphi при прогоне без отладчика исключение останется необработанным и будет поднято до WER. Именно поэтому этот код помечен «опциональным». Тем не менее, если вы захотите поменять WER на, скажем, свой собственный механизм обработки/логгирования исключений, то вам этот код будет нужен, так что я заодно его и показал.
Для совсем старых версий Delphi вы можете заменить (или дополнить) вызов SetUnhandledExceptionFilter на назначение обработчика ExceptProc.
Вызов же SetWERVisible нужен чтобы окно WER появлялось бы всегда, даже если ошибка произошла в невизуальной части нашего приложения (см. обсуждение этого поведения выше).
И если вы хотите получать отчёты, но не хотите использовать WER, то вы можете использовать полностью аналогичный код:
procedure UnhandledExceptionHandler(EP: TExceptionPointers; const AErrorCode: Cardinal = 0); overload;
begin
// ваш собственный код обработки/логгирования "необработанных" исключений.
end;
procedure UnhandledExceptionHandler(const E: Exception); overload;
var
EP: TExceptionPointers;
ER: System.TExceptionRecord;
ErrorCode: Cardinal;
begin
if E is EExternal then
EP.ExceptionRecord := Windows.PExceptionRecord(EExternal(E).ExceptionRecord)
else
begin
FillChar(ER, SizeOf(ER), 0);
ER.ExceptionCode := cDelphiException;
ER.ExceptionAddress := ExceptAddr;
ER.NumberParameters := 2;
ER.ExceptAddr := ExceptAddr;
ER.ExceptObject := Pointer(E);
EP.ExceptionRecord := Windows.PExceptionRecord(@ER);
end;
EP.ContextRecord := nil;
if E is EOSError then
ErrorCode := EOSError(E).ErrorCode
else
ErrorCode := 0;
UnhandledExceptionHandler(EP, ErrorCode);
end;
type
TDummyObject = class(TObject)
private
class procedure CustomHandle(Sender: TObject; E: Exception);
end;
{ TDummyObject }
class procedure TDummyObject.CustomHandle(Sender: TObject; E: Exception);
begin
UnhandledExceptionHandler(E);
end;
function CustomHandle(const E: TExceptionPointers): Integer; stdcall;
begin
UnhandledExceptionHandler(E);
Result := 0;
end;
// Опционально
procedure SetWERVisible;
const
WER_FAULT_REPORTING_ALWAYS_SHOW_UI = 16;
var
WerSetFlags: function(dwFlags: DWord): HRESULT; stdcall;
begin
WerSetFlags := GetProcAddress(GetModuleHandle(kernel32), 'WerSetFlags');
if Assigned(WerSetFlags) then
WerSetFlags(WER_FAULT_REPORTING_ALWAYS_SHOW_UI);
end;
initialization
Application.OnException := TDummyObject.CustomHandle;
SetUnhandledExceptionFilter(@CustomHandle);
SetWERVisible; // опционально
end.
В этом случае вызов SetUnhandledExceptionFilter становится обязательным, а не опциональным.
Примеры выше были приведены для оконного VCL-приложения, где есть глобальный объект
Application, предоставляющий событиеOnException. Если вы пишите приложение с использованием другого фреймворка — вы должны адаптировать этот код, изменив назначение глобального обработчика. Например, FireMonkey тоже предоставляет свой собственный глобальный объектApplication, у которого также есть событиеOnException. Некоторые другие фреймворки предоставляют аналогичное событие. Например, IntraWeb предоставляет событиеgServerController.OnLogException. Некоторые фреймворки в качестве такого события используют глобальную переменнуюClasses.ApplicationHandleException(например, OTL — Omni Thread Library) — так что вы можете назначить свой обработчик туда. Некоторые фреймворки предоставляют процедуру регистрации обработчика вродеRegisterExceptionFilter. Например — OTL и IntraWeb (TIWServerControllerBase.RegisterExceptionCallback). Некоторые фреймворки (в основном — многопоточные) не выпускают исключение наружу, а сохраняют его в свойстве типа.FatalException— например,TThreadи OTL.Короче говоря, вам нужно изучить документацию фреймворка, найти там как фреймворк обрабатывает исключения. И если фреймворк ловит все необработанные исключения, то узнать как можно назначить свой глобальный обработчик, назначить его — и вызывать из него
UnhandledExceptionHandlerиз примера выше.К сожалению, не всегда можно назначить свой обработчик. К примеру, службы (сервисы Win32) в Delphi не предоставляют ни события, ни какого-либо иного способа зарегистрировать обработчик. В большинстве случаев для обработки исключений вызывается не виртуальный метод
LogMessage. ВTServiceApplicationесть динамический метод DoHandleException, но заменить его нет никакой возможности, т.к. классTServiceApplicationсоздаётся безусловно, он не извлекается из какой-либо глобальной переменной, в которую мы могли бы записать свой класс. Есть и другие фреймворки, где не предусмотрена возможность указания своего обработчика исключений.Во всех таких случаях нет чистого решения. Вы можете только установить ловушку на нужный код методом сплайсинга.
И раз уж вы собираетесь вылетать, то сильно неплохо было бы настроить своё приложение на автоматический перезапуск. Делается это либо вручную (на Windows XP и младше), либо вы можете использовать Restart and Recovery API на Windows Vista и выше. Не забудьте только передавать флаг WER_SUBMIT_HONOR_RESTART. Рассмотрение Restart and Recovery API выходит за рамки этой статьи.
Настройка посмертного отладчика
Как я уже описывал, у вас есть возможность зарегистрировать любую программу на ваш выбор в качестве посмертного (postmortem) или JIT (Just-In-Time) отладчика. Когда приложение вылетает, система добавит кнопку «Отладка» («Debug») в диалог фатального вылета. Нажатие на эту кнопку запустит указанный вами отладчик, передав ему идентификатор процесса, в котором произошёл вылет. Отладчик сможет подключиться к процессу и исследовать его. Отладчик может быть классическим интерактивным — вроде отладчика Delphi. Или же это может быть автоматизированная утилита, которая просто соберёт информацию — вроде Доктора Ватсона.
Посмертный отладчик регистрируется в ключе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug (или HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug — для 32-битных приложений в 64-битной системе). Для регистрации отладчика вам нужно создать или изменить значение Debugger в ключе AeDebug (строкового типа). Строка должна содержать корректную командную строку. Иными словами, если имя/путь отладчика включает в себя пробелы, его нужно заключать в кавычки. Путь обязательно должен быть полным и абсолютным.
В командной строке нужно указать как минимум один параметр %ld — это шаблон, который будет заменён на PID процесса.
Опционально можно добавить ещё два параметра: второй %ld будет заменён на описатель (handle) события, который отладчик может взвести, чтобы возобновить выполнения процесса. При этом считается, что отладчик исправил проблему, и процесс может продолжить работу. Если его не указывать, либо отладчик его не взведёт, то система будет ждать завершения процесса отладчика, после чего возобновит обычную работу WER, т.е. считается, что проблема не исправлена. В большинстве случаев это не очень полезная возможность, которой на практике обычно не пользуются.
Наконец, можно добавить третий параметр %p, который будет заменён на адрес записи JIT_DEBUG_INFO в целевом процессе. Отладчик (или вы, вручную) может прочитать оттуда дополнительную информацию.
type
_JIT_DEBUG_INFO = record
dwSize: DWORD;
dwProcessorArchitecture: DWORD;
dwThreadID: DWORD;
dwReserved0: DWORD;
lpExceptionAddress: UInt64;
lpExceptionRecord: UInt64;
lpContextRecord: UInt64;
end;
JIT_DEBUG_INFO = _JIT_DEBUG_INFO;
TJITDebugInfo = JIT_DEBUG_INFO;
PJITDebugInfo = ^JIT_DEBUG_INFO;
Кроме того, вы можете создать строковый параметр Auto и установить его в ‘0’ или ‘1’. Несложно сообразить, что при Auto = 1 диалоговое окно не показывается, посмертный отладчик запускается сразу. При Auto = 0 (умолчание), соответственно, появляется обычное окно с дополнительной кнопкой «Отладка» («Debug»).
Примечание: поскольку настройки посмертного отладчика хранятся в HKEY_LOCAL_MACHINE — вам потребуются права администратора. Поэтому все действия ниже нужно выполнять из программ, запущенных под администратором (и с элевацией прав).
Delphi при установке регистрирует себя в качестве посмертного отладчика. Но если потом устанавливается другая среда разработки, то она может перезаписать регистрацию посмертного отладчика. К сожалению, в Delphi нет никакого способа автоматически перерегистрировать посмертный отладчик, вам придётся сделать это вручную.
К примеру, для Delphi 5-7 установите Debugger в:
"C:\путь-к-Delphi\Bin\bordbg70.exe" -aeargs %ld %ld
только замените 70 (Delphi 7) на 50 (Delphi 5) или 60 (Delphi 6).
Для более новых версий Delphi используйте:
"C:\путь-к-Delphi\Bin\BDS.exe" /attach:%ld;%ld
В настоящее время параметр %p не принимает ни одна версия Delphi.
Указанный выше отладчик Delphi 5-7 (
bordbg70.exe) является, по-сути, удалённым отладчиком (remote debugger) и поэтому зависит от соответствующей библиотеки bordbk (bordbk50.dll,bordbk60.dll,bordbk61.dll,bordbk70.dll), которую можно найти в папкеC:\Program Files\Common Files\Borland Shared\Debugger\(да, даже на 64-битной системе используетсяC:\Program Files\, а неC:\Program Files (x86)\).Если при запуске отладчика Delphi 5-7 вы получаете сообщение о невозможности загрузки библиотеки bordbk, то соответствующую библиотеку нужно зарегистрировать вызовом
tregsvr(лежит в папке\bin\Delphi) илиregsvr32(два экземпляра лежат в папкеC:\Windows\System32\— под каждую разрядность; вызывать нужно, разумеется, 32-битный), например:C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files\Common Files\Borland Shared\Debugger\bordbk70.dll"
Помимо Delphi посмертным отладчиком регистрируются и отладчики от Microsoft. Только в отличие от Delphi, многие из них имеют возможность автоматической перерегистрации. Например, отладчики WinDbg, CDB и NTSD могут быть зарегистрированы следующими командами:
windbg -I cdb.exe -iae ntsd.exe -iae
К сожалению, отладчик WinDbg при этом не регистрирует параметр для JIT_DEBUG_INFO, поэтому лучше всего отредактировать его регистрацию вручную:
"C:\путь-к-windbg\windbg.exe" -p %ld -e %ld -c ".jdinfo 0x%p"
Отладчик Visual Studio не имеет возможности перерегистрации, его нужно регистрировать заново вручную. Для этого используется такая командная строка:
"C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld
Утилита ProcDump от SysInternals также может быть зарегистрирована посмертным отладчиком с помощью такой команды:
procdump.exe -i
Утилита ProcDump создаёт дамп процесса. По умолчанию создаётся мини-дамп: списки процессов, потоков, модулей, описателей. Дамп может быть расширен указанием опций -ma или -mp. Подробнее — см. справку по параметрам ProcDump.
Если вы пользуетесь в основном Delphi, то вы регистрируете отладчик Delphi в качестве посмертного — и на этом всё. Если же вы используете несколько сред разработки, то, возможно, вы бы хотели переключаться между отладчиками. В этом случае вы можете написать свою утилиту-переходник и зарегистрировать её в качестве посмертного отладчика. Например:
"C:\Projects\Project1.exe" %ld %ld %p
При запуске вы можете показать диалоговое окно со списком отладчиков, которые вы используете в работе. При выборе отладчика — запустите его через CreateProcess, передав ему отформатированные параметры командной строки (хотя бы так: «Args := StringReplace(StringReplace(StringReplace(Args, ‘%ld’, ParamStr(1), []), ‘%ld’, ParamStr(2), []), ‘%p’, ParamStr(3), []);»). Не забудьте наследовать описатель события (второй параметр %ld) в целевой процесс. Дождитесь завершения процесса отладчика и выходите.
Например, отладчик Visual Studio позволяет выбрать отладчик так:
Этот список позволяет выбрать native-отладчик, управляемый (.NET) или Java-отладчик. Delphi там, само собой, нет. Это я просто пример привёл, как это визуально может выглядеть, если вы захотите сделать такую утилиту самостоятельно.
Использование Threads Snapshot в качестве посмертного отладчика
В качестве посмертного отладчика вы также можете использовать утилиту Threads Snapshot. Она входит в состав трейсера исключений EurekaLog. Если у вас нет EurekaLog, то вы можете скачать бесплатный Tools Pack.
Для установки Threads Snapshot в качестве посмертного отладчика достаточно запустить её с параметром «/install«:
Само собой, запускать нужно под администратором (и с элевацией прав).
Когда утилита Threads Snapshot зарегистрирована в качестве посмертного отладчика, и вылетает любое приложение — вы можете нажать кнопку Debug для снятия снимка процесса:
Нажатие на кнопку Debug запустит снятие снимка процесса:
В конце утилита Threads Snapshot подготовит отчёт и спросит у вас, куда его сохранять. Отчёт будет сохранён в обычный .el формат (отчёт EurekaLog), который можно просмотреть в любом текстовом редакторе или в бесплатной утилите EurekaLog Viewer:
Восстановить регистрацию предыдущего посмертного отладчика можно запуском Threads Snapshot с параметром «/uninstall«.
Что я могу извлечь из отчёта WER?
Во-первых, вы можете просмотреть отчёт или его часть локально. Используйте «центр обслуживания» / «журнал стабильности работы» в новых версиях Windows или системный лог — в старых.
(Примечание: «Неправильный путь приложения» — это кривой перевод «Faulting Application Path»: «Путь к сбойнувшему приложению».)
Альтернативно можно использовать сторонюю утилиту AppCrashView — она показывает существенно больше технических деталей.
Сохраняемая в отчёте информация зависит от версии Windows, настроек WER и способа вызова WER из приложения (вызвало ли WER приложение само, через API, или нет; и если через API — то какие параметры указало).
Тип вылета
В первую очередь смотрим на тип вылета. Он может быть:
- APPCRASH — необработанное исключение, самое частое событие.
- APPHANG — зависание.
- BEX — срабатывание защиты переполнение буфера (не реализовано в Delphi) или DEP (может случаться и в Delphi).
- Пользовательские типы событий (если WER вызывается вручную; только на Vista+).
Код исключения
Далее, смотрим код ошибки. Он же — код исключения. Самые частые коды: $C0000005 — это Access Violation, $0EEDFADE — исключение-объект Delphi. Могут быть и другие коды. Если вы видите неопознанный код ошибки — попробуйте использовать утилиту Error Lookup. Она входит в состав трейсера исключений EurekaLog. Если у вас нет EurekaLog, то вы можете скачать бесплатный Tools Pack.
Класс исключения
Хорошо, с аппаратными исключениями понятно — они отличаются кодом. Но как отличить одно исключение Delphi от другого? Ведь любое исключение, представленное объектом Delphi, в результате будет иметь один и тот же код $0EEDFADE? Ну, в ситуации если WER вызван системой или через API уровня WinXP (т.е. функцию ReportFault, как мы сделали это в примере выше) — никак. Вам придётся исследовать слепок (дамп) процесса. Если же вы вызываете WER вручную (аналогично нашему примеру выше) и используете API уровня Vista+ (WerCreateReport/WerSubmitReport), то вы можете скопировать имя класса и/или сообщение в один из десяти произвольных строковых параметров отчёта (модифицированный код из примера выше):
const
cDelphiException = $0EEDFADE; // копия из SysUtils
{$A+}
{$Z4}
// API уровня Windows XP
const
// Возможные коды ошибок
frrvOk = 0; // The function succeeded.
frrvOkManifest = 1; // The function succeeded and the error reporting client was launched in manifest reporting mode.
frrvOkQueued = 2; // The function succeeded and the fault report was queued for later reporting.
frrvErr = 3; // The function failed but the error reporting client was launched.
frrvErrNoDW = 4; // The error reporting client was unable to launch. The system will perform its default actions, such as displaying the standard exception dialog box and launching the debugger.
frrvErrTimeout = 5; // The function timed out.
frrvLaunchDebugger = 6; // The function succeeded and the user launched the debugger.
frrvOkHeadless = 7; // The function succeeded and the error reporting client was launched in silent reporting mode (no UI is used).
frrvCancelled = 15; // Не документирован
var
ReportFault: function(const pep: TExceptionPointers; dwOpt: DWORD): Cardinal; stdcall;
// API уровня Windows Vista
const
APPCRASH_EVENT = 'APPCRASH'; // Тип события для вылета приложения с необработанным исключением // Do Not Localize
WER_P0 = 0;
WER_P1 = 1;
WER_P2 = 2;
WER_P3 = 3;
WER_P4 = 4;
WER_P5 = 5;
WER_P6 = 6;
WER_P7 = 7;
WER_P8 = 8;
WER_P9 = 9;
WER_SUBMIT_HONOR_RECOVERY = 1; // show recovery option
WER_SUBMIT_HONOR_RESTART = 2; // show application restart option
WER_SUBMIT_QUEUE = 4; // report directly to queue
WER_SUBMIT_SHOW_DEBUG = 8; // show the debug button
WER_SUBMIT_ADD_REGISTERED_DATA = 16; // Add registered data to the WER report
WER_SUBMIT_OUTOFPROCESS = 32; // Force the report to go out of process
WER_SUBMIT_NO_CLOSE_UI = 64; // Do not show the close dialog for the critical report
WER_SUBMIT_NO_QUEUE = 128; // Do not queue the report
WER_SUBMIT_NO_ARCHIVE = 256; // Do not archive the report
WER_SUBMIT_START_MINIMIZED = 512; // The initial reporting UI is minimized and will flash
WER_SUBMIT_OUTOFPROCESS_ASYNC = 1024; // The initial reporting UI is minimized and will flash
WER_SUBMIT_BYPASS_DATA_THROTTLING = 2048; // [Win8+] Bypass data throttling for the report.
WER_SUBMIT_ARCHIVE_PARAMETERS_ONLY = 4096; // [Win8+] Archive only the parameters; the cab is discarded. This flag overrides the ConfigureArchive WER setting.
WER_SUBMIT_REPORT_MACHINE_ID = 8192; // [Win8+] Always send the unique, 128-bit computer identifier with the report, regardless of the consent with which the report was submitted.
type
TWERReportType = (
WerReportNonCritical,
WerReportCritical,
WerReportApplicationCrash,
WerReportApplicationHang,
WerReportKernel,
WerReportInvalid);
TWERReportInformation = record
dwSize: DWORD;
hProcess: THandle;
wzConsentKey: array[0..64 - 1] of WideChar;
wzFriendlyEventName: array[0..128 - 1] of WideChar;
wzApplicationName: array[0..128 - 1] of WideChar;
wzApplicationPath: array[0..MAX_PATH - 1] of WideChar;
wzDescription: array[0..512 - 1] of WideChar;
hwndParent: HWND;
end;
PWERReportInformation = ^TWERReportInformation;
TWERConsent = (
WerConsentReserved,
WerConsentNotAsked,
WerConsentApproved,
WerConsentDenied,
WerConsentMax);
TWERSubmitResult = (
WerReportReserved,
WerReportQueued,
WerReportUploaded,
WerReportDebug,
WerReportFailed,
WerDisabled,
WerReportCancelled,
WerDisabledQueue,
WerReportAsync,
WerCustomAction);
PWERSubmitResult = ^TWERSubmitResult;
TWERDumpType = (
WerDumpTypeUnknown,
WerDumpTypeMicroDump,
WerDumpTypeMiniDump,
WerDumpTypeHeapDump,
WerDumpTypeMax);
PExceptionPointers = ^TExceptionPointers;
TWERExceptionInformation = record
pExceptionPointers: PExceptionPointers;
bClientPointers: BOOL;
end;
PWERExceptionInformation = ^TWERExceptionInformation;
TWERDumpCustomOptions = record
dwSize: DWORD;
dwMask: DWORD;
dwDumpFlags: DWORD;
bOnlyThisThread: BOOL;
dwExceptionThreadFlags: DWORD;
dwOtherThreadFlags: DWORD;
dwExceptionThreadExFlags: DWORD;
dwOtherThreadExFlags: DWORD;
dwPreferredModuleFlags: DWORD;
dwOtherModuleFlags: DWORD;
wzPreferredModuleList: array[0..256 - 1] of WideChar;
end;
PWERDumpCustomOptions = ^TWERDumpCustomOptions;
var
WerReportCreate: function(pwzEventType: PWideChar; repType: TWERReportType; pReportInformation: PWERReportInformation; out phReportHandle: THandle): HRESULT; stdcall;
WerReportSetParameter: function(hReportHandle: THandle; dwparamID: DWORD; pwzName: PWideChar; pwzValue: PWideChar): HRESULT; stdcall;
WerReportAddDump: function(hReportHandle: THandle; hProcess: THandle; hThread: THandle; dumpType: TWERDumpType; pExceptionParam: PWERExceptionInformation; pDumpCustomOptions: PWERDumpCustomOptions; dwFlags: DWORD): HRESULT; stdcall;
WerReportSubmit: function(hReportHandle: THandle; Consent: TWERConsent; dwFlags: DWord; out SubmitResult: TWERSubmitResult): HRESULT; stdcall;
WerReportCloseHandle: function(hReportHandle: THandle): HRESULT; stdcall;
resourcestring
// Копия из SysConst с заменой %s (класс исключения) на %8.8x (код)
SException = 'Exception %8.8x in module %s at %p.' + sLineBreak + '%s%s' + sLineBreak;
procedure UnhandledExceptionHandler(EP: TExceptionPointers; const AErrorCode: Cardinal = 0); overload;
// Копия ShowException из SysUtils с заменой ExceptObject: TObject на Code: Cardinal
procedure ShowExceptionRecord(const ACode: Cardinal; const AAddr: Pointer);
begin
// ... (код приведён выше)
end;
// Переводит буфер в нижний регистр (только ASCII)
// Используется ниже при форматировании в HEX через StrLFmt
procedure BufferToLowerCase(P: PWideChar; Len: Integer);
var
X: Integer;
begin
for X := 0 to Len - 1 do
begin
if (Ord('A') <= Word(P^)) and
(Word(P^) <= Ord('Z')) then
P^ := Char(Word(P^) or $0020);
Inc(P);
end;
end;
// Функция по сути повторяет стандартную работу WER по сбору параметров отчёта
// Это т.н. первый уровень информации (Level One).
procedure WERSetModuleParameters(const AWERReport: THandle; const AModule: HMODULE; const P1, P2, P3: Cardinal; const AName1, AName2, AName3: PWideChar);
type
TValue = array[0..50] of WideChar;
procedure GetModuleVersion(const AFileName: PWideChar; out AVersion: TValue);
const
DefVersion: PWideChar = '0.0.0.0';
var
InfoSize: DWORD;
Handle: DWORD;
VerBuf: Pointer;
FI: PVSFixedFileInfo;
VerSize: DWORD;
Major: Word;
Minor: Word;
Release: Word;
Build: Word;
begin
FillChar(AVersion, SizeOf(AVersion), 0);
Move(DefVersion^, AVersion, (Length('0.0.0.0') + 1) * SizeOf(WideChar));
InfoSize := GetFileVersionInfoSizeW(PWideChar(AFileName), Handle);
if InfoSize <> 0 then
begin
// Размер не известен и иногда может быть большим.
// Мы не можем использовать стек, придётся использовать кучу.
// Поскольку менеджер памяти может быть не рабочим, используем альтернативу.
// Я выбрал HeapAlloc, но можно использовать и другие функции.
VerBuf := HeapAlloc(GetProcessHeap, HEAP_ZERO_MEMORY, InfoSize);
try
if GetFileVersionInfoW(PWideChar(AFileName), Handle, InfoSize, VerBuf) then
if VerQueryValue(VerBuf, '\', Pointer(FI), VerSize) then
begin
Major := Hiword(FI.dwFileVersionMS);
Minor := Loword(FI.dwFileVersionMS);
Release := Hiword(FI.dwFileVersionLS);
Build := Loword(FI.dwFileVersionLS);
StrLFmt(@AVersion, Length(AVersion) - 1, '%d.%d.%d.%d', [Major, Minor, Release, Build]);
end;
finally
HeapFree(GetProcessHeap, 0, VerBuf);
end;
end;
end;
function ReadResourceTime(const AImage: THandle): Cardinal;
type
_IMAGE_RESOURCE_DIRECTORY = record
Characteristics: DWORD;
TimeDateStamp: DWORD;
// остальные поля нам не интересны, опускаем
end;
PImageResourceDirectory = ^_IMAGE_RESOURCE_DIRECTORY;
PImageOptionalHeader = ^TImageOptionalHeader;
var
Header: PImageDosHeader;
ImageNtHeaders: PImageNtHeaders;
OptionalHeader: PImageOptionalHeader;
DataDir: PImageDataDirectory;
DOSTimeStamp: Cardinal;
DT: TDateTime;
begin
Result := 0;
Header := PImageDosHeader(AImage);
if (Header.e_magic <> IMAGE_DOS_SIGNATURE) or
(Header._lfanew = 0) then
Exit;
ImageNtHeaders := PImageNtHeaders(PAnsiChar(AImage) + Header._lfanew);
if ImageNtHeaders.Signature <> IMAGE_NT_SIGNATURE then
Exit;
// FileHeader.TimeDateStamp не заполняется некоторыми версиями компилятора Delphi,
// поэтому мы используем время ресурсов
OptionalHeader := @ImageNtHeaders.OptionalHeader;
if OptionalHeader.NumberOfRvaAndSizes >= IMAGE_DIRECTORY_ENTRY_RESOURCE then
begin
DataDir := @OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE];
if (DataDir.Size > 0) and
(DataDir.VirtualAddress > 0) then
begin
DOSTimeStamp := PImageResourceDirectory(PAnsiChar(AImage) + DataDir.VirtualAddress)^.TimeDateStamp;
DT := FileDateToDateTime(DOSTimeStamp);
Result := DateTimeToUnix(DT);
end;
end;
end;
var
FileName: array[0..MAX_PATH] of WideChar;
Name: array[0..MAX_PATH] of WideChar;
Version: TValue;
X: Integer;
LastPos: Integer;
EndPos: Integer;
CompilationTimeStamp: Cardinal;
begin
// Имя файла
FillChar(FileName, SizeOf(FileName), 0);
FillChar(Name, SizeOf(Name), 0);
GetModuleFileNameW(AModule, @FileName, Length(FileName));
LastPos := 0;
EndPos := MAX_PATH + 1;
for X := 0 to High(FileName) do
begin
if FileName[X] = #0 then
begin
EndPos := X;
Break;
end
else
if Word(FileName[X]) = Ord('\') then
LastPos := X;
end;
if LastPos > 0 then
Move(FileName[LastPos + 1], Name[0], (EndPos - LastPos) * SizeOf(WideChar))
else
Move(FileName, Name, SizeOf(Name));
WerReportSetParameter(AWERReport, P1, AName1, @Name);
// Версия
GetModuleVersion(FileName, Version);
WerReportSetParameter(AWERReport, P2, AName2, @Version);
// Метка времени
// Стандартный WER добавляет её в виде DOS-ского timestamp
CompilationTimeStamp := ReadResourceTime(AModule);
FillChar(Name, SizeOf(Name), 0);
StrLFmt(@Name, Length(Name) - 1, '%x', [CompilationTimeStamp]);
BufferToLowerCase(Name, Length(Name));
WerReportSetParameter(AWERReport, P3, AName3, @Name);
end;
var
ErrorCode: Cardinal;
WERResult: Cardinal;
WERReport: THandle;
WERSubmitResult: TWERSubmitResult;
ReportInfo: TWERReportInformation;
PReportInfo: PWERReportInformation;
EO: TObject;
EA: Pointer;
MBI: TMemoryBasicInformation;
PClassName: PShortString;
FriendlyEventName: array[0..128 - 1] of AnsiChar;
Sz: Integer;
Value: array[0..32] of WideChar;
Module: HMODULE;
Offset: HMODULE;
Flags: Cardinal;
WEI: TWERExceptionInformation;
{$IFNDEF UNICODE}
Description: array[0..512 - 1] of AnsiChar;
{$ENDIF}
begin
// Сначала определим код, с которым завершится наше приложение
if AErrorCode <> 0 then
ErrorCode := AErrorCode
else
ErrorCode := EP.ExceptionRecord.ExceptionCode;
// Для Delphi исключений объект уже есть - извлекаем его
if EP.ExceptionRecord.ExceptionCode = cDelphiException then
begin
EO := TObject(SysUtils.PExceptionRecord(EP.ExceptionRecord).ExceptObject);
EA := SysUtils.PExceptionRecord(EP.ExceptionRecord).ExceptAddr;
// На всякий случай проверим объект:
// размещён ли он в доступной странице памяти.
// Менеджер памяти Delphi может уже завершить работу к этому моменту.
// Например, если исключение возникло в секции initialization модуля,
// то сначала сработает блок except процедуры InitUnits модуля System,
// который завершит модули (и менеджер памяти - в том числе),
// а затем уже вызовет UnhandledExceptionFilter.
if (EO = nil) or
(VirtualQuery(EO, MBI, SizeOf(MBI)) = 0) or
(MBI.State <> MEM_COMMIT) then
EO := nil;
end
else
// Для аппаратных исключений объекта нет
begin
EO := nil;
EA := EP.ExceptionRecord.ExceptionAddress;
end;
EP.ExceptionRecord.ExceptionAddress := EA;
// Вызываем WER, сначала вариант Windows Vista+
if Assigned(WerReportCreate) (* and (EO <> nil) { опционально } *) then
begin
if EO <> nil then
begin
FillChar(ReportInfo, SizeOf(ReportInfo), 0);
ReportInfo.dwSize := SizeOf(ReportInfo);
ReportInfo.hProcess := GetCurrentProcess;
if Assigned(Application) and Assigned(Application.MainForm) then
ReportInfo.hwndParent := Application.MainForm.Handle;
// Записываем класс исключения и сообщение в "тип события" и "описание" соответственно
// Ради этого весь сыр-бор и затевался
PClassName := PShortString(PPointer(PAnsiChar(PPointer(EO)^) + vmtClassName)^); // PAnsiChar используется для адресной арифметики
Sz := Byte(PClassName^[0]);
Move(PClassName^[1], FriendlyEventName, Sz);
MultiByteToWideChar(CP_UTF8, 0, @FriendlyEventName, Sz, @ReportInfo.wzFriendlyEventName, Length(ReportInfo.wzFriendlyEventName));
if EO is Exception then
begin
{$IFDEF UNICODE}
StrLCopy(ReportInfo.wzDescription, PWideChar(Exception(EO).Message), Length(ReportInfo.wzDescription));
{$ELSE}
if Length(Exception(EO).Message) > Length(Description) then
Sz := Length(Description)
else
Sz := Exception(EO).Message;
Move(Pointer(Exception(EO).Message)^, Description, Sz);
MultiByteToWideChar(CP_ACP, 0, @Description, Sz, @ReportInfo.wzDescription, Length(ReportInfo.wzDescription));
{$ENDIF}
end;
PReportInfo := @ReportInfo;
end
else
PReportInfo := nil;
if Succeeded(WerReportCreate(APPCRASH_EVENT, WerReportApplicationCrash, PReportInfo, WERReport)) then
// Альтернативно, вместо WerReportApplicationCrash можно указывать:
// WerReportApplicationHang - для зависаний и взаимных блокировок,
// WerReportCritical - аналог WerReportApplicationCrash, но в отчёте показывает имя исполняемого файла вместо имени,
// WerReportNonCritical - для не-ошибок (отправка в фоне/очереди, нет UI)
try
// Устанавливаем 8 параметров - аналогично стандартному отчёту WER
// (В принципе, мы можем задавать параметры как угодно)
// Первые три параметра характеризуют приложение
WERSetModuleParameters(WERReport, MainInstance, WER_P0, WER_P1, WER_P2,
'Application Name', 'Application Version', 'Application Timestamp');
// Следующие три параметра характеризуют модуль, в котором произошёл вылет
Module := FindHInstance(EA);
WERSetModuleParameters(WERReport, Module, WER_P3, WER_P4, WER_P5,
'Fault Module Name', 'Fault Module Version', 'Fault Module Timestamp');
// Последние два параметра характеризуют исключение
StrLFmt(@Value, Length(Value) - 1, '%8.8x', [EP.ExceptionRecord.ExceptionCode]);
BufferToLowerCase(@Value, Length(Value));
WerReportSetParameter(WERReport, WER_P6, 'Exception Code', @Value);
Offset := HMODULE(EP.ExceptionRecord.ExceptionAddress);
if (Module <> 0) and (Offset > Module) then
Offset := Offset - Module;
StrLFmt(@Value, Length(Value) - 1, {$IFDEF CPUX64}'%16.16x'{$ELSE}'%8.8x'{$ENDIF}, [Offset]);
BufferToLowerCase(@Value, Length(Value));
WerReportSetParameter(WERReport, WER_P7, 'Exception Offset', @Value);
// и добавляем свой девятый параметр (не имеет аналога в WER) - код из EOSError, EDatabaseError, ...
StrLFmt(@Value, Length(Value) - 1, '%d', [ErrorCode]);
WerReportSetParameter(WERReport, WER_P8, 'Error Code', @Value);
// Добавляем к отчёту мини-дамп (опционально)
FillChar(WEI, SizeOf(WEI), 0);
WEI.pExceptionPointers := @EP;
WEI.bClientPointers := True;
WerReportAddDump(WERReport, GetCurrentProcess, GetCurrentThread, WerDumpTypeMiniDump { или WerDumpTypeHeapDump для большего покрытия }, @WEI, nil, 0);
// Опционально к отчёту можно присоединить любую дополнительную информацию и файлы
if CheckWin32Version(6, 2) then // Win8+ - добавим идентификатор машины (опционально)
Flags := WER_SUBMIT_OUTOFPROCESS or WER_SUBMIT_REPORT_MACHINE_ID
else
Flags := WER_SUBMIT_OUTOFPROCESS;
// "out of process" делать - хорошо, минимизирует вылет при stack overflow
// В этом месте появится обычное окно WER "В программе - ошибка, идёт поиск решения"
if Failed(WerReportSubmit(WERReport, WerConsentNotAsked, Flags, WERSubmitResult)) then
WERSubmitResult := WerReportFailed;
case WERSubmitResult of
WerReportQueued, WerReportUploaded, WerDisabledQueue, WerReportAsync:
// Успех
TerminateProcess(GetCurrentProcess, ErrorCode);
WerReportCancelled:
// Отправку отменили, следовательно, UI был, выходим
TerminateProcess(GetCurrentProcess, ErrorCode);
WerReportDebug:
begin
// Нужно запустить отладчик из ключа реестра AeDebug
// Оставляю это в качестве домашнего задания,
// чтобы не засорять пример
end;
else begin end; // ошибки (WerDisabled, WerFailed)
end;
finally
WerReportCloseHandle(WERReport);
end;
end
// Не Vista, вызываем WinXP
else if Assigned(ReportFault) then
begin
// В этом месте появится обычное окно WER "В программе - ошибка, идёт поиск решения"
WERResult := ReportFault(EP, 0);
case WERResult of
frrvOk, frrvOkManifest, frrvOkQueued, frrvOkHeadless:
// Успех
TerminateProcess(GetCurrentProcess, ErrorCode);
frrvCancelled:
// Отправку отменили, следовательно, UI был, выходим
TerminateProcess(GetCurrentProcess, ErrorCode);
frrvLaunchDebugger:
begin
// Нужно запустить отладчик из ключа реестра AeDebug
// Оставляю это в качестве домашнего задания,
// чтобы не засорять пример
end;
else begin end; // ошибки frrvErr*, в том числе - frrvErrNoDW, если WER отключен
end;
end;
// Если WER нет или произошла ошибка - покажем:
if EO <> nil then
// если объект есть - обычное сообщение средствами SysUtils
ShowException(EO, EA)
else
// если объекта нет - своё сообщение
ShowExceptionRecord(EP.ExceptionRecord.ExceptionCode, EP.ExceptionRecord.ExceptionAddress);
// Завершим приложение в любом случае - с выбранным кодом ошибки
TerminateProcess(GetCurrentProcess, ErrorCode);
end;
Да, ужасно много работы ради замены всего двух параметров. Получился не самый тривиальный код, который, к тому же работает без выделения памяти в куче стандартного менеджера памяти. Увы, вызвать WER — это вам не класс с перезаписью виртуального метода унаследовать. Вы можете модифицировать этот код под ваши нужды. Например, выводить имя класса и сообщение через (не используемые WER) параметры WER_P8 и WER_P9, или заменить один из стандартных параметров WER_P0-WER_P7.
И насчёт сообщения — будьте аккуратны. Параметры отчёта используются WER для группировки и классификации отчётов, а сообщение об ошибке может быть локализовано, что приведёт к ненужному дублированию отчётов. Экспериментируйте.
В любом случае, в результате имеем:
Для исключений Delphi теперь показывается имя класса и сообщение исключения. Для аппаратных исключений всё осталось по прежнему, дополнительной информации мы не добавляем.
Напомню, эта кастомизация возможна только на Windows Vista и выше. На Windows XP отчёт не изменится.
Смещение/адрес исключения
Как только вы опознали что именно произошло, осталось понять где это произошло. Для этого посмотрите на параметры имя модуля (не приложения!) и смещение (offset) для этого модуля.
Имя модуля покажет модуль, в котором было возбуждено исключение. Смещение — это смещение указателя (на код) от начала этого модуля. К примеру, если исключение возникло по адресу $004AF70A в модуле CrashMe5.exe, который загружен по (стандартному для .exe) адресу $00400000, то смещение будет равно: $004AF70A — $00400000 = $AF70A. И наоборот, если вы знаете смещение, то, узнав адрес загруженного модуля, можете узнать и где произошло исключение: $000AF70A + $00400000 = $004AF70A.
Почему вообще используется какое-то смещение? Почему бы в отчёте просто не указать адрес?
Потому что этот адрес не будет иметь для вас смысла. К примеру, на машине где произошёл вылет адрес оказался равен $77A0098E, а модуль был загружен по адресу $77990000. Ну а на вашей машине этот модуль оказался загруженным по адресу $5AD20000. И что теперь? Как вы найдёте место вылета? Адрес $77A0098E на вашей машине вообще не указывает внутрь модуля!
Но если вы знаете смещение ($77A0098E — $77990000 = $7098E), то легко определите и адрес вылета: $5AD20000 + $7098E = $5AD9098E — именно в этом месте произошло исключение.
Окей, но как же узнать, что за код выполнялся по этому адресу?
Для этого вы можете использовать утилиту Address Lookup. Она входит в состав трейсера исключений EurekaLog. Если у вас нет EurekaLog, то вы можете скачать бесплатный Tools Pack. Запустите утилиту, укажите на модуль вылета и укажите смещение:
Утилита покажет вам в каких модуле, классе, методе/функции и строке произошёл вылет. Чтобы это стало возможным утилите необходима отладочная информация. Она понимает множество форматов: map-файлы, TDS/TD32, JCL, DBG и другие. Но это также означает, что вам нужно заранее позаботится об этом. Включите генерацию map-файла (или используйте любой другой из поддерживаемых форматов). Разумеется, эти map-файлы (а также .tds, .dbg, .jdbg и т.п.) нужно будет хранить у себя. И не перепутать два разных файла от двух разных версий одной программы. Чтобы не перепутать — используйте поле версии в версионной информации модуля.
Некоторые форматы поддерживают внедрение (собственный формат EurekaLog, TDS/TD32, JCL и т.п.) — вы можете использовать их. Тогда дополнительных файлов хранить не нужно (только сам модуль) и нельзя перепутать версии файлов, что тоже есть хорошо. Но увеличивается размер модуля, что не есть хорошо. Выбор за вами.
Альтернативно, вы можете использовать и саму Delphi. Для этого запустите программу (ровно той версии, что упомянута в отчёте) и поставьте её на паузу (Run / Pause), затем откройте окно со списком модулей: View / Debug / Modules и выясните по какому адресу оказался загружен модуль на вашей машине.
У вас есть базовый адрес, у вас есть смещение — вычислите полный адрес, сложив два значения. Теперь используйте Search / Go to address и введите полученный абсолютный адрес:
Если вы всё сделали правильно, то IDE откроет нужный модуль и ткнёт вас в строчку с ошибкой.
Однако у этого способа куча минусов. Во-первых, не только версия программы должна полностью совпадать с модулем, в котором произошёл вылет, вам также необходимо иметь копию всех исходников для этой версии, а также быть 100% уверенными, что при перекомпиляции вы получите точно ту же самую программу. В противном случае адреса будут отличаться и этот метод ткнёт вас в неверное место.
Во-вторых, IDE попросту не поддерживает сторонние отладочные форматы. Поэтому если вылет произошёл во внешнем модуле (в частном случае — в модуле ОС), то IDE откроет CPU-отладчик и ткнёт вас в конкретную ассемблерную инструкцию. Никакой дополнительной информации она показать не сможет.
На практике хранить все копии исходников, восстанавливать их для исследования каждого вылета, пересобирать программу, гарантировать/проверять её совпадение — крайне трудоёмко и чревато ошибками, поэтому этот способ (с IDE) стоит приберечь только на самый последний случай (когда заранее к нему не подготовились), а сильно предпочтительнее просто генерировать отладочную информацию в одном из форматов и хранить её (либо ещё лучше — внедрять), а затем использовать Address Lookup.
P.S. Аналогичную технику можно использовать и для анализа любых других адресов в сообщениях об ошибках. Например, «Runtime error 217 at 004060CD» или «Access Violation at address 005D2500…». К сожалению, Delphi сделана в этом отношении не совсем грамотно: она показывает абсолютный адрес, а не смещение. В итоге получается, что если ошибка произошла в .exe — вам (возможно) повезло: .exe (почти) всегда грузится по фиксированному адресу $00400000. Если же исключение произошло в DLL — вы пролетели, если только вам сильно не повезёт (каким-то образом вы узнаете базовый адрес DLL, или же DLL на вашей машине окажется загруженной по тому же адресу).
Стек, переменные и другая информация
Окей, с базовой информацией мы разобрались. Но что делать с самой вкусной частью пирога — стеком вызова и, возможно, значениями переменных? К сожалению, в Delphi вы не сделаете ничего. Но вы можете использовать отладчик Microsoft. Для этого вам потребуется следующее:
- Vista и выше. На Windows XP дампы не создаются.
- Отчёт вылета должен содержать в себе дамп процесса (дамп процесса также называется мини-дампом, противопоставляя себя полному дампу режима ядра). Дамп процесса — это «слепок» памяти и, возможно, объектов процесса. Если вы вызываете WER вручную, то параметры создания дампа вы указываете самостоятельно — в вызове WER. См. код-пример выше, где мы вызывали
WerReportAddDumpдля добавления мини-дампа в отчёт. Если вылет происходит под управлением системы, то мини-дамп создаётся (или нет) согласно настройке WER. В любом случае, файл мини-дампа будет упомянут в отчёте (файл .mdmp или, реже, .dmp), а ссылки на локальные хранилища я приводил выше (в описании WER). - Отладочная информация в формате, которую может понять отладчик Microsoft. Для этого вам нужно создавать отладочную информацию в формате MAP и/или TDS/TD32, а затем использовать конвертер в DBG или PDB. Для этого подойдёт какой-либо из вариантов утилиты map2dbg:
- https://code.google.com/p/map2dbg/
- https://github.com/andremussche/map2dbg
- https://github.com/garethm/map2dbg
- https://bitbucket.org/wpostma/map2dbg
или утилиты tds2pdb:
- https://github.com/andremussche/map2dbg/tree/master/tds2pdb
- https://sourceforge.net/projects/tds2pdb/
- Сама Visual Studio или WinDbg.
Я решил вынести этот вопрос за рамки статьи, потому что я не уверен, что эта информация нужна по следующим причинам:
- Это достаточно трудоёмкий процесс.
- Интеграция не идеальна. К примеру, Visual Studio мне так и не удалось заставить читать DBG/PDB, созданные указанными утилитами. Это работает для WinDbg, но для Delphi-ста изучать WinDbg (отладчик, управляемый в основном текстовыми командами) — весьма нетривиальная задача. Также есть проблемы с 64-разрядными файлами.
- Намного проще добавить к отчёту произвольный файл(ы) (через WerReportAddFile) — куда вы можете записать стеки, дампы кучи, переменные, логи, скриншоты, рабочие файлы и вообще всё, что душа пожелает.
Как мне получать отчёты WER?
Для этого необходимо зарегистрировать в Microsoft свою программу (а точнее — каждую версию каждого исполняемого файла).
В первую очередь для этого вам потребуется сертификат для цифровой подписи — только так вы можете подтвердить, что вы именно тот человек, который собрал программу. Ранее для этого требовался только особый сертификат от одобренного Microsoft поставщика: VeriSign — стоимостью $500 в год.
К счастью, сегодня это не так. Вам подойдёт любой сертификат для цифровой подписи. Ключевые слова для поиска: code signing certificate или Microsoft Authenticode. Стоимость — что-то от $65 в год (при покупке на несколько лет) до $200 — в зависимости от поставщика. Остались и сертификаты за $500, но они теперь уже EV: «Extended Validation». Для них производится более тщательная проверка перед выдачей сертификата вас как компании. Такие подписи получают бонус от Smart-фильтров браузеров, а также требуются для подписи драйверов. Для обычного же разработчика вполне достаточно сертификатов за $65 в год. Только убедитесь, что вы покупаете сертификат именно для подписи исполняемых файлов Windows.
Подписывать свои программы — есть хорошо в любом случае, так что, если вы профессионально разрабатываете софт, то сертификат для подписи у вас и так уже есть.
Как только у вас появится сертификат, вам, возможно, придётся переконвертировать в подходящий формат. Это бывает редко, но иногда необходимо. Поскольку я понятия не имею, в каком формате у вас сертификат — идите в Google. Вам нужно сконвертировать в формат PFX.
Далее, вам потребуется Windows SDK. Не хочу давать прямую ссылку, они меняются. Поищите в Google по ключевым: download Windows SDK. Устанавливаете SDK. Вас там интересует только утилита SignTool.
Когда SDK поставили — можно подписывать файлы. Делать это нужно после каждой компиляции для релиза. Можете использовать для этого Post-Build Event в современных IDE, либо что-то вроде FinalBuilder.
Если вы не используете FinalBuilder, то вызывать SignTool вам придётся вручную. Как-то так:
"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe" sign /f "C:\путь-к-сертификату\сертификат.pfx" /p "пароль" /tr timestamp-сервер "C:\путь-к-программе\модуль.exe" /d "Краткое описание программы" /du "http://сайт-программы/"
где «timestamp-сервер» может быть: http://timestamp.comodoca.com, http://sha256timestamp.ws.symantec.com/sha256/timestamp, http://tsa.starfieldtech.com/ или любым другим timestamp-сервером, поддерживающим RFC 3161.
Примечание: все современные сертификаты используют SHA-256 и не распознаются Windows XP и ниже (которая поддерживает только SHA-1).
Как только вы подписали файл — можно регистрировать его в Microsoft. Веб-сайт Windows Error Reporting (бывший WinQual) сейчас переехал на sysdev.microsoft.com (который, в свою очередь, в настоящее время находится в процессе переезда на https://developer.microsoft.com/dashboard/hardware — который пока только для разработчиков драйверов). Само собой, потребуется учётная запись Microsoft (Live), а также необходимо будет использовать только Internet Explorer.
Регистрация происходит путём подписи файла. Вам предложат скачать .exe файл, вы должны подписать его своим сертификатом и закачать на сайт. Профиль компании будет создан автоматически по сертификату, вы станете администратором. Если же доступа к сертификату у вас нет, то вы можете выбрать одну из уже зарегистрированных компаний и сможете присоединиться к ней после одобрения заявки администратором компании.
Выглядит это примерно так (на скриншотах показан процесс для драйверов на developer.microsoft.com, поэтому и упоминается EV; я не могу сделать скриншоты для обычного сертификата, поскольку этот процесс я уже прошёл; напомню, что в настоящее время вам нужно заходить на sysdev.microsoft.com, где произойдёт аналогичный процесс):
Как только вы успешно зарегистрировались и вошли — вам будет доступна консоль (dashboard).
Большинство опций в ней предназначены для разработчиков драйверов и сертификации приложений — и потому нам не интересны. Фактически, нас интересуют только отчёты (Reports). Но прежде нам нужно сделать ещё две вещи.
Первое, что вам придётся в ней сделать — подписать соглашение. Для этого откройте Administration / Legal agreements:
Как и ранее — тут куча всего для драйверов и сертификации, что нам не интересно. Выберите в фильтре тип «Signable» (т.е. что можно подписать, но ещё не подписано) и найдите в списке WER. Я не могу показать процесс подписи именно для этого соглашения (потому что у меня оно уже подписано), но вот скриншот для другого соглашения:
Важно: вы должны использовать только Internet Explorer и у вас должен стоять Adobe Acrobat.
Фактически, тут вам нужно продублировать ваше имя и дату (Ctrl + C / Ctrl + V) и нажать «Submit».
Наконец, последнее, что нам осталось сделать — зарегистрировать свои программы. Делается это не тривиально. Откройте раздел Reports (где будет написано, что у вас отчётов нет) и проскрольте вниз, ищите ссылку на «Product mapping Tool»:
Качайте и устанавливайте.
Тут вас поджидает сюрприз, ибо установщик запросит установленный Windows Live Essentials, который… не доступен для скачивания. Придётся искать оффлайн установщик по неофициальным каналам. Короче, гуглите.
В любом случае, текущая версия Product Mapping Tool называется аж Microsoft Ecosystem Metadata Exchange (или MEME). Она попросит вас войти в вашу учётку и синхронизируется с сервером Microsoft.
Ну вот с помощью её мы и добавляем каждый выпуск (release) нашей программы. Само собой, добавляем Product, а не Driver. Ну и если у вас прям сложная программа, то можете создать ещё Product Group, но это не обязательно.
Не забываем добавить и сами файлы (которые уже должны быть подписаны вашим сертификатом). Ещё раз: файл обязан быть подписан! И быть подписан именно вашим сертификатом, на аккаунт которого вы вошли в MEME. Если файл не будет подписан или будет подписан любым другим сертификатом (включая двойную подпись) — MEME покажет ошибку.
Ещё один сюрприз тут — утилиту нужно вручную запускать с правами администратора (запускать из: C:\Program Files (x86)\Microsoft Ecosystem Metadata Exchange\MetadataExchange\). По крайней мере, на Windows 10. Иначе попытка добавления файла закончится ошибкой недостаточных привилегий (утилита выдаст общее сообщение «ошибка — см. лог», а подробности можно найти в системном логе «Приложения»).
Я понятия не имею, что будет, если версионная информация в исполняемом модуле не будет совпадать с мета-информацией, которую вы вводите в MEME. Лучше бы, наверное, чтобы она совпадала как можно лучше — особенно номера версий.
Не забудьте опубликовать внесённые изменения — ссылка «Publish Changes» в заголовке:
Публикуйтесь — и на этом всё! Конечно, процесс ассоциации нужно будет проводить заново для каждого релиза/версии каждой вашей программы. Но по крайней мере, вы уже зарегистрированы в системе.
После этого можно деплоить и крашиться! После регистрации вид раздела Reports изменится на рабочий:
Учтите только, что отчётам нужно время, чтобы пройти отправку и сортировку, появляются они не сразу. Задержка будет от нескольких дней до месяца.
Вот как будет выглядеть раздел отчётов при поступлении багов:
Это общий вид «Product group summary», где создано две версии одного продукта, одна из которых раскрыта. Как вы можете видеть, отчёты сортируются по количеству возникновения. Чем больше произошло вылетов — тем выше в списке запись. Есть также «Company hotlist» — куда попадают самые «популярные» быги из всех ваших продуктов. Подразумевается, что «Company hotlist» будет служить своеобразным списком TO-DO для исправления багов.
Вы можете раскрыть любую запись:
Будут показана статистика и возможность скачать отчёты.
У записей также может не быть никаких данных, кроме статистики. Это потому, что они не собраны. Вы должны щёлкнуть «Request more data»:
В любом случае, когда вы скачаете отчёт (.cab или .zip-файл — в зависимости от ОС), в нём будет:
Вот два отчёта с разных систем. В обоих случаях присутствует дамп процесса (minidump.mdmp), общая информация (WERInternalMetadata.xml) и пользовательский файл, присоединённый через WerReportAddFile (dump.txt) — куда вы можете сохранить информацию об исключении, стеки вызовов и т.п.
WERInternalMetadata.xml выглядит примерно так (полный вариант из отчёта с 6-ю файлами; вариант из отчёта с тремя файлами существенно короче):
<?xml version="1.0" encoding="UTF-16"?>
<WERReportMetadata>
<OSVersionInformation>
<WindowsNTVersion>10.0</WindowsNTVersion>
<Build>15063</Build>
<Product>(0x30): Windows 10 Pro</Product>
<Edition>Professional</Edition>
<BuildString>15063.138.amd64fre.rs2_release.170317-1834</BuildString>
<Revision>138</Revision>
<Flavor>Multiprocessor Free</Flavor>
<Architecture>X64</Architecture>
<LCID>1049</LCID>
</OSVersionInformation>
<ProcessInformation>
<Pid>11200</Pid>
<ImageName>CrashMe32.exe</ImageName>
<CmdLineSignature>00000000</CmdLineSignature>
<Uptime>2114</Uptime>
<Wow64 guest="332" host="34404">1</Wow64>
<ProcessVmInformation>
<PeakVirtualSize>151908352</PeakVirtualSize>
<VirtualSize>142888960</VirtualSize>
<PageFaultCount>5762</PageFaultCount>
<PeakWorkingSetSize>21839872</PeakWorkingSetSize>
<WorkingSetSize>14458880</WorkingSetSize>
<QuotaPeakPagedPoolUsage>270200</QuotaPeakPagedPoolUsage>
<QuotaPagedPoolUsage>249184</QuotaPagedPoolUsage>
<QuotaPeakNonPagedPoolUsage>17256</QuotaPeakNonPagedPoolUsage>
<QuotaNonPagedPoolUsage>16712</QuotaNonPagedPoolUsage>
<PagefileUsage>4116480</PagefileUsage>
<PeakPagefileUsage>4124672</PeakPagefileUsage>
<PrivateUsage>4116480</PrivateUsage>
</ProcessVmInformation>
<ParentProcess>
<ProcessInformation>
<Pid>2464</Pid>
<ImageName>TOTALCMD64.EXE</ImageName>
<CmdLineSignature>80004005</CmdLineSignature>
<Uptime>4467447</Uptime>
<Wow64 guest="0" host="34404">0</Wow64>
<ProcessVmInformation>
<PeakVirtualSize>657219584</PeakVirtualSize>
<VirtualSize>461492224</VirtualSize>
<PageFaultCount>28170</PageFaultCount>
<PeakWorkingSetSize>44371968</PeakWorkingSetSize>
<WorkingSetSize>38064128</WorkingSetSize>
<QuotaPeakPagedPoolUsage>502208</QuotaPeakPagedPoolUsage>
<QuotaPagedPoolUsage>476984</QuotaPagedPoolUsage>
<QuotaPeakNonPagedPoolUsage>35848</QuotaPeakNonPagedPoolUsage>
<QuotaNonPagedPoolUsage>33168</QuotaNonPagedPoolUsage>
<PagefileUsage>19787776</PagefileUsage>
<PeakPagefileUsage>20017152</PeakPagefileUsage>
<PrivateUsage>19787776</PrivateUsage>
</ProcessVmInformation>
</ProcessInformation>
</ParentProcess>
</ProcessInformation>
<ProblemSignatures>
<EventType>APPCRASH</EventType>
</ProblemSignatures>
<DynamicSignatures>
<Parameter1>10.0.15063.2.0.0.256.48</Parameter1>
<Parameter2>1049</Parameter2>
</DynamicSignatures>
<SystemInformation>
<MID>6A93F14F-F67E-426D-AC92-FA8CC504DDFC</MID>
<SystemManufacturer>System manufacturer</SystemManufacturer>
<SystemProductName>System Product Name</SystemProductName>
<BIOSVersion>4802</BIOSVersion>
<OSInstallDate>1492177385</OSInstallDate>
<OSInstallTime>2017-04-14T13:42:56Z</OSInstallTime>
<TimeZoneBias>-03:00</TimeZoneBias>
</SystemInformation>
<SecureBootState>
<UEFISecureBootEnabled>1</UEFISecureBootEnabled>
<PolicyPublisher>{77fa9abd-0359-4d32-bd60-28f4e78f784b}</PolicyPublisher>
</SecureBootState>
<ReportInformation>
<Guid>b91edf68-85d7-42b4-9805-d07cba17fec0</Guid>
<ReportSource>memory</ReportSource>
<CreationTime>2017-04-25T20:03:11Z</CreationTime>
</ReportInformation>
</WERReportMetadata>
sysinfo.txt содержит статистику работы системы (что-то вроде performance counters). WERDataCollectionStatus.txt — служебный. А memory.csv содержит список процессов (со статистикой).
Что если я хочу использовать отчёты, но не хочу использовать WER?
Да, использовать WER для Delphi приложений довольно сложно:
- Достаточно сложно всё настроить и зарегистрироваться
- Требуется сертификат цифровой подписи
- Отчёты доставляются с задержкой, а сам сайт sysdev работает неторопливо
- Нужно явно регистрировать каждую публикуемую сборку приложения
- Отчёты с Windows XP (и ранее) практически бесполезны, поскольку не включают в себя дамп и не позволяют приложить пользовательские файлы
- Невозможно использовать отладчик Delphi или Visual Studio для анализа дампов, будет работать только WinDbg
- Невозможно анализировать дампы 64-разрядных процессов
- В случае неконтролируемого вылета (т.е. когда WER вызывает система, а не мы сами), пользовательских данных у отчёта не будет
Поэтому вы можете захотеть использовать свой собственный механизм отправки и сбора отчётов. Для этого вам потребуется две вещи:
- Централизованный сервер для сбора отчётов, включая их сортировку/группировку и возможности просмотра
- Код отправки вылета приложения на сервер
В качестве сервера я крайне рекомендую FogBugz или Exceptionless — это единственные известные мне системы отслеживания ошибок (среди прочих: Mantis, JIRA, Bugzilla, Redmine, YouTrack), которые были созданы с прицелом на автоматический сбор отчётов. Только FogBugz и Exceptionless поддерживают понятие bug hash / bugID / alias с автоматической группировкой, учётом (count / occurencies) и контролем сбора. Во всех остальных трекерах отсутствует часть возможностей. Будете делать отправку отчётов через REST API FogBugz — ищите по ключевым словам BugzScout и sScoutDescription. У Exceptionless API ещё проще, но слабо документирован — проще посмотреть их примеры и перехватить трафик.
К счастью, мы уже рассмотрели все модификации кода, которые вам нужно сделать в вашем приложении выше — теперь вам осталось только поместить ваш код отправки отчёта вместо ReportFault / WerSubmitReport в функцию UnhandledExceptionHandler выше.
Что если я не хочу изобретать при этом велосипед?
Тогда вам нужно использовать готовое решение. Для Delphi есть два трейсера исключений с поддержкой отправки отчётов в FogBugz: EurekaLog и madExcept. Конечно, они поддерживают не только FogBugz, но и другие трекеры.
Более того, если вы хотите использовать WER, то EurekaLog поддерживает и его — присоединяя свой отчёт как дополнительный файл. (Я не уверен, но возможно, что madExcept в режиме Windows Logo Compliant Mode делает что-то аналогичное.)
Ну и само собой, трейсеры исключений дадут вам и контекст процессора и стек вызовов.
Дополнительные материалы для чтения
Что можно почитать:
- Windows Error Reporting — обсуждение WER API в Windows:
- Using WER
- Windows Feedback Services
- WER Reference
- Configuring Automatic Debugging — администрирование WER и посмертного отладчика:
- Enabling Postmortem Debugging
- WER Settings
- Collecting User-Mode Dumps
- How to: Configure Microsoft Error Reporting
- Windows Error Reporting: Getting Started — обсуждение использования сайта WER / WinQual / SysDev:
- How WER collects and classifies error reports
- Providing Solutions to Reported Errors
P.S. Блиииин, как же я увлёкся. А ведь просто хотел написать про регистрацию в WER.
Windows Error Reporting is a service that allows users to send all the operating system errors, alerts related content to Microsoft. The error reporting service is intended to help the user to ensure the PC works optimally.
When Your PC/Laptop hangs or crashes then OS immediately sends an error report to Microsoft automatically. If the solution is available then Microsoft will send you fixes but if not then they try to find the solutions.
And in every Windows version, the service is enabled by default, so whenever you will face any error then the Windows system sends an error report to Microsoft automatically.
Windows Error Reporting is enabled by default. And when you send general information about errors than Microsoft (For more you can visit the official page: https://technet.microsoft.com/en-us/library/cc754364(v=ws.11).aspx) will send back either the most current fix or use the information to find a perfect solution for the related issue.
Well, the Windows error reporting feature always prompt you to send the information about the problem to Microsoft whenever a certain program or operating system encounter issues.
And this is the reason many users are searching how to disable error reporting feature, in order to:
- Prevent the system from sending private information about your computer to Microsoft
- To avoid annoying alerts along with the error message
- The error reporting can’t help to fix the problem all the time.
The Microsoft Error Reporting service becomes irritating sometimes and becomes necessary to stop this service.
So, in this article, I am sharing with you the best possible ways on how to disable or enable error reporting services on Windows 10 as well as Windows 8 & 7.
Well, you can disable the error reporting in Windows 10 in three different ways. Follow the steps listed to disable the service easily.
Step 1 – Disable Error Reporting via Registry Editor
If you are good at following the commands then follow the steps listed to disable Windows Error Reporting service through the Registry Editor.
Follow the steps to do so:
- Press Windows + R key > to type regedit > click OK
- Now in the Registry Editor > locate the listed address
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting.
- Then right-click the Windows Error Reporting key > click New > DWORD (32-bit) Value.
- Now right-click on the new DWORD value > rename it to Disabled.
- Next double click on it > to set the value data to 1 > click OK for saving the changes.
Well, the Windows Error Reporting is successfully disabled on your Windows 10 system. Now open the Control panel and verify the error reporting service status, it must be changed from On to Off.
Step 2 – Disable Windows Error Reporting via Services
If you are Windows 10 user then learn how to turn off Windows error reporting service in Windows 10 through services:
- Press Windows + R button > to open Run box > type services.msc > press Enter key
- Now search for the Windows Error Reporting Service > right-click on the entry from the list.
- After right-clicking, you need to select the Properties option.
- Go to the Startup type and from the dropdown menu choose Disabled.
- Click OK or Apply to save the modifications.
- Exit from the Services window and reboot your system.
The Error Reporting service in Windows 10 is disabled now.
Step 3 – Turn off Windows Error Reporting via Group Policy
Here follow the steps to disable the Windows error reporting service through the group policy.
- Press Windows + R keys > and in the Run box type gpedit.msc > click OK
- Now in the Group Policy editor> browse to Computer Configuration and click Administrative Templates and Windows Components > click Windows Error Reporting.
- Then on the right-side click on Settings and locate the Disable Windows Error Reporting option > double click on it.
- Select Enabled > Apply > OK for saving changes.
Now the Windows error reporting feature is disabled successfully on Windows 10.
How to Disable Error Reporting in Windows 8 & Windows 7?
Well, the steps to disable error reporting service is same for the both Windows 8 and 7 OS. So, follow the steps given carefully.
- Go to the Control Panel and click on the System and Security link.
- Click on the Action Center link.
- Now, in the Action Center window, click/tap the Change Action Center settings link on the left.
- Click on the Problem reporting settings link present in the “Related settings” section at the bottom of the “Change Action Center settings” window.
Here you will found four Problem Reporting Settings options:
-
- Automatically check for solutions (the default option)
- Automatically check for solutions and send additional report data, if needed
- Each time a problem occurs, ask me before checking for solutions
- Never check for solutions
- Select Never check for solutions will completely disable error reporting in Windows.
Note: If you want to partially disable this service then you should choose Each time a problem occurs, ask me before checking for solutions.
- After it, click the OK button present at the bottom of the window.
- Click the OK button present at the bottom of the Change Action Center settings window.
- After all, exit from the Action Center window.
The Windows error reporting feature is disabled successfully now.
Now if after disabling the Windows error reporting feature on Windows 10, wondering how to enable service in Windows 10, then learn how to do so:
How to Enable Windows Error Reporting in Windows 10?
If you are looking to enable error reporting service in Windows 10 then simply follow the below-given steps:
- Press Windows + R keys > click on the Run after it type oobe and > press Enter.
- Click on the Enable automatic updating and feedback in the Update This Server area.
- Click on the Manually configure settings.
- After it, in the Windows Error Reporting area of the Manually Configure Settings dialog box, click on the Change Setting.
- Now you need to configure the Windows Error Reporting Service, in the Configuration dialog box select one of the following options.
-
- Yes, automatically send detailed reports
- Yes, automatically send summary reports
- Save them by clicking on OK
- On the Manually Configure Settings dialog box, click Close.
And that’s it now your Windows error reporting service is enabled in Windows 10 OS.
Is it Safe to Disable Windows Error Reporting Service?
Well, disabling the Windows error reporting service won’t impact the system performance but if everyone starts disabling the windows error reporting then this will be harder for Microsoft to know about the background problems encountered by the users.
And ultimately getting immediate support and improvements may get delayed.
Make Your Windows PC/Laptop Error-Free
Well if you are encountering various Windows PC/laptop errors or your system is running slow then here it is suggested to scan your system with the PC Repair Tool.
This is an advanced repair tool, that just by scanning once detect and fix various PC problems including BSOD error, repair the corrupted Windows system files, DLL errors, registry errors, prevent virus or malware infection, and much more.
This not only fixes errors but also optimizes your Windows PC performance like a new one to optimize the gaming performance.
Get PC Repair Tool, to make your PC Error-Free & Speed up
Conclusion:
Well, the Windows Error Reporting service is one of the useful things and it helps the user to fix the appeared issue.
But, if in case you want to get rid of Error Report Service notification along with the errors or have concerns about privacy then you should immediately disable the error reporting service.
Here, you can follow the steps to apply the steps based on different Windows versions and avoid the error reporting service to fetch any personal information.
Hope the article works for you.
Hardeep has always been a Windows lover ever since she got her hands on her first Windows XP PC. She has always been enthusiastic about technological stuff, especially Artificial Intelligence (AI) computing. Before joining PC Error Fix, she worked as a freelancer and worked on numerous technical projects.