Today I’ll write about Windows Error Reporting on Windows Server 2008 R2 / Windows 7, a set of Windows technologies that capture software crash and hang data from end users.
See this post as a summary of what I’ve learned when analyzing Windows Error Reporting feature and it’s ‘shortcomings’
Years ago Microsoft started with fault-detection creating Dr. Watson. Dr. Watson evolved during the last years to a complete Error Reporting feature called Windows Error Reporting. The feature consists of a Windows Service called Windows Error Reporting Service
C:\>sc query WerSvc
SERVICE_NAME: WerSvc
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0×0)
SERVICE_EXIT_CODE : 0 (0×0)
CHECKPOINT : 0×0
WAIT_HINT : 0×0
C:\>services.msc
Image may be NSFW.
Clik here to view.
Additionally there are a few DLLs which can be found in %WinDir%\System32 / %WinDir%\SysWow64.
The Windows Error Reporting feature, respectively WerFault.exe gets triggered if an application terminates unexpectedly. You can change the behavior of the Windows Error Reporting feature using various Windows registry keys:
Here’s an example dialog in Win7 with the usual settings:
Image may be NSFW.
Clik here to view.
If you disable the AeDebug registry key, the JIT debugging option goes away:
Image may be NSFW.
Clik here to view.
If you disable checking for solutions (the only thing you seem to have control over via the control panel), it looks like this, but still appears and still stops the program from dying until the user presses something.WerAddExcludedApplication is documented to also have this effect.
Image may be NSFW.
Clik here to view.
Windows Error Reporting can be configured using GPOs:
Start gpedit.msc, go to Computer Configuration – Administrative Tools – Windows Components – Windows Error Reporting
There you can change/control the behavior of WER.
If you don’t change the configuration of Windows Error Reporting, a crash dump is being written to %ProgramData%\Microsoft\Windows\WER
There you can find a Reporting Queue and a Report Archive:
Image may be NSFW.
Clik here to view.
so far the whole WER feature works good and does not make any problems. BUT, if you change startup type of the Windows Error Reporting Service to Disabled, Windows Error Reporting begins to make problems. If you do so, and a program triggers WerFault.exe, the WerFault.exe Process won’t terminate until you kill it yourself using taskkill /IM werfault.exe or taskmanager. This happens because WerFault.exe tries to start the Windows Error Reporting Service. Since WER Service is disabled and cannot be startet, WerFault.exe remains/hangs…. This is a big shortcoming of WER. Because: imagine you have a windows service which crashes, Werfault.exe is beeing triggered, the crashing process (windows service) can not terminate until werfault.exe reports the fault. you won’t be able to restart the windows service in some ‘constellations’.
we have escalated this to Microsoft Support. They provided us with the solution of preventing WerFault.exe from being run using Image File Execution.. I’m absolutely not a fan of this ‘solution’ it’s more of a workaround..
Resolution
If you need to ensure that Werfault.exe will never be spawned when an unhandled exception is encountered, you can choose one of the following resolution paths.
1) Create a software restriction policy (via local policy or Domain GPO) to disallow Werfault.exe for all users.
Or
2) Use Image File Executions Options to cause Werfault.exe to be executed under a non-existent debugger(NUL). Since NUL can’t be found, the process fails to launch.
(REG ADD “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Werfault.exe” /v Debugger /t REG_SZ /d NUL /f)
