Here are the influential voices leading the conversations where nonprofits and technology overlap.
In my experience using Windows Vista, it has for the most part been a solid and reliable platform. But when a hang or crash occurs, Vista is able to automatically send relevant information about the failure to Microsoft, have this information analyzed and obtain a solution to the problem if one exists. The underlying technology for doing this is called the Watson Feedback Platform (WFP); the client component on Vista that handles this is called Windows Error Reporting (WER), which replaces the Dr. Watson component that was used in previous versions of Windows.
WER in Vista has some significant improvements over Dr. Watson. For instance, when a user-mode fault or hang occurs in Windows XP, the failure data can’t be queued and must be sent immediately for analysis. Vista, however, can queue WER reports for later submission, and this is configurable by administrators. Also, previous Windows platforms had no user-friendly interface for managing Watson reports and solutions. Vista, however, has an easy-to-use Control Panel (CPL) applet dedicated to this purpose, called Problem Reports and Solutions (Figure 1).
Figure 1: Problem Reports and Solutions CPL
For small businesses that have standalone Vista computers belonging to a workgroup, the easiest way of configuring WER is to use the CPL. Clicking the Change Settings link (Figure 1) displays a screen that lets you choose between automatically sending reports and checking for solutions when a problem occurs (the default setting) or presenting the user with the option of doing. Clicking the Advanced Settings link on this second screen opens a third screen that lets you configure other WER properties (Figure 2), such as whether to automatically send additional in-depth (“second-level”) information that might be needed to resolve a particular failure or whether to ignore problems caused by specific programs by adding these programs to the block list. Tweaking these settings lets you determine how WER responds to failures on your computer and how much information is sent to Microsoft for analysis.
Figure 2: Configuring advanced WER settings using the CPL
Businesses that have Vista deployed in managed environments with Active Directory can configure the WER settings of Vista client computers using Group Policy. Advanced users of standalone computers can also use Local Group Policy to access the same WER policy settings, although this requires knowledge of administrator credentials because a UAC prompt is involved. The advantages of configuring WER using policy are twofold: First, administrators can lock in the configurations they want, which simplifies administration; second, there are many more additional WER settings that can be configured by policy and that aren’t revealed by the Problem Reports and Solutions user interface.
Per-machine WER policy settings for Vista are found under Computer Configuration > Administrative Templates > Windows Components > Windows Error Reporting (Figure 3).
Figure 3: Per-machine WER policy settings.
Using Group Policy gives you a lot of granularity in how you configure WER on your Vista client computers. For instance, the policy Computer Configuration > Administrative Templates > Windows Components > Windows Error Reporting > Advanced Error Reporting > Configure Report Queue (Figure 4) lets you queue up WER reports instead of sending them to Microsoft, notifying you at a time period you specify with a balloon popup.
Figure 4: Configure Report Queue policy
Group Policy (or Local Group Policy) also lets you configure some (but not all) of the WER settings on a per-user basis. This can be useful if you have computers that are shared by different users who have different needs. The per-user policy settings for WER are found under User Configuration > Administrative Templates > Windows Components > Windows Error Reporting.
You can also configure WER settings by hacking the registry, but generally this is not recommended — if you make a mistake, you could render your system unstable or unable to boot. However, If you decide you want to try this, the relevant registry values are found under HKLM > Software > Microsoft > Windows > Windows Error Reporting (for per-machine WER registry settings) and HCU > Software > Microsoft > Windows > Windows Error Reporting (for per-user WER registry settings). Note that editing the registry on Vista requires administrator credentials (there’s that pesky UAC prompt again), and if your computer belongs to a domain, then any Group Policy settings for WER that are configured will overwrite any registry settings you define.
How can you find out more about each specific WER policy setting or registry value? The best place to start is the Windows Vista Resource Kit from Microsoft Press, which has a comprehensive section on WER in Chapter 22, “Maintaining Desktop Health.” There you’ll find detailed information concerning each WER registry value and its corresponding policy setting, plus an in-depth description of the WFP architecture, error reporting cycle and WER components.
A frequent question I’m asked is, “What information does WER send to Microsoft?” In an age of increasing concerns about privacy, it’s simple due diligence to want to know whether Microsoft is collecting any confidential information when you have WER enabled on your computers. The simple answer is that by default the only data sent to Microsoft is information that is needed to identify the nature and cause of the problem. This “first-level” data includes the application name, application version, module name and time stamps. The WER information for each problem is summarized in the form of a report manifest file named report.wer, which is archived in a subfolder (uniquely named for each problem) under C:\ProgramData\Microsoft\Windows\WER\ReportArchive or C:\Users\<username>AppData\Microsoft\Windows\WER\ReportArchive. Figure 5 shows an example of such a report that was generated by the Plug and Play (PnP) service detecting a device for which Vista didn’t have a driver.
Figure 5: Example of a WER report manifest file
In this instance, WER uploaded this information to Microsoft, a suitable device driver was found and installed, and the issue was resolved (Figure 6).
Figure 6: Problem solved
Double-clicking on the highlighted problem in Figure 6 will essentially display the same information found in the report.wer file shown in Figure 5.
If you decide to allow WER to send more detailed, second-level information to Microsoft, this information could include (but would not be limited to) files on your system, a system minidump, the contents of your heap, registry keys and information obtained through WMI queries. If you’re concerned about any of this, click the link Read Our Privacy Statement Online at the bottom left of the Problem Reports and Solutions CPL (Figure 1) and you’ll be taken to Microsoft’s privacy statement concerning WER.