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 where the error report data is stored. 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, which are compressed by default using NTFS compression. 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 store 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 Cancel.
- 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 computer 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.
Report Queue 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. After a report is successfully submitted, the report, along with any uploaded data, is copied into the ReportArchive folder.
The location of the ReportQueue folder is either of the following:
- Users\<username>\AppData\Local\Microsoft\Windows\WER\ReportQueue (for reports in the user store)
- ProgramData\Microsoft\Windows\WER\ReportQueue (for reports in the computer store)
Note that when the error data is collected initially and before it is queued in the Report- Queue folder, the collected error report files are stored in subfolders within the following folder:
Users\<username>\AppData\Local\Temp
In this tutorial:
- Windows 7 Desktop Maintenance
- Performance Monitoring
- Improvements to Performance Monitoring in Windows 7
- Using Performance Monitor
- Real-Time Performance Monitoring
- Performance Monitor Logging
- Creating a Data Collector Set
- Configuring a Data Collector Set
- Using Data Manager to View Performance Data
- Starting and Stopping Data Logging
- Viewing Performance Data
- Comparing Performance Monitor Logs
- Performance Monitor User Rights
- Remote Data Collection
- Using Windows PowerShell for Performance Monitoring
- Resource Monitor
- Overview Tab
- CPU Tab
- Memory Tab
- Disk Tab
- Network Tab
- Reliability Monitor
- How Reliability Monitor Works
- Windows Performance Tools Kit
- Event Monitoring
- Understanding the Windows Event Architecture
- Channels
- Improvements to Event Monitoring in Windows 7
- Using Event Viewer
- Understanding Views
- Viewing Event Logs
- Saving Event Logs
- Configuring Event Subscriptions
- Considerations for Workgroup Environments
- Creating a New Subscription
- Using the Windows Events Command-Line Utility for Event Monitoring
- Using Windows PowerShell for Event Monitoring
- Using Task Scheduler
- Improvements to Task Scheduler in Windows 7
- Understanding Tasks
- Understanding the Task Scheduler Architecture
- Understanding Task Scheduler Security
- Credentials Management
- Securing Running Tasks
- Understanding AT and Task Scheduler v1.0 Compatibility Modes
- Understanding the Task Scheduler Snap-in
- Understanding Default Tasks
- Creating Tasks
- Defining Triggers
- At Startup Trigger
- On Connection To AND Disconnect From User Session Triggers
- On Workstation Lock AND Unlock Triggers
- Defining Actions
- Defining Conditions
- Defining Settings
- Managing Tasks
- Viewing History
- Using SchTasks.exe for Creating and Managing Tasks
- Task Scheduler Events
- Troubleshooting Task Scheduler
- Tasks Won't Run If the Service Is Not Started
- The Task Will Run Only When a Certain User Is Logged On
- The Task Action Failed to Execute
- Interpreting Result and Return Codes
- Understanding the Windows System Assessment Tool
- Understanding WinSAT Assessment Tests
- Examining the WinSAT Features Assessment
- Running WinSAT from the Command Line
- Understanding WinSAT Command Exit Values
- Running WinSAT Using Performance Information and Tools
- System Capabilities Section
- OEM Upsell And Help Section
- Understanding Windows Error Reporting
- Overview of Windows Error Reporting
- How WER Works
- Store Management System
- ReportArchive Folder
- WER Service
- Understanding the Error Reporting Cycle
- Understanding WER Data
- Configuring WER Using Group Policy
- Configuring WER Using the Action Center