S3 Tech Blog: New Windows Event Log: Gateway to Native Windows Functionality in Vista

Share |

While the .NET Framework's feature coverage continues to increase—particularly with the WinFX release in Windows Vista, native code will continue to be the most powerful and flexible mechanism for producing applications that work closely with the host operating system (OS). To demonstrate that native development is alive and well in Vista, this article covers the new Windows Event Log features to prepare you for a plunge into the native libraries, which are the only way to access the new functionality.

Since Microsoft unveiled .NET at the Professional Developers Conference in 2000, where native development fits in has been an ongoing debate. Extreme opinions have been expressed on both sides of the argument, ranging from managed code is a toy technology that will never be suitable for real-world application development to developers never need to write another line of native code!

The truth obviously rests between these two opinions, and Microsoft's first major revision of the Windows OS since the release of .NET (Windows Vista) provides some hard evidence on which to examine the native/.NET divide.

Based on the feature set growth of the managed WinFX libraries, compared to the native Windows SDK libraries, Microsoft is continuing to focus its managed code efforts on providing the best platform for application development and leaving native code as the preferred offering for system development. At its heart, Vista is simply another release of the well-known NT kernel with a number of additional libraries for both native and managed development. The compilers, which allow native libraries to be called for managed applications and vice-versa, reflect Microsoft's strategy of releasing a library using the most appropriate technology for the functionality of the library.

With Vista, managed code becomes a core part of the Windows offering, and a number of new technologies are exposed primarily through managed libraries. You can call these libraries from native C/C++ through COM interoperability, but it is generally easier and faster (both in terms of development speed and execution speed) to call managed libraries using the /clr compiler option at a minimum and preferably using C++/CLI.

Author's Note: Not all the new functionality is available through WinFX, and native libraries continue to be the only way to access some aspects of the operating system's functionality.

Windows Event Logging

Event logging prior to Vista's new event logging framework was a complicated proposition. A wide range of operating system features offered competing functionality, and no logging technology offered all the features an application may have wished to use. The following four main technologies available to native developers were:

Event Tracing for Windows (ETW). ETW offered a high-performance logging option, but its output was not readily accessible to operations staff. ETW log files were put in a location defined by the code using ETW and required a custom viewer for inspection.
The Windows Event log. The Windows Event log was probably the most popular enterprise and system logging mechanism. It was not designed for high-volume logging, so it could miss events under high load. High-volume logging also had the tendency to flood the common Application event log with high-frequency events from a single application. As a result, important events raised by other applications could be overwritten by trivial debug statements. The Event Log did ship with an built-in viewer, but it was feature-poor and required a more advanced offering like Microsoft Operations Manager to deal with enterprise scenarios.
Windows Management Instrumentation (WMI). WMI offered a rich event model at the expense of performance. WMI events also required a custom viewer.
printf or OutputDebugString. The use of printf or OutputDebugString was a popular developer method of adding basic instrumentation to an application, but these statements rarely were captured by logging tools run by operations staff. Even if they were, the log information typically required the original developer to interpret it.

One of the main problems of all these event-logging technologies is that they have minimal built-in security. Given the potentially sensitive information that a log file can contain and the denial-of-service possibility of spoofed log events, incorporating security in a logging mechanism is an important consideration.

The New Event Tracing Framework

Rather than throw out all the logging technologies currently available, Vista uses these as building blocks for a new uber-framework. Starting at the most visible manifestation of the logging changes, Figure 1 shows the new Event Viewer for Windows Vista. Despite some superficial similarities to the Windows XP event log, the Vista Event Log offers a wide range of functionality traditionally associated with an enterprise-monitoring tool.

(Full Size Image)

Figure 1. Windows Vista Event Viewer

Starting on the left pane, the Event Viewer still has the familiar Windows Logs, where events from the Windows XP-style event logging API will end up. One of the new features of the left pane is the ability to define a standard query of log events that can be persisted as a custom view. This can be incredibly useful for operations staff who are interested only in events of a certain severity from a particular event source. The other new feature is the hierarchal presentation of custom application logs. While you could create custom logs with the old Event Logging framework, it had no concept of log hierarchies.

The main pane of the Event Viewer shows the list of events in a list-view (as is the case in XP). It also includes a new preview pane that negates the need to bring up a dialog in order to inspect the details of the event. It is still possible to bring up a dialog box, and the dialog box in Vista will not be modal, enabling you to bring up multiple details dialog boxes and compare events. The Event Viewer also presents an XML view of the data in an event record, and you can query all the events across multiple logs with XPath.

The Actions Pane on the right presents various options for opening, filtering, and closing various filters. One of the more interesting features is the ability to attach a task to a specific event. The task can be any Windows Task Scheduler task. You can use this feature to alert operations staff that need to respond to any event or even to respond to an event automatically.

The new event logging framework for Windows Vista is a part of the Vista operating system, and Microsoft will not back-port it to Windows XP or Windows Server 2003.

The new Event Logging in Vista is built on top of ETW. ETW was the most comprehensive and robust logging framework in the NT5.x kernel, and building on top of it allowed the Vista team to concentrate on adding new functionality rather than re-inventing an existing logging framework.

The Windows Event Log uses channels to deliver events to a log file. Vista ships with a number of pre-defined channels for Application, Security, Setup, and System Windows Event logs (these are visible in the left pane in Figure 1), and new applications that target Vista will each add a new channel. The bottom of the left pane in Figure 1 also shows custom channels created by the various components of the Vista operating system.

Channels come in two distinct types: serviced channels and direct channels. Having two different types satisfies the two distinct reasons you may log an event. For high-performance, high-volume logging to inspect events on a log console as they flow past, use the direct channel. Direct channel events are not processed by the Event Logging framework, and you cannot subscribe to an event from a direct channel. In contrast, serviced channels offer the reliable delivery of messages that you can subscribe to via an XPath query. Serviced channel events can be either: