Windows Error Reporting and Internet Communication (Windows Server 2003)

Applies To: Windows Server 2003 with SP1

This section provides information about:

• The benefits of Windows Error Reporting

• How Windows Error Reporting communicates with sites on the Internet

• How to control Windows Error Reporting to prevent the flow of information to and from the Internet

Benefits and Purposes of Windows Error Reporting

The Windows Error Reporting feature in Microsoft Windows Server 2003 family operating systems provides a service which allows Microsoft to track and address errors relating to the operating system, Windows components, and applications. This service, called the Error Reporting service, gives administrators and users with administrative credentials the opportunity to send data about errors to Microsoft and to receive information about them. Moreover, developers can use the Error Reporting service as a problem-solving tool to address customer problems in a timely manner and to improve the quality of Microsoft products.

In addition to having users or administrators send information to Microsoft, in some cases Microsoft may provide information, such as a way to work around a problem or a link to a Web site for updated drivers, patches, or Microsoft Knowledge Base articles.

Overview: Using Windows Error Reporting in a Managed Environment

In Windows Server 2003 family operating systems, error reporting is enabled by default and you can report system and application errors to Microsoft if you choose to. When an error occurs, a dialog box is displayed, giving you the option to report the problem. If you choose to report the problem, technical information about it is collected and then sent to Microsoft over the Internet. No information is sent unless you confirm that the error report be sent to Microsoft.

On Windows Server 2003 family operating systems you can configure or disable error reporting through the Control Panel\System\Advanced tab. You can configure error reporting to send specified information such as system errors only, unplanned shutdowns, or errors for Windows components, such as Windows Explorer, Paint, or Microsoft Internet Explorer. You can also send information for applications, such as Microsoft Word. An operating system error causes the computer to display a Stop error screen with error values. An application or component error causes the application or component to stop working.

The default settings for the Windows Server 2003 family are:

• Enable error reporting for the operating system, unplanned computer shutdowns, and applications.

  For application errors, you can configure error reporting in one of two ways: either have the error reporting dialog box appear as soon as an error occurs for any user, or do not have the dialog box appear until the next time an administrator logs on.

  Windows treats operating system errors and unplanned shutdowns differently from the way it treats application errors. If an operating system error or unplanned shutdown occurs, Windows writes the error information to a log file. The next time an administrator logs on, the error reporting dialog box prompts them to report the error.

• Force queue mode for application errors.

  The queued mode displays the last ten errors the next time the administrator logs on to the computer. Each error is displayed in its own window so the administrator can choose the errors to report to Microsoft. In this mode errors are displayed only to an administrator; if users logged on to the server they would not see the errors.

Since error reporting is a valuable service, we do not recommend that IT administrators disable it, but that they control what information is reported and where it is sent. For an organization where privacy is a concern, we recommend that the IT department review and filter error reports before they are sent to Microsoft. The best method to use to prevent the automatic flow of error reporting information to and from the Internet is to redirect error reports to a server on your intranet by using Group Policy and to set up Corporate Error Reporting (CER). You can configure error reporting to control various aspects of how errors are reported.

IT administrators can use the Corporate Error Reporting tool to manage error reports that have been redirected to a network server. You use the tool to review the redirected error reports and then filter the reports that are sent to Microsoft based on your policies and the data contained within the error report. The tool is also useful for determining the types of problems users are experiencing most often.

If you have not yet deployed the operating system, you can use unattended installation files to configure error reporting in the same way as in Group Policy. If it is necessary in your organization to completely disable Windows Error Reporting you can do so with the unattended installation file or with Group Policy. For more information about these methods, see "Controlling Error Reporting to Prevent the Flow of Information to and from the Internet," later in this section.

How Windows Error Reporting Communicates with Sites on the Internet

The data that Microsoft collects is used strictly for the purpose of tracking down and solving problems that users or administrators are experiencing. The information is stored in a secure database with limited access. This subsection describes various aspects of the data that is sent to and from the Internet during error reporting, and how the exchange of information takes place.

• Specific information sent or received: Microsoft collects various types of information related to two types of errors, user mode or application errors, and kernel mode or operating system failures. Some information that uniquely identifies the user might inadvertently be collected as part of the crash report. This information, if present, is never used to contact a user. The specific data collected is described later in this subsection. Also, Microsoft may send information about a problem, including links to Web sites.

• Default and recommended settings: Error reporting for application and system errors is enabled by default. For more information about recommended settings, see "Controlling Error Reporting to Prevent the Flow of Information to and from the Internet," later in this section.

• Triggers: The opportunity to send an error report is triggered by application or system errors.

• User notification: A dialog box appears notifying users that an error has occurred and asks if they want to send an error report to Microsoft. Users can review the data that will be sent.

• Logging: Descriptions of system and application errors are recorded in the event log.

• Encryption: All data that could include personally identifiable information is encrypted (HTTPS) during transmission. The "crash signature," which includes such information as the application name and version, module name and version, and offset (location) is not encrypted.

• Access: Microsoft employees and contingent staff who have submitted a business justification for reviewing the information are granted access to the data.

• Privacy statement: The privacy statement for Microsoft Error Reporting is located at the following Web site:

  https://go.microsoft.com/fwlink/?LinkId=825

  Details related to privacy of data are presented in "Types of data collected," later in this section.

• Transmission protocol and port: The transmission protocol is HTTP and the ports are HTTP 80 and HTTPS 443.

• Ability to disable: The feature can be disabled through Group Policy or by administrators on individual servers.

Types of errors reported

There are two types of errors that are reported, user mode and kernel mode.

User mode reporting

When a user mode error occurs, such as an application error, the Error Reporting service does the following:

• Displays an alert stating that the operating system detected a problem.

  Users can choose to report the problem or not. If they do report it, they will see that the information is being sent to Microsoft.

• Sends a problem report to Microsoft.

  Users may then be queried for additional computer information and again may choose to send it or not. If they choose to do so, the Error Reporting service sends the error report to Microsoft. Users might be prompted to provide additional information to complete the error report. When the process is complete, users have the option of selecting More Information, which directs them to updated drivers, patches, or Microsoft Knowledge Base articles.

If the error report indicates that one or more non-Microsoft products were involved in causing the problem, Microsoft may send the report to the respective companies. Qualified software or hardware developers (employed by Microsoft or one of its partners) will analyze the fault data and try to identify and correct the problem.

Kernel mode reporting

When a kernel mode or system error occurs, Windows displays a Stop message and writes diagnostic information to a memory dump file. When you restart your computer using normal mode or Safe Mode (with networking) and log on to Windows, the Error Reporting service gathers information about the problem and displays a dialog box that gives you the option of sending a report to Microsoft.

Types of data collected

The Error Reporting service collects Internet Protocol (IP) addresses, which are not used to identify users. It does not intentionally collect anyone's name, address, e-mail address, computer name, or any other form of personally identifiable information. It is possible that such information may be captured in memory or in the data collected from open files, but Microsoft does not use it to identify users.

In rare cases, such as problems that are especially difficult to solve, Microsoft may request additional data, including sections of memory (which may include memory shared by any or all applications running at the time the problem occurred), some registry settings, and one or more files from the user's computer. The user's current documents may also be included. When additional data is requested, the user can review the data and choose to send the information or not.

The specific type of data that is collected when application errors or kernel failures occur is as follows.

Application errors

If you have an application error the Error Reporting service collects the following information:

• The Digital Product ID, which can be used to identify your license.

• Information regarding the condition of the computer and the application at the time the error occurred. This includes data stored in memory and stacks, information about files in the application's directory, as well as the operating system version and the computer hardware in use. This information is packaged into what is called a "minidump." The minidump contains the following:

  • Exception information: This is information regarding the problem that occurred; it tells Microsoft what kind of instruction the application received that caused it to generate an error.

  • System information: This is data about the kind of CPU (processor) you have and what operating system you are running.

  • A list of all the modules that are currently loaded and their version information.

  • A list of all the threads that are currently running. For each thread, the current context and the whole stack are collected.

  • Global data.

  The minidump data is shown as a hexadecimal representation that the user cannot read.

  Note

Note
For the exact specification of the minidump format, see the Microsoft Platform SDK, which is available on the Microsoft Developers Network (MSDN) Web site.

</div></td>
</tr>
</tbody>
</table>

Windows kernel failures

Windows kernel fault reports contain information about what your operating system was doing when the problem occurred. These event reports contain the minimum information that can help to identify why the operating system stopped unexpectedly. The report includes:

• The operating system name (for example, Microsoft Windows 2000).

• The operating system version (for example, 5.1.2426 0.0).

• The operating system language as represented by the locale identifier (LCID) (for example, 1033 for United States English). This is a standard international numeric abbreviation.

• The loaded and recently unloaded drivers. These identify the modules used by the kernel when the Stop error occurred, and the modules that were used recently.

• The list of drivers in the Drivers folder on your hard disk, that is, systemroot\System32\Drivers.

• The file size, date created, version, manufacturer, and full product name for each driver.

• The number of available processors.

• The amount of random access memory (RAM).

• The time stamp that indicates when the Stop error occurred.

• The messages and parameters that describe the Stop error.

• The processor context for the process that stopped. This includes the processor, hardware state, performance counters, multiprocessor packet information, deferred procedure call information, and interrupts (requests from software or devices for processor attention).

• The process information and kernel context for the halted process. This includes the offset (location) of the directory table and the database that maintains the information about every physical page (block of memory) in the operating system.

• The process information and kernel context for the thread that stopped. This information identifies registers (data-storage blocks of memory in the processor) and interrupt request levels, and includes pointers to data structures for operating system data.

• The kernel-mode call stack for the interrupted thread. This is a data structure that consists of a series of memory locations and includes a pointer to the initial location.

Controlling Error Reporting to Prevent the Flow of Information to and from the Internet

To prevent the automatic flow of information to and from the Internet when users and administrators report errors, you can configure error reporting in two ways: while deploying the operating system using answer files with unattended or remote installation, or after deployment using Group Policy. There may be some aspects of error reporting you want to configure using answer files, and others you may want to configure using Group Policy. Review the tables in this subsection to determine the configuration options that will work best for your organization.

Using unattended installation

You can configure error reporting by using standard methods for unattended or remote installation. You use the [PCHealth] section of an answer file to make entries for this feature. The following table describes those entries.

Entries for configuring error reporting in an answer file (for unattended installation)

For complete details about the entries for error reporting, see the resources listed in Appendix A: Resources for Learning About Automated Installation and Deployment (Windows Server 2003). Be sure to review the information in the Deploy.chm file (whose location is provided in that appendix).

Using Group Policy

To enable Corporate Error Reporting, perform these steps:

• Configure the Error Reporting policy settings in Group Policy so that error reports go to a server on your intranet.

• Use the Corporate Error Reporting tool to filter reports.

Enable error reporting through Group Policy so you can override actions users or administrators might take, and so you can redirect error reports to a server on your intranet instead of to the Internet. Once you have initiated Corporate Error Reporting, you can use this tool to manage error reports.

In addition to the Error Reporting policy settings, this subsection also includes a list of the Advanced Error Reporting policy settings you may want to use for additional configuration options.

Using Error Reporting policy settings

To configure servers for Corporate Error Reporting you need first to enable the Report Errors policy setting. Once you enable this policy setting, you can enter a file path to a server on your intranet, limit data that is exchanged on the Internet when errors are reported, control how users and administrators interact with the Error Reporting service, and take other steps to control information.

For details about locating the error reporting policy settings, see "Procedures for Configuring Error Reporting," later in this section. The following table describes the policy settings.

Group Policy settings for configuring error reporting

Using Advanced Error Reporting policy settings

When you enable error reporting you can choose to specify the types of errors that are reported. In a highly managed environment administrators might want to do this based on the kinds of information included in the error report (see "Types of data collected," in the previous subsection).

With Advanced Error Reporting you can configure the following policy settings:

• Default application reporting settings

• List of applications to always report errors for

• List of applications to never report errors for

• Report operating system errors

• Report unplanned shutdown events

These policy settings are located in Computer Configuration\Administrative Templates\System\Error Reporting. When you configure these policy settings they will override any adjustments to error reporting administrators might make through Control Panel. You can configure these same policy settings in an answer file for unattended installation.

To find more information about editing Group Policy, see Appendix B: Resources for Learning About Group Policy (Windows Server 2003).

How controlling error reporting can affect administrators

What administrators will see on a server when an error occurs depends on how you have configured the Error Reporting policy settings. You can have certain administrators sending error reports to your intranet server only and others using CER to filter reports and send selected ones on to Microsoft. On some servers, for example, administrators may see only operating system or unplanned computer shutdown error reports and not application errors. Or, on some servers you might choose not to have error notification on.

Procedures for Configuring Error Reporting

This subsection presents the recommended procedure for enabling Corporate Error Reporting by configuring the Report Errors policy setting in Group Policy, for IT administrators who want to control the information that goes out to the Internet. This subsection also presents steps for configuring error reporting during unattended installation of the operating system by using an answer file.

Use the following procedure to configure the Report Errors policy setting so error reports are sent to a server on your intranet instead of to Microsoft.

To enable Corporate Error Reporting by using Group Policy

1. Use the resources described in Appendix B: Resources for Learning About Group Policy (Windows Server 2003) to learn about Group Policy and the Group Policy Management Console. Apply Group Policy objects (GPOs) to an organizational unit, a domain, or a site, as appropriate for your situation.

2. Click Computer Configuration, click Administrative Templates, click System, and then click Error Reporting.

3. In the details pane, double-click Display Error Notification, and then select Enabled.

4. Click Next Setting, and then under Report Errors, select Enabled.

5. In the Corporate upload file path box, enter a UNC (Universal Naming Convention) path (\\servername\sharename).

To configure error reporting during unattended installation by using an answer file

1. Using the methods you prefer for unattended installation or remote installation, create an answer file. For information about unattended installation, and for details about the entries for error reporting, see the resources listed in Appendix A: Resources for Learning About Automated Installation and Deployment (Windows Server 2003). Be sure to review the information in the Deploy.chm file (whose location is provided in that appendix).

2. In the [PCHealth] section of the answer file, create entries according to the table in "Using unattended installation," earlier in this section. For example, to disable error reporting the entry is:

   [PCHealth]
   ER_Enable_Reporting = 0
   

Related Links

• For more information about Windows Error Reporting, see the article on the Microsoft Developer Network Web site at:

  https://go.microsoft.com/fwlink/?LinkId=29903

• To obtain the Corporate Error Reporting tool, see the Microsoft Web site at:

  https://go.microsoft.com/fwlink/?LinkId=29517

• To read the Microsoft privacy statement for error reporting, see the Microsoft Web site at:

  https://go.microsoft.com/fwlink/?LinkId=825