Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Maintaining Desktop Health : Understanding Windows Eventing (part 1) - Windows Eventing Capabilities

- Windows 10 Product Activation Keys Free 2019
- How to active Windows 8 without product key
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/16/2013 6:37:01 PM

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 ChannelsDirect 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
TypeGroupDescription
AdminServicedThese 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.
DebugDirectThe 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.
OperationalServicedAll 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.
AnalyticDirect

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.

Figure 1. Event Log structure 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>                                                                           
										  
Other -----------------
- Using Voice and Sounds : Associating a Sound with an Event, Using Alternatives to Sound
- Using Voice and Sounds : Letting Your Computer Do the Talking, Creating a Sound File
- Managing Windows Licensing and Activation : Notification Experience and Reduced Functionality Mode
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 3) - Managing licensing and activation, Implementing KMS activation
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 2) - Leveraging MAK activation, Comparing KMS and MAK activation
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 1) - Centralizing activation with KMS
- Managing Windows Licensing and Activation : Licensing Windows
- Maintaining Desktop Health : Monitoring Reliability and Performance (part 6) - Using Reliability Monitor
- Maintaining Desktop Health : Monitoring Reliability and Performance (part 5)
- Maintaining Desktop Health : Monitoring Reliability and Performance (part 4)
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server