Administrators, developers, and technical
support personnel use Windows Eventing to gather information about the
state of the hardware, the software, and the system, as well as to
monitor security events. To provide these users with useful information,
you need to give an event the right level or severity, raise it to the
appropriate log, provide it with the correct attributes, and give it a
useful and actionable message.
The Event Viewer in Windows Vista now contains
component-specific logs and events. Components that write events to the
system or application event logs in Windows XP can also write events to
their own event log, also known as a channel.
These component-specific logs generally contain non-administrative
events, either operational, analytic or debug events. These events are
usually non-actionable and more verbose and are logged for tracing of
normal operation or more details concerning potential problems.
Administrative (actionable) events however are still usually logged in
the application or system log. An exception may be large components or
applications with a significant volume of administrative events, in
which case there may be a separate component-specific administrative
log. Because of these changes, the Windows Vista Event Viewer is easier
to read and contains many more events with detailed information than on
previous Windows platforms.
1. Overview of Windows Eventing
Windows Eventing 6.0 is the the next generation
of the Windows Event Log service in Windows Vista and Windows Server
Code Name “Longhorn.” While the system as a whole provides an end-to-end
solution for various needs related to tracing and organizing events,
Windows Eventing specifically offers services for administrators, IT
professionals, and developers. It allows users to query and select
events for analysis, diagnostics, and monitoring; it provides powerful
local and remote subscriptions to events; and it allows you to forward
events using industry-standard protocols.
2. Windows Eventing Capabilities
Windows Eventing capabilities include:
Windows Eventing provides a hierarchy of channels:
Global
channels (displayed in Event Viewer as Windows Logs) that correspond to
the NT Event Log standard channels (System, Application, Security)
Installation channel (displayed in Event Viewer as Setup) for the events describing installation and setup history
Global
channels that correspond to the NT Event Log application private
channels (some Windows components such as Active Directory use these
channels for backward compatibility reasons)
Manifest-defined private channels within the Applications subspace
Enhancements associated with these channels include include:
Log files associated with every channel
Access control list (ACL)–based read/write/clear security for the channels and associated log files
A significant improvement in logging performance and scalability over the NT Event Log
Windows Eventing provides the following capabilities to Event Publishers:
The ability to log their events into global and private channels (with write security)
The ability to raise structured and schematized events efficiently from user and kernel mode
The
ability to describe and register the structure and constant values in
their events ahead of time to increase discoverability by allowing users
(administrators) to discover events and their shape before these events
are published as described below
The auto-generation of various system properties in the event, extending similar capabilities of the NT Event Log
Windows Eventing provides the following capabilities to Event Consumers:
The
ability to discover which events a given Event Publisher is capable of
reporting, where these events go, and the shape and meaning of each
event
The ability to select events from one or more channels using queries (with read security)
The ability to register subscription filters to receive event notifications (with read security)
The ability to configure the forwarding of events across computers
Windows Eventing provides the following configuration and maintenance capabilities:
The ability to configure the size, retention policy, and security of event logs
The ability to configure subscriptions
The ability to save archive events from one or more channels using a query
The ability to clear an event log file
Channels
A channel is a named stream of events;
conceptually, this is no different from a television channel. Just as TV
channels are directed at particular audiences, event channels are
intended for specific audiences.
Note
In Windows Eventing 6.0,
each channel has its own event log file associated with it. This means
that you can use the terms “channel” and “event log” interchangeably in
Windows Vista. |
A channel serves as a logical pathway for
transporting events from the event provider to a log file and possibly
to an event consumer. Channels have a number of properties defining
their behavior. These properties can be divided into two groups:
publishing properties and logging properties.
Publishing Properties
When events leave the provider, they are
transported through an ETW session within the Windows kernel. The
physical session can carry multiple channels and the publishing
properties of the channel determine the properties of the session that
must be used to transport the events in this channel. Channels that
share publishing properties can share a single session.
Publishing properties include the security
settings that specify which providers can publish events into the
channel and the filtering parameters that control event filtering at the
source.
Logging Properties
The second set of properties defines how the
events in this channel are to be consumed. Based on these properties,
the channels can be divided into two groups: Serviced Channels and
Direct Channels. Table 1 describes the properties associated with each group.
Table 1. Logging Properties for Channels
| Serviced Channels | Direct Channels |
|---|
| Consumers
can subscribe for reliable delivery of events in the Serviced Channels.
The subscriptions are based on XPath queries, so that only events that
match the query are delivered to the subscribers. | Consumers cannot subscribe to these channels easily. |
| Events
can be forwarded to other systems. Forwarding is subscription-based so
that selected events from any number of channels can be forwarded. | These
channels are performance-oriented. The events are not processed in any
way by the eventing system. This allows these channels to support a high
volume of events. |
Each channel belongs to one of the two groups.
The requirements on the events determine which channel group would best
serve as the destination of the events.
Channel Types
Two channel types are defined within each
group, for a total of four channel types. The channel types are based on
the event audiences. Table 2 describes the channel types in more detail.
Table 2. Channel Types
| Type | Group | Description |
|---|
| Admin | Serviced | These
channels are primarily targeted at end users, administrators, and
support personnel. The events found in Admin channels indicate a problem
and are well-documented or have a message associated with them that
gives the reader direct instruction on what needs to be done to rectify
the problem. |
| Debug | Direct | The
events in the Debug channels are created by developers for developers.
They are typically used during development or may be turned on to
provide information to the developers to help diagnose a problem. The
structure of those events may change often and cannot be relied upon to
stay unchanged for a significant period of time. |
| Operational | Serviced | All
other events describe program operation and indicate problems that
cannot be handled by user intervention. The main consumers of these
events are tools; many of these events are used for problem analysis and
diagnosis. |
| Analytic | Direct |
The Admin channels have a special place on
every system. Administrators and users refer to these channels to see if
their systems are having problems. The contents of these channels are
normally highly visible and easy to find. Two standard channels—System
and Application—are well-established targets of such error and warning
events. System services publish global error and warning events into the
System channel. All other programs publish such events into the
Application channel. Programs normally avoid creating Admin channels of
their own.
Event Log Files
A log file is attached to every channel.
Applications direct the events into the channels, and these events are
typically recorded in a log file. Figure 1 shows the structure of event logs in Windows Vista.
Naming Providers and Channels
A provider’s distinguished name must be specified in the manifest. In most cases, the name is composed of three parts:
<Company>-<Product>-<ProgramName>
The last component may also include a version
number (useful when multiple versions may be running side by side), as
in the following example.
Microsoft-Windows-TaskScheduler
Microsoft-Windows-Eventlog
Microsoft-Windows-SqlServer-10
The unique names of the channels created using
manifests are designed to provide maximum information to the
administrator about the purpose of the channel. The name for a channel
is usually based on the provider name.
<Provider Name>/<Channel Name>
The channel names thus look like the following example.
Microsoft-Windows-SqlServer/Operational
Microsoft-Windows-TaskScheduler/CompletedJobs
Event Level
Event level is used to indicate the seriousness
of an issue with regard to the functionality delivered by the service
or component. It is also used to describe the verbosity of events logged
in tracing scenarios.
The following event levels are predefined and
known to all event providers in the Windows Event Log (event providers
can also define custom levels):
Information events
Indicate a change in the application’s or component’s state as a part
of normal operation (an operation has been completed successfully, a
resource has been created, or a service started) or that the component
has recovered from a problem and returned to a healthy state.
Warning events
Notify the user of degradation in service or of other issues that can
affect service level or result in a more serious problem or failure
unless action is taken.
Error events
Provide information about a problem that might affect functionality
external to the component raising the event, or that is not core to the
capabilities that the service or application provides to users.
Critical events
Provide information about a catastrophic loss of functionality in the
application or component itself. The failure is about the component
raising the event (in other words, failure has already occurred) and
cannot be automatically recovered from Deployment and Configuration.
Event Logs
The unified event-publishing Application
Programming Interface (API) in Windows Vista supports raising events to
four types of logs:
Admin logs
Administrators logs or tools use Admin to determine the health of a
component. Error and warning events, being most critical, are always
raised to an Admin log. Information events that indicate a service’s
return to a healthy state are also appropriate for the Admin logs. To
help administrators find these important events, they are normally only
raised to the System and Application logs, which are common admin logs
shared by system components and applications. In most scenarios, private
Admin logs are not created.
Operational logs
Operational logs are typically private logs in which components can
raise events that are useful for troubleshooting or launching automated
actions, but are not actionable by themselves. Most Information events
belong in Operational logs, which are enabled by default.
Analytic logs
Analytic logs contain events primarily used by tools for scenarios such
as problem diagnosis or performance analysis. Analytic logs are also
known as Trace logs, and are generally disabled by default. Messages for
events in Analytic logs are not necessarily written for administrators.
Debug logs
Debug logs contain events raised by developers for developers. Debug
logs are hidden and disabled by default. Messages for events in debug
logs are designed for developers and support personnel.
Event Attributes
Other event properties help administrators and
tools filter events and automate tasks. Some properties are displayed on
the event summary page, while others are available on the details page
or programmatically.
Source
Source is the name of the component that published the event. Windows
components normally use their assembly names as the name of the main
provider in the manifest. For example: Microsoft-Windows-TaskScheduler.
Value Value is the numeric ID unique to a specific event and source. An event ID is normally used for that event for each version.
Keyword
Keyword is a set of categories or tags that can be used to filter or
search on events. Examples include Network, Security, or Resource Not
Found.
Task Category
Task Category represents a subcomponent or activity of the event
publisher. Task Category is only supported when you use the Windows
Vista Event Publishing API.
Event Messages
Every event report displayed in Event Viewer
contains a message, which is located in the Description box of the
event’s property sheet as well as on the preview pane. The event message
provides context for what happened to the resource about which the
event was raised. Messages for events in an admin log (the System or
Application log) are generally actionable by an administrator. (There
can be additional admin logs for certain applications that are
application-specific.)
In addition to the description message, the
Event Viewer can display event structure using XML (in XML view) and
text (in Friendly View). The following example illustrates an event in
XML format.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-TaskScheduler" Guid="{de7b24ea-73c8-4a09-985d-
5bdadcfa9017}" />
<EventID>301</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>300</Task>
<Opcode>2</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2006-03-17T18:48:36.635Z" />
<EventRecordID>530</EventRecordID>
<Correlation />
<Execution ProcessID="2916" ThreadID="1156" />
<Channel>Microsoft-Windows-TaskScheduler</Channel>
<Computer>user1_PC</Computer>
<Security UserID="S-1-5-19" />
</System>
- <UserData>
- <TaskEngineExitEvent xmlns="http://manifests.microsoft.com/win/2004/08/windows/
eventlog">
<TaskEngineName>S-1-5-19:NT AUTHORITY\Local Service:Interactive:LUA</TaskEngineName>
</TaskEngineExitEvent>
</UserData>
</Event>
