4. Conceptual Components
Windows Error Reporting consists of the following conceptual components:
Each of the components is discussed in the following sections.
Report Processor
The Report Processor is a conceptual component
that is responsible for managing the state of a report once it has been
sent to WER. Applications use WER APIs to create and submit reports. At
that point, the Report Processor decides whether to queue the report or
submit the report. The Report Processor will attempt to hand over the
report to the Transport System if the following conditions are met:
there is network connectivity, the report is for an interactive
application, and a user interface can be shown. Otherwise, the Report
Processor will hand over the report to the Queue Management system. The
Report Processor will also invoke the user interface component if
applicable.
Data Collection Module
The Data Collection Module is responsible for collecting the following data:
Transport System
WER uses two separate transport modes:
Live Watson Mode In this mode, WER uses a four-stage protocol based on top of HTTP to communicate with the live Watson back-end servers.
Corporate Error Reporting (CER) Mode
In this mode, the target is a file share on a corporate network server.
The primary difference from Live Watson Mode is that the server does
not respond with relevant information, and the client has to read that
information from text files located in the file tree.
Store Management System
The WER Store Management System component is
responsible for maintaining the error report stores (folders) and for
scheduling the prompts that a user will see when there are unsent queued
error reports. WER uses user stores for user-level problems and machine
stores for system-level problems. The type of store affects the WER
prompts that a user sees and the location that the error report data is
stored.
NTFS file compression is enabled by default on the store root folders.
In addition, user and machine stores contain
two subfolders named ReportQueue and ReportArchive. These folders store
the queued (unsent) and archived report contents, respectively. The
actual data for each error report is stored in individual subfolders
within the ReportQueue and ReportArchive folders. When an error report
is generated, the queue subsystem evaluates the WER configuration and
connection status to determine the appropriate store to use. The WER
queuing structure and behavior is discussed later in this section.
User Store
The WER user queue is located in the following folder:
Users\<username>\AppData\Local\Microsoft\Windows\WER
The default WER behavior is to store error
report data in user stores. Error reports are written to the current
user’s store if the following conditions are true:
Reporting failed for any reason other than the user clicking the Cancel button.
The application developer designed the application using WER APIs to specify queuing as the default behavior.
The ForceAdminQueue policy is not enabled.
Computer Store
The WER machine store is located in the following folder:
ProgramData\Microsoft\Windows\WER
You can configure WER by using Group Policy or
the registry to force all error report data to be written to the
machine store. Reports are written to the machine store if either of the
following conditions is true:
ReportQueue Folder
The ReportQueue folder contains reports that
are queued for sending at a later time. These reports have either the
necessary consent and are pending a network connection for upload, or
they need consent from the user before they can be uploaded. When a
report has been successfully uploaded, it is removed from the
ReportQueue folder. This folder is referred to as the Upload or Signoff
queue. Once a report is successfully submitted, the report, along with
any uploaded data, is copied into the archive store.
Note that when the error data is initially
collected and before it is queued, the collected error report files are
stored in subfolders within the following folder:
Users\<username>\AppData\Local\Temp
ReportArchive Folder
The ReportArchive folder contains reports that
have been uploaded or denied upload (via policy or explicit user
action). This folder is referred to as the Archive store. Reports that
are successfully submitted from the queue store(s) are automatically
transferred to the archive store.
You can also create an Event Reporting Console
(ERC) folder in the WER store folder(s). The subfolders in the ERC
folder store response metadata and templates used for displaying the
response data in the Problem Reports And Solutions control panel. You
don’t need to modify the data in the ERC folder, and modifying the data
is not supported.
Queue Reporting
When a new error report is successfully
submitted to any of the queues or directly to the Watson back-end
servers, WER launches into a queue reporting mode. In queue reporting
mode, WER will prompt you to send the queued report(s) if conditions
permit. If conditions are not optimal for reporting, WER schedules
itself to be launched when a network connection is established (SENS) or
when the current user logs on the next time (HKCU\Run). This ensures
that at some point in the future when conditions are right for
reporting, infrastructure will be able to show the queued reporting
console.
In queue reporting mode, WER performs the following checks in the order shown:
1. | Is
the failing process running in an interactive desktop? If not,
wermgr.exe terminates. This is necessary because WER dialogs should not
be shown for non-interactive desktops, such as the ones that the service
accounts own.
|
2. | Does
the current user have reports in her queue or is the current user an
administrator and is administrative queuing enabled? If neither of the
conditions is true, the current user has no reports to report. In this
case, WER will ensure that network and logon triggers for the current
user are removed and it will exit immediately. If either of the
conditions is true, WER attempts to prompt you to report entries in the
queue.
|
3. | Set the network and logon triggers for the current user in case conditions are not optimal for reporting at this time.
|
4. | Check network access and see whether the last pester time has expired. If either of these checks fails, wermgr.exe terminates.
|
5. | Launch the Problem Reports And Solutions control panel to prompt you and update the last pester time.
|
Store Maintenance
By default, the Queue Management System
performs maintenance such as deleting stale data and trimming the size
of the queue on a report store whenever 50 saved reports are in the
store. When the total queued report count exceeds the number defined in
the registry value MaxQueueCount or the registry value MaxArchiveCount
for archive stores, the queue subsystem deletes the oldest CAB files
from the queues in the following order until the size of the queue
reaches MaxQueueCount or no more CABs remain to delete:
The metadata for a report is persisted for one
calendar year unless the user has disabled the archive via the
DisableArchive setting.
WER queue data retention policies can be
configured using Group Policy. If no queuing policies are configured,
the Archive queue will retain 1000 reports and the Upload/Signoff queue will
retain 50 reports. If a queue becomes full and a new report is created,
the new report will overwrite the oldest report in the respective queue
(FIFO).
Queue Triggers
This section describes the launch triggers
that WER uses to ensure that the queued reporting prompt is launched for
users when they have unsent reports in their queues. Triggers are
persistent across reboots.
WER launch triggers include:
Network trigger
This trigger launches WerMgr.exe in queue reporting mode for a specific
user when a network connection is established. The network trigger is
implemented through the SENS API that senses the presence of a network
connection.
Logon trigger
This trigger launches WerMgr.exe in queue reporting mode for a specific
user when the user logs on. Currently, the shell HKCU Run key is used
to implement this feature.
Administrator trigger
The administrator trigger notifies an administrator of unsent entries
in the machine queue. This trigger only occurs for administrators on the
system.
A System Tray popup that says “Check
for solutions: Click to have Windows check online for solutions to
computer problems” will be displayed when queued reports are available
to send.
