Tài liệu Windows 7 Resource Kit- P22 ppt

Using Task Scheduler CHAPTER 21
1003
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\Windows\System32\calc.exe</Command>
</Exec>
</Actions>
</Task>
Importing Tasks
Tasks that have been exported can also be easily imported to another computer or the same
computer.
To import a task, follow these steps:

1. Right-click a task folder under the Task Scheduler Library and then select Import Task,
or select Import Task in the Action pane.
2. Browse to where the .xml file is located and click Open. The task will be automatically
imported into the library using the settings contained in the .xml file.
note To ensure that the task runs properly, it is recommended that you verify the prop-
erties of the task after you import it.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1004
Using SchTasks.exe for Creating and Managing Tasks
This section describes the SchTasks.exe command-line syntax and parameters. The Schtasks.exe
command-line interface utility allows an administrator to create, delete, query, change, run,
and end scheduled tasks on a local or remote system through the command shell.
Command Syntax
The SchTasks.exe command interface uses the following syntax:
SCHTASKS /<parameter> [arguments]
Command Parameters
The available parameters for SchTasks.exe are as follows:
n
/Create Creates a new scheduled task
n
/Delete Deletes the scheduled task(s)
n
/Query Displays all scheduled tasks
n
/Change Changes the properties of the scheduled task
n
/Run Runs the scheduled task immediately
n
/End Stops the currently running scheduled task

n
/? Displays a help message
Creating Tasks
The general syntax for Schtasks.exe is as follows:
SCHTASKS /Create [/S system [/U <username> [/P [<password>]]]] [/RU <username>
[/RP <password>]] /SC schedule [/MO <modifier>] [/D <day>] [/M <months>]
[/I <idletime>] /TN <taskname> /TR <taskrun> [/ST <starttime>] [/RI <interval>]
[ {/ET <endtime> | /DU <duration>} [/K] [/XML <xmlfile>] [/V1]] [/SD <startdate>]
[/ED <enddate>] [/IT] [/Z] [/F]
The following is an example command.
SCHTASKS /Create /S system /U user /P password /RU runasuser /RP runaspassword
/SC HOURLY /TN rtest1 /TR notepad
Deleting Tasks
The general syntax for deleting a task is as follows:
SCHTASKS /Delete [/S <system> [/U <username> [/P [<password>]]]] /TN <taskname>
[/F]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Using Task Scheduler CHAPTER 21
1005
The following is an example command.
SCHTASKS /Delete /TN "Backup and Restore”
Running Tasks
The general syntax for running a task is as follows:
SCHTASKS /Run [/S <system> [/U <username> [/P [<password>]]]] /TN <taskname>
The following is an example command.
SCHTASKS /Run /TN "Start Backup"
Ending Tasks
The general syntax for ending a task is as follows:
SCHTASKS /End [/S <system> [/U <username> [/P [<password>]]]] /TN <taskname>
The following is an example command.

SCHTASKS /End /TN "Start Backup"
Querying Tasks
The general syntax for querying a task is as follows:
SCHTASKS /Query [/S <system> [/U <username> [/P [<password>]]]] [/FO <format>]
[/NH] [/V] [/?]
The following is an example command.
SCHTASKS /Query /S system /U user /P password
SCHTASKS /Query /FO LIST /V
Changing Tasks
The general syntax for changing a task is as follows:
SCHTASKS /Change [/S <system> [/U <username> [/P [<password>]]]] /TN <taskname>
{ [/RU <runasuser>] [/RP <runaspassword>] [/TR <taskrun>] [/ST <starttime>]
[/RI <interval>]
[ {/ET <endtime> | /DU <duration>} [/K]] [/SD <startdate>] [/ED <enddate>] [/ENABLE |
/DISABLE] [/IT] [/Z] }
The following is an example command.
SCHTASKS /Change /RP password /TN "Backup and Restore"
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1006
Task Scheduler Events
In Windows Server 2003 and earlier versions, scheduled tasks used a Schedlgu.txt log file to
track tasks and their status. Windows Vista implements all new event logs for applications,
and Task Scheduler now logs all operational information about scheduled tasks into its own
event log. The Scheduled Tasks event log Microsoft-Windows-TaskScheduler is located under
Application Logs. Important errors or warnings about task or service failures are logged to
the System log so that administrators can readily see them and take action.
Task Scheduler 2.0 will normally log an event on task registration (at creation), at task
launch, and when the task instance has been sent to the engine. Events will also be logged on
task failures and any task-related problems. This section provides examples of typical events

that are logged by the Scheduled Tasks service.
Task Registration
An Event ID 106 is logged when a task is created. This event is also referred to as task
registration.
Task Launch
Tasks can be started by either a user request or a trigger. An Event ID 110 is normally logged
when a user manually starts a task. An Event ID 107 is normally logged when a task is started
as the result of a trigger.
Task Execution
An Event ID 319 indicates that the Task Engine received a message from the Task Scheduler
service requesting task launch, and it is the best indicator of a task launch. In these events, the
Task Engine is identified by the user SID, and the task name is also logged.
Task Completion
An Event ID 102 is normally logged when a task completes successfully.
Troubleshooting Task Scheduler
Task or service failures are logged to the system event log. It is important to note that the
events will vary and will be based on what failed. A user will see different events based on
whether a task failed to start or if the task started successfully but the action failed.
The key to troubleshooting Task Scheduler is understanding specifically where the failure
occurred in the process. A task is defined as an action, the trigger for the action, the conditions
under which the task will run, and additional settings. The event log will show whether the
failure is in the trigger, the task action, the conditions, or the settings of the task.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Using Task Scheduler CHAPTER 21
1007
Tasks Won’t Run If the Service Is Not Started
If you are having problems scheduling tasks or getting tasks to run correctly, first ensure
that the Task Scheduler service is running. You can run Services.msc to verify that the Task
Scheduler service status is Started.
The Task Did Not Run at the Expected Time

If a scheduled task does not run when you expect it to run, ensure that the task is enabled
and also check the triggers on the task to ensure that they are set correctly. Also, check the
history of the task, as shown in Figure 21-18, to see when the task was started and to check
for errors.
FIGURE 21-18 Task Scheduler History Tab
The Task Will Run Only If All Conditions Are Met
You can set task conditions on the Conditions tab of the Task Properties dialog box. If condi-
tions are not met or are set up incorrectly, the task will not execute.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1008
The Task Will Run Only When a Certain User Is Logged On
If a scheduled task does not run when you expect it to run, review the Security Options set-
tings in the Task Properties dialog box on the General tab.
The Task Executed a Program But the Program Did Not Run Correctly
If a task attempts to execute a program, but the program does not run correctly, first try run-
ning the program manually (not from a task) to ensure that the program works correctly. You
may need to add arguments to the program command or define the Start In path using the
Add Arguments and Start In optional fields.
The Task Failed to Start
An Event ID 101 is normally logged when a task fails to start. In these events, the result code
is also displayed. For more information about result and return codes, see the section titled
“Interpreting Result and Return Codes” later in this chapter.
The Task Action Failed to Execute
When a task starts but the action configured for the task fails to execute, an Event ID 103 or
an Event ID 203 is normally logged. These events also display the return code. For more infor-
mation about result and return codes, see the section titled “Interpreting Result and Return
Codes” later in this chapter.
The Program Specified in the Task Requires Elevated Privileges
If a task is running a program that requires elevated privileges, ensure that the task runs with

the highest privileges. You can set a task to run with the highest privileges by changing the
task’s security options on the General tab of the Task Properties dialog box.
Interpreting Result and Return Codes
To interpret return codes, you can use a tool such as Err.exe, which you can obtain from the
Microsoft Download Center. Err.exe parses source-code header files until it finds a match for
the error. In this regard, the Scheduled Tasks service in Windows Vista still functions quite
similarly to previous versions of Windows. Return codes from events that occur internally are
always translated into hresult code. For example, the logon failed event will contain a result
code that can be interpreted as a hresult. Task handler tasks also return result codes that you
can interpret using the same tools.
However, when an executable is started and fails for an unknown reason, you have no
way of knowing what the result code might mean. The hresult logged in the event log will
typically indicate the value returned to the service from the executable itself, and additional
research and documentation may be required for accurately interpreting the code.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding the Windows System Assessment Tool CHAPTER 21
1009
note You can download Err.exe from the Microsoft Download Center at
/>09e02a13696c. Although this tool is called the Microsoft Exchange Server Error Code Look-
up tool, it actually looks up any Windows operating system error codes.
Understanding the Windows System Assessment Tool
You can use the Windows System Assessment Tool (WinSAT) to assess the features and capa-
bilities of a Windows PC. If the WinSAT scores have not been pre-populated by the original
equipment manufacturer (OEM), then WinSAT will run the following tests:
1. The DWM test during initial install or Out-of-Box Experience (OOBE), to provide the
Desktop Window Manager (DWM) with the video memory bandwidth data used in
determining whether Aero can run on a system.
2. The remaining tests on system idle (as an idle task, to be kicked off by the Task Sched-
uler when the computer is not busy).
In addition, WinSAT checks once a week whether new hardware has been installed on this

machine. If new hardware was installed and the current ratings are outdated, then WinSAT will
run on idle to update the ratings. WinSAT can also be run on demand, when the Re-run The
Assessment option is selected in the Performance Information And Tools Control Panel item.
diReCt FRoM tHe SoURCe
WinSAT Data Files
CSS Global Technical Readiness (GTR) Team
A
dvanced users may want more information regarding the Windows Experience
Index and system performance than is available in the Performance Informa-
tion And Tools Control Panel item. The underlying technology that supports the
Windows Experience Index is the WinSAT. This tool stores the 10 most recent assess-
ments in a data store folder located at:
%WinDir%\Performance\WinSAT\DataStore
The data store consists of XML files that contain information regarding each
assessment. These XML files contain details regarding system performance and
the Windows Experience Index. The files are named by the date and time the
assessments ran.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1010
Understanding WinSAT Assessment Tests
WinSAT performs a variety of assessment tests on the hardware of a computer. These assess-
ment tests include:
n
cpu Measures the computation ability of the processor.
n
d3d The Direct3D (D3D) assessment is targeted at assessing a system’s ability to run
3D graphics; both business graphics and games.
n
disk Measures the performance of disk drives for sequential and random reads, and

for mixed read-write workloads.
n
dwm The DWM assessment is targeted at assessing a system’s ability to run a
Windows–composited desktop, usually referred to as Aero Glass. Note that these are
names of Aero themes. You can run this assessment only on computers with Windows
Display Driver Model (WDDM) video drivers.
n
features Enumerates relevant system information. This assessment is automatically
run once for each invocation of WinSAT.
n
formal Runs the full set of assessments and saves the results in the xml format
needed to populate the Windows Experience Index score and subscores in the
Performance Information And Tools Control Panel item.
n
media Measures the performance of video encoding and decoding.
n
mem Runs system memory bandwidth tests. This is intended to be reflective of large
memory-to-memory buffer copies, like those used in multimedia processing (video,
graphics, imaging, and so on).
n
mfmedia Runs the Media Foundation–based assessment.
Examining the WinSAT Features Assessment
WinSAT automatically runs the Features assessment each time WinSAT runs, to gather the
system information listed. This assessment enumerates system information relevant to the
assessments, including:
n
An optional globally unique identifier (GUID) if the –iguid command-line switch is used.
This ensures that each XML file has a unique identifier.
n
The iteration value from the –iter N command-line switch.

n
The number of processors, cores, and CPUs.
n
The presence of CPU threading technology.
n
x64 capability.
n
The processor signature.
n
The size and other characteristics of the processor’s L1 and L2 caches.
n
The presence of MMX, SSE, and SSE2 instructions.
n
Information on the memory subsystem. (Note that this is very system-dependent:
Some systems will produce good detail here; others will not.)
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding the Windows System Assessment Tool CHAPTER 21
1011
n
Graphics memory.
n
Graphics resolution.
n
Graphics refresh rate.
n
Graphics names and device IDs.
Running WinSAT from the Command Line
Although in most cases, WinSAT will not need to be executed manually from a command
prompt, the general format of the command line is as follows.
winsat <assessment_name> <assessment_parameters>

The WinSAT command-line options are not case sensitive. The command line does not
require a dash or forward slash for the assessment name, but it does support either a lead-
ing dash (–) or a leading forward-slash (/) character to designate an assessment parameter.
WinSAT can be run from a command shell with administrative privileges. An error may be
reported if any options or switches are not supported.
The WinSAT tool also supports several command-line switches in addition to the assess-
ment parameters. These are parsed by WinSAT before it passes control to one or more of the
assessments. Some of these parameters are also supported by one or more assessments. The
command-line parameters recognized by WinSAT include:
n
–csv This causes WinSAT to save the top-level measured metrics to a Comma-
Separated Value (CSV) file.
n
–help or ? Displays the help content.
n
–idiskinfo Information on the disk subsystem (logical volumes and physical disks) is
not normally saved as part of the <SystemConfig> section in the XML output.
n
–iguid Generates a GUID in the XML output file. Note that this is not valid with the
formal assessment.
n
–iter N Includes the iteration number <n> in the XML output file.
n
–v This specifies that WinSAT should produce verbose output. This output includes
progress and status information, and possibly error information. The default is for no
verbose output. This switch is passed to all of the specified assessments.
n
–xml file_name This specifies that the XML output from the assessment is to be
saved in the specified file name. All assessments support the –xml command-line
switch; a pre-existing file with the same name will be overwritten.

Understanding WinSAT Command Exit Values
WinSAT provides the following command exit values:
n
0 All requested assessments were completed successfully.
n
1 One or more assessments did not complete because of an error.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1012
n
2 One or more assessments did not complete because of interference.
n
3 WinSAT was canceled by the user.
n
4 The command given to WinSAT was invalid.
n
5 WinSAT did not run with administrator privileges.
n
6 Another instance of WinSAT is already running.
n
7 WinSAT cannot run individual assessments (for example, D3D or DWM) on Remote
Desktop server.
n
8 WinSAT cannot run a formal assessment on batteries.
n
9 WinSAT cannot run a formal assessment on Remote Desktop server.
n
10 No multimedia support was detected, so the WinSAT tests could not be run.
n
11 This version of WinSAT cannot run on Windows XP.

n
12 The WinSAT watchdog timer timed out, indicating something is causing the tests
to run unusually slowly.
n
13 Can’t run a formal assessment on a Virtual Machine.
diReCt FRoM tHe SoURCe
When Does WinSAT Run?
Server Performance Group
Windows Fundamentals
I
n Windows Vista, all WinSAT tests were run during OOBE (the first-run install or
out-of-box experience) in order to ensure that all systems had detailed ratings, but
it took time (about 3-5 minutes).
In Windows 7, we’ve made the OOBE experience faster; only the DWM WinSAT test
needs to run during OOBE. That test provides the video bandwidth data used by the
DWM to determine whether Aero can be turned on. The remaining WinSAT tests
(other than the DWM test) run as idle tasks.
After the initial scores are populated, WinSAT checks weekly to see whether
hardware has changed sufficiently that the tests should be re-run. Customers can
also choose to manually re-rate the system at any time using Performance Infor-
mation And Tools in Control Panel. By default, WinSAT tracks the history of scores
on a machine. If the hardware components have not changed, the highest score is
maintained. This prevents temporary minor fluctuations in scoring; for example, if
someone re-ran the assessment while a complex application was also running and
competing for resources. To re-rate a system from scratch without taking history
into account, Performance Information And Tools has an Advanced Tools option to
“Clear all Windows Experience Index scores and re-rate the system.”
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding the Windows System Assessment Tool CHAPTER 21
1013

In addition, WinSAT in Windows 7 now supports the new “prepop” syntax. Customers
and partners who update images prior to rolling out installations can generate
winsat.xml files containing scoring data for their particular systems. During OOBE,
WinSAT looks for prepopulated files that match that system configuration. If the files
are present, WinSAT will use them to supply the WinEI scores for Performance Infor-
mation And Tools. Benefits of prepopulation include the following:
n
The DWM test does not run during OOBE, because the corresponding
winsat.xml file is already there.
n
The customer has a complete set of WinEI scores from the start with no need
to wait for the remaining WinSAT tests to run on idle.
n
Components that make decisions based on WinSAT data will have the
information as early as possible so they can modify their behavior based on
prepopulated settings instead of using defaults. For example, SuperFetch is
aware of advances in storage technology and will turn itself off automatically
when the system disk has a WinEI Disk score greater than or equal to 6.5.
(SuperFetch helps the common occurrence in which retrieving data from
disk is relatively slow; when the system disk is extremely fast, SuperFetch
gracefully backs off.)
Running WinSAT Using Performance Information and Tools
If WinSAT has not assessed the system at all, or if hardware has changed since the initial
installation, the Windows Aero Glass features may not be available. If you have installed new
video hardware or other hardware that might affect the system rating, you may need to run
WinSAT from Performance Information And Tools in order to reassess the computer.
To run WinSAT again and reassess the hardware, perform these steps:
1. Click the Action Center icon in the system notification area to open the Action Center.
2. Click the View Performance Information link on the left to display the Performance
Information and Tools Control Panel item, shown here.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1014
3. Click the Re-run The Assessment link at the bottom right. The Windows Experience
Index dialog box will be displayed with a status bar. The reassessment process can take
a few minutes and the screen may flash while the system is being assessed.
note You cannot use Performance Information And Tools in Safe mode.
The main screen of Performance Information and Tools includes the following sections,
from top to bottom:
n
System Capabilities
n
Help links for more information
n
A link to Print detailed system information
n
OEM Upsell And Online Help
You can use Group Policy to configure what is displayed on the Performance Information
And Tools Control Panel for targeted computers. The policy settings for doing this are found
here:
Computer Configuration\Policies\Administrative Templates\System\Performance Control
Panel
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding the Windows System Assessment Tool CHAPTER 21
1015
System Capabilities Section
The System Capability details section contains scores derived from the WinSAT data and
provides the Windows Experience Index scores and subscores for each area. The Windows
Experience consists of the base score (Index) and the subscores for the following areas:
n

Processor
n
Memory (RAM)
n
Primary hard disk
n
Desktop graphics
n
3D and gaming graphics
The base score is a positive integer that starts at 1 and can continue to grow as new
technology comes out. For example, in Windows Vista, the maximum score was 5.9, while in
Windows 7, the maximum score is 7.9. Each of the subscores also has a rating.
The System Capabilities section can be in one of three different states:
n
Unrated The computer has not yet been rated.
n
Normal The computer has been rated and the rating is up to date.
n
Outdated Hardware configuration changed and the Windows Experience Index
score and subscores should be updated.
OEM Upsell And Help Section
The OEM Upsell And Help section provides the following features:
n
An area for OEM suppliers to place their logos and a link to a local page or their Web
sites
n
A link for additional information online
Accessing Advanced Performance Tools
Additional options available on the left side of Performance Information And Tools include:
n

Adjust Visual Effects Opens the Performance Options dialog box
n
Adjust Indexing Options Opens the Indexing Options dialog box
n
Adjust Power Settings Opens the Power Options dialog box
n
Open Disk Cleanup Opens the Disk Cleanup Options dialog box
n
Advanced Tools Opens an Advanced Tools screen that provides access to other
performance-related tools (see Figure 21-19)
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1016
FIGURE 21-19 Advanced Tools
HoW it WoRKS
Understanding the System Performance Rating
Microsoft Global Technical Readiness Platforms Team
I
t is important to note that the System Performance Rating number indicates the
general speed and power of a computer running Windows Vista. The rating per-
tains only to the performance aspects that affect how well features in Windows and
other programs will run on this computer and does not reflect the overall quality of
the computer. A higher performance rating means the computer will generally
perform better and faster—especially when performing more advanced and
resource-intensive tasks—than a computer with a lower performance rating.
The rating system is designed to accommodate future advances in computer tech-
nology. In general, the standards for each level of the rating system stay the same
(within tenths). For example, a computer that is rated as a 4 should remain a 4 unless
the computer’s hardware changed. As technology continues to improve, additional
higher-level Windows Experience scores will be introduced, and new tests added.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1017
Understanding Windows Error Reporting
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 to the user in a
meaningful and actionable manner.
WER is the technology that reports user-mode freezes, 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 and later has support for any kind of problem event as
defined by the developer, not just critical failures as in Windows XP.
Overview of Windows Error Reporting
The WFP is illustrated in the high-level flow diagram in Figure 21-20, with WER labeled as the
Watson Client.
Step 3: WER collects the bucketing parameters and
prompts the user for consent (if needed)
Step 2: WER plug-in code calls WER APIs
Step 1: Problem event occurs
Step 7: If a response is available from Microsoft,
a notification is shown to the user
Step 6: WER executes pre-registered recovery and
restart functions if applicable, and the data is compressed
and uploaded behind-the-scenes
Step 5: If Watson requests additional data,
WER collects the data and prompts the user
for consent (if needed)
Step 4: WER sends bucketing parameters
to the Watson back-end

FIGURE 21-20 Watson Feedback Platform flow diagram
A significant improvement of WER in Windows Vista and later versions is the concept of
queuing. In Windows XP, WER reports could be sent only at the time the event occurred, with
few exceptions. Beginning with Windows Vista, WER provides a flexible queuing architecture
where users, administrators, and WER integrators can determine the queuing behavior of
their WER events.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1018
During the OOBE phase of installing Windows 7, the user can choose whether WER should
automatically send basic problem reports to Microsoft. 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.
How WER Works
WER consists of the following conceptual components:
n
Report Processor
n
Data Collection Module
n
Transport System
n
Store Management System
Client-side WER functionality is provided through the WER service.
Report Processor
The Report Processor is a conceptual component that is responsible for managing the state
of a report after it has been sent to WER. Applications use WER APIs to create and submit
reports. At that point, the Report Processor decides whether to queue the report or submit
the report. The Report Processor will attempt to hand over the report to the Transport System
if the following conditions are met: there is network connectivity, the report is for an interac-

tive application, and a user interface can be shown. Otherwise, the Report Processor will hand
over the report to the Queue Management System. The Report Processor will also invoke the
user interface component if applicable.
Data Collection Module
The Data Collection Module is responsible for collecting the following data:
n
Heap dump data
n
WMI query results
n
Registry key data
n
Registry tree data
n
Files
n
File version information
n
User documents
n
Minidump
n
Microdump (that is, a minidump that has been stripped of all other information except
the faulting stack trace)
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1019
Transport System
WER uses two separate modes of transport:
n

Live Watson Mode In this mode, WER uses a four-stage protocol based on top of
HTTP to communicate with the live Watson back-end servers.
n
Agentless Exception Monitoring (AEM) Support for the file share–based
Corporate Error Reporting (CER) transport mode used in previous versions of Windows
has been discontinued in Windows Vista. Instead, support for Agentless Exception
Monitoring (AEM) has been added to Windows Vista for use in corporate environments.
AEM is a component of the Client Monitoring feature in Microsoft System Center
Operations Manager (SCOM) 2007 that lets you monitor operating systems and
applications for errors within your organization. For more information about AEM,
see />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:
n
Reporting failed for any reason other than the user clicking Cancel.

n
The application developer designed the application using WER APIs to specify queuing
as the default behavior.
n
The ForceAdminQueue policy is not enabled.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1020
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:
n
The process submitting the report is not running in an interactive desktop (includes
system services).
n
The ForceAdminQueue policy is enabled.
REPORTQUEUE 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:
n
Users\<username>\AppData\Local\Microsoft\Windows\WER\ReportQueue (for reports
in the user store)

n
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
REPORTARCHIVE FOLDER
The ReportArchive folder contains reports that have been uploaded or denied upload (via
policy or explicit user action). This folder is referred to as the Archive store. Reports that are
successfully submitted from the queue store(s) are automatically transferred to the archive
store.
You also can create an Event Reporting Console (ERC) folder in the WER store folder(s). The
subfolders in the ERC folder store response metadata and templates used for displaying the
response data in the Problem Reports And Solutions Control Panel. You don’t need to modify
the data in the ERC folder, and modifying the data is not supported. The location of the
ReportArchive folder is either of the following:
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1021
n
Users\<username>\AppData\Local\Microsoft\Windows\WER\ReportArchive (for reports
in the user store)
n
ProgramData\Microsoft\Windows\WER\ReportArchive (for reports in the computer
store)
QUEUE REPORTING
When a new error report is successfully submitted to any of the queues or directly to the
Watson back-end servers, WER enters Queue Reporting mode. In Queue Reporting mode,
WER will prompt you to send the queued report(s) if conditions permit. If conditions are not

optimal for reporting, WER schedules itself to be started when a network connection is estab-
lished (SENS) or when the current user logs on the next time (HKCU\Run). This ensures that at
some point in the future when conditions are right for reporting, infrastructure will be able to
show the queued reporting console.
In Queue Reporting mode, WER performs the following checks in the following order:
1. Is the failing process running in an interactive desktop? If not, WerMgr.exe terminates.
This is necessary because WER dialog boxes should not be shown for noninteractive
desktops, such as the ones that the service accounts own.
2. Does the current user have reports in her queue, or is the current user an administrator
and is administrative queuing enabled? If neither of the conditions is true, the current
user has no reports to report. In this case, WER will ensure that network and logon
triggers for the current user are removed, and it will exit immediately. If either of the
conditions is true, WER attempts to prompt you to report entries in the queue.
3. WER sets the network and logon triggers for the current user in case conditions are not
optimal for reporting at this time.
4. WER checks network access to see if the last reporting time has expired. If either of
these checks fails, WerMgr.exe terminates.
5. Open the Problem Reports And Solutions Control Panel to prompt you and update the
last reporting time.
STORE MAINTENANCE
By default, the Queue Management System performs maintenance such as deleting stale
data and trimming the size of the queue on a report store whenever 50 saved reports are in
the store. When the total queued report count exceeds the number defined in the registry
value MaxQueueCount or the registry value MaxArchiveCount for archive stores, the queue
subsystem deletes the oldest .cab files from the queues in the following order until the size of
the queue reaches MaxQueueCount or no more CABs remain to delete:
1. Archive Store
2. Signoff Queue
3. Upload Queue
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

CHAPTER 21 Maintaining Desktop Health
1022
The metadata for a report persists for one calendar year unless the user has disabled the
archive via the DisableArchive setting.
WER queue data retention policies can be configured using Group Policy. If no queuing
policies are configured, the Archive queue will retain 1,000 reports and the Upload/Signoff
queue will retain 50 reports. If a queue becomes full and a new report is created, the new
report will overwrite the oldest report in the respective queue.
QUEUE TRIGGERS
This section describes the launch triggers that WER uses to ensure that the queued report-
ing prompt is started for users when they have unsent reports in their queues. Triggers are
persistent across reboots.
WER launch triggers include:
n
Network trigger This trigger starts WerMgr.exe in Queue Reporting mode for a
specific user when a network connection is established. The network trigger is imple-
mented through the SENS API that senses the presence of a network connection.
n
Logon trigger This trigger starts WerMgr.exe in Queue Reporting mode for a
specific user when the user logs on. WerMgr.exe is responsible for WER error queue
management.
n
Administrator trigger The administrator trigger notifies an administrator of unsent
entries in the machine queue. This trigger occurs only for administrators on the system.
WER Service
The WER service is responsible for obtaining the information that is provided to the back-end
Watson servers when an application exception occurs. The service library, Wersvc.dll, is hosted
in its own Svchost.exe process. When a process crashes, the WER service calls Werfault.exe (or
Werfaultsecure.exe, discussed later in this section) to obtain all of the necessary data for the
crashing/hanging process. Werfault.exe loads Dbgeng.dll and Dbghelp.dll to collect the appli-

cation error data. It also loads Faultrep.dll to perform the reporting to the back-end Watson
servers. If the WER service is not started when an application exception occurs, Werfault.exe
and the dependent libraries will still be started to perform the data collection and reporting
tasks for the fault.
WER in Windows Vista and later also supports error reporting for secure processes. Secure
processes are processes that contain data encrypted with a private key and restricted permis-
sion. If a crash occurs in a secure process, the WER service uses Werfaultsecure.exe to obtain
the necessary data for the crashing/hanging process. The report is encrypted when created
and queued automatically to prevent any possibility of exploitation through the user interface.
The encrypted data is then sent to the back-end Watson servers, where it is decrypted and
analyzed.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1023
diReCt FRoM tHe SoURCe
WER and SCOM 2007
Dhananjay Mahajan, Senior Program Manager
Enterprise Management Division
A
ll versions of Windows have a service called WER, which uses the WER client (on
Windows Vista or later) or the Watson client (on earlier versions of Windows)
to gather information about application and operating system crash. WER then for-
wards the crashes to Microsoft for analysis. SCOM 2007 allows WER to first forward
those errors to a management server operated by the organization. The administrator
can then decide if she wants to send the data to Microsoft for analysis and to see
if a resolution to the problem exists. Having access to this information gives client
administrators visibility into their system errors as they have never had before,
through built-in reports that aggregate crash information from all WER clients.
Using these reports, administrators can identify the top crashing applications, the
top crashes, and any available solutions on WER service.

AEM, a feature of SCOM 2007, offers the flexibility of sending no information,
error IDs only, or full crash information including memory images for analysis. If an
error ID or full crash information is sent, Microsoft will search its knowledge base
of errors and return a resolution if one exists. Microsoft uses crash information
submitted by WER to improve the quality of its products. By having access to this
crash data, administrators can use it to improve the quality of their own internal
applications as well. AEM has very little overhead, and because crashes happen
infrequently and it can easily be deployed across all of the client systems within an
enterprise, without a large data storage burden. Typically, a single server can collect,
aggregate, and analyze crashes from 100,000 desktops with “normal” crash rates.
Understanding the Error Reporting Cycle
The error reporting cycle for WER 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, categorization, investigation, resolution, and response. The following
sections explain what is involved in each of these steps.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1024
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 freeze, or stop error (blue screen). Begin-
ning with 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 type.
Categorization 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 investigat-
ing 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 respond-
ing to his report with information he can use to mitigate the issue. A customer may receive a
response in two ways:
n
If the issue is understood at the time an error report is submitted, the customer will see
a response in the form of a dialog box immediately after the categorization step.
n
If the issue is not understood at the time an error report is submitted but is resolved
some time after the report, the customer can query for updated knowledge of the
problem at a later time.
note Resolutions found later are populated in Action Center.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1025
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 submit-
ted to the Watson back-end servers. (The Report.wer file is not itself sent—only the param-
eters 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:
n
Version
n
Event Information
n
Signature
n
UI
n
State
n
Files
n
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 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:
n
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.
n
Other data This encompasses everything that is not safe data, which may or may not
contain personal information.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 Maintaining Desktop Health
1026
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:
n
Minidump file
n
Contents of the heap
n
Registry Keys
n
WMI queries
n
Miscellaneous files
MoRe inFo For more information about what information can be sent with WER, see the
Windows Vista WER Privacy Statement at />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
/kb/931673.

Configuring WER Using Group Policy
Administrators can use Group Policy to configure WER in AD DS environments. Table 21-9
describes the policy settings you can use for configuring WER on targeted computers running
Windows Vista and later. WER policy settings can be found in two locations:
Computer Configuration\Policies\Administrative Templates\Windows Components\Windows
Error Reporting
User Configuration\Policies\Administrative Templates\Windows Components\Windows
Error Reporting
Note that all policy settings listed in this table are available as both per-computer and per-
user policies except for the Configure Corporate Windows Error Reporting policy setting,
which is available only as a per-computer policy.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Understanding Windows Error Reporting CHAPTER 21
1027
TABLE 21-9 Group Policy Settings for Configuring WER
POLICY SETTING DESCRIPTION
LOCATED UNDER \WINDOWS ERROR REPORTING
Disable Windows Error
Reporting
If this setting is enabled, WER will not send any problem
information to Microsoft. Additionally, solution informa-
tion will not be available in the Action Center Control
Panel.
Prevent Display Of The User
Interface For Critical Errors
This policy setting prevents the display of the user inter-
face for critical errors. If you enable this policy setting,
WER prevents the display of the user interface for critical
errors. If you disable or do not configure this policy set-
ting, WER displays the user interface for critical errors.

Disable Logging If this setting is enabled WER events will not be logged to
the system event log.
Do Not Send Additional Data If this setting is enabled any additional data requests from
Microsoft in response to a WER event will be automatically
declined without notice to the user.
LOCATED UNDER \WINDOWS ERROR REPORTING\ADVANCED ERROR REPORTING SETTINGS
Configure Report Archive This setting controls the behavior of the WER archive. If
Archive behavior is set to Store All, all data collected for
each report will be stored in the appropriate location. If
Archive behavior is set to Store Parameters Only, only the
minimum information required to check for an existing
solution will be stored. The setting for Maximum Number
Of Reports To Store determines how many reports can be
stored before old reports are automatically deleted. If this
setting is disabled, no WER information will be stored.
Configure Corporate Windows
Error Reporting
This setting determines the corporate server to which WER
will send reports (instead of sending reports to Microsoft).
Server port indicates the port to use on the target server.
Connect using Secure Sockets Layer (SSL) determines
whether Windows will send reports to the server using a
secured connection.
List Of Applications To Be
Excluded
This setting determines the behavior of the error report-
ing exclusion list. Windows will not send reports for any
process added to this list. Click Show to display the exclu-
sion list. In the Show Contents dialog box in the Value
column, type a process name to add a process to the list.

To remove a process from the list, click the process name
to be removed and press the Delete key. Click OK to save
the list.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.