Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Maintaining Desktop Health : Understanding Windows Error Reporting (part 2) - Conceptual Components

- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
4/19/2013 6:54:25 PM

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:

  • Heap dump data

  • WMI query results

  • Registry key data

  • Registry tree data

  • Files

  • File version information

  • User documents

  • Minidump

  • Microdump (A minidump that has been stripped of all other information except the faulting stack trace)

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:

  • The process submitting the report is not running in an interactive desktop (includes system services).

  • The ForceAdminQueue policy is enabled.

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:

  1. Archive Store

  2. Signoff Queue

  3. Upload Queue

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.

Other -----------------
- Maintaining Desktop Health : Using Performance Information And Tools
- Maintaining Desktop Health : Understanding the Windows System Assessment Tool
- Maintaining Desktop Health : Understanding Windows Eventing (part 2) - Event Viewer User Interface
- Maintaining Desktop Health : Understanding Windows Eventing (part 1) - Windows Eventing Capabilities
- Using Voice and Sounds : Associating a Sound with an Event, Using Alternatives to Sound
- Using Voice and Sounds : Letting Your Computer Do the Talking, Creating a Sound File
- Managing Windows Licensing and Activation : Notification Experience and Reduced Functionality Mode
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 3) - Managing licensing and activation, Implementing KMS activation
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 2) - Leveraging MAK activation, Comparing KMS and MAK activation
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 1) - Centralizing activation with KMS
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server