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 1) - Error Reporting Cycle, Report Data Overview

- 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:53:32 PM

Windows Error Reporting (WER) is the client component for the overall Watson Feedback Platform (WFP), which allows Microsoft to collect reports about failure events that occur on a user’s system, analyze the data contained in those reports, and respond back to the user in a meaningful and actionable manner.

WER is the technology that reports user-mode hangs, user-mode faults, and kernel-mode faults to the back-end servers at Microsoft and replaces Dr. Watson as the default application exception handler.

Note

WER in Windows Vista has support for any kind of problem event as defined by the developer, not just critical failures as in Windows XP.


1. Overview of Windows Error Reporting

The Watson Feedback Platform is illustrated in the high-level flow diagram in Figure 1, with Windows Error Reporting labeled as the Watson Client.

Figure 1. Watson Feedback Platform flow diagram.


In Windows Vista, the user interface for Windows Error Reporting is the Problem Reports and Solutions Control Panel applet. When installing Vista, you can choose if you would like WER to send basic problem reports automatically. Basic problem reports include only the minimum amount of information necessary to search for a solution. Later you can choose to send additional information automatically as well. The goal of the Problem Reports and Solutions control panel is to provide you with one location to simply and efficiently view the problem events that have occurred on your computer, track your reports, manage responses from Microsoft, and act on these responses to prevent failures in the future.

One significant improvement of Windows Error Reporting in Windows Vista is the concept of queuing. In Windows XP, WER reports could only be sent at the time the event occurred, with few exceptions. In Windows Vista, WER provides a flexible queuing architecture where users, administrators, or WER integrators can determine the queuing behavior of their WER events.

2. Error Reporting Cycle

The cycle begins when a report is generated on a user’s system and completes when a response is returned to the user. Overall, five primary steps are involved in this process:

Reporting

The first step is the creation and submission of the report. This can be triggered by a number of events, including an application crash, application hang, or stop error (blue screen). In Windows Vista, applications can also be designed to define their own custom event types, allowing them to initiate the reporting process when any type of problem occurs.

Categorization

After the back-end servers at Microsoft receive the report, it is categorized by problem typeCategorization may be possible with only the event parameters (text descriptors of the event) or it may require additional data (dumps). The end result of categorization is that the event reported by the customer becomes a Watson Bucket ID. This allows the developers investigating the events to determine the most frequently reported problems and focus on the most common issues.

Investigation

After the problem is categorized, development teams may view the report data via the Watson portal. The Watson portal provides the data necessary to understand high-level trends and aggregate data, such as the top errors reported against an application. It also provides a mechanism to investigate the low-level data that was reported to debug the root cause of the problem.

Resolution

After a developer has determined the root cause of a problem, ideally a fix, workaround, or new version will be created that can be made available to the customer.

Response

The final step is to close the loop with the customer that reported the problem by responding to his report with information he can use to mitigate the issue. A customer may receive a response in two ways:

  • If the issue is understood at the time an error report is submitted, the customer can receive a response in the form of a balloon notification immediately after the categorization step.

  • If the issue is not understood at the time an error report is submitted, but is resolved some time after the report, you will be able to query for updated knowledge of the problem at a later time. Users can also elect to manually check for new solutions using the Problem Reports And Solutions control panel.

3. Report Data Overview

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 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.

Report.wer File

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. Since Microsoft usually only needs a small sample of this verbose data, the second level 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 else, 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:

  • Files

  • Minidump

  • Heap

  • Registry Keys

  • WMI queries

Note

Because of security reasons, report manifests are not allowed to reference files outside the report directory.

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