Understanding WER Data
To optimize the reporting process, the WER error data is divided into first- and second-level data. During first-level communication with the back-end servers, WER determines if more data is needed. If the server returns a request for more data, collection of the second-level data begins immediately. Simultaneously, a second-level consent dialog box is displayed.
First-Level Data
First-level data consists of up to 10 string parameters that identify a particular classification of the problem. This data is stored in the report manifest file, Report.wer, and is initially submitted to the Watson back-end servers. (The Report.wer file is not itself sent-only the parameters are sent.) The included parameters are used to identify a class of problems. For example, the parameters for a crash (Application Name, Application Version, Module Name, Module Version, Module Offset, AppTimeStamp, ModTimeStamp, and ExceptionCode) provide a unique way to accurately classify a crash. The parameters are the only data submitted to the Watson back-end during first-level communication.
Reports are stored in an archive as a folder structure on the system. Each report subfolder contains, at a minimum, the report manifest text file (Report.wer), which describes the contents of the error report. Although the Report.wer file is a simple text file, it is not meant to be human-readable or editable. Any files referenced by the report are also placed in this folder. The following major sections appear in most Report.wer files:
- Version
- Event Information
- Signature
- UI
- State
- Files
- Response
Second-Level Data
Second-level data is additional data that may be needed to diagnose and resolve a particular bucket. Because Microsoft usually needs only a small sample of this verbose data, the secondlevel data is submitted only if the back-end server requests it and the user consents to sharing the data. Second-level data is split into two categories:
- Safe data This is information that the developer feels is unlikely to contain any personal information, such as a small section of memory, a specific registry key, or a log file.
- Other data This encompasses everything that is not safe data, which may or may not contain personal information.
You have the option to always send safe data automatically. Second-level data is specified by the back-end Watson servers and can include, but is not limited to, the following items:
- Minidump file
- Contents of the heap
- Registry Keys
- WMI queries
- Miscellaneous files
More Info For more information about what information can be sent with WER, see the Windows Vista WER Privacy Statement at http://go.microsoft.com/fwlink/?linkid=50163.
Note Beginning with Windows Vista, WER generates minidump files and heap dump files; it does not generate user-mode process dump files. For information about how to generate user-mode process dump files, see Knowledge Base article 931673, "How to create a user-mode process dump file in Windows Vista," at http://support.microsoft.com/kb/931673.
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