The Fundamentals: #1 Next Generation Event Log

The first feature I want to discuss is the new event log, a benefit to IT Pros and developers alike. The event log in Longhorn is a major update of the NT event log service. It maintains 100% backwards compatibility with the existing APIs and functionality and uses the existing NT event log instrumentation in the applications and services. At the same time it eliminates some of the limitations of the NT event log and provides additional features to better support monitoring and diagnostics of Windows applications, services, components and drivers.

For event publishers, the new event log allows you to publish structured events based on -- surprise, surprise -- XML.  Event subscribers likewise provides ways for admins to richly query the event log.  Moreover, it provides event forwarding, such that certain events can be forwarded to another event log.

The best way to grok some of this functionality is to work through some samples.  There are some very simple and concise samples in the SDK that are quite explanatory. 

1. First, go to the SDK and compile the Simple Eventlog Publisher sample using msbuild.exe.  Run the sample. This sample demonstrates an application which reports a text XML event to a channel. To see this event, right click on My Computuer and go to manage.  There are still two event logs in the PDC build, the old event log and the new one (This will become one by RTM.)  The old event log is called the "Event Viewer" under System Tools -- you won't see your event there.   The new event log can be found under Services and Applictions and is called "Windows Event Viewer".   Here is the source code.

If you go to the Application bucket, you will see your event listed.  Double click on it and go to Details -- there you will see the XML of the event published.  Notice how additional elements are added to the custom XML published by the event, such as computer name, ProcessID, etc. 

2. Now, go to the SDK and compile the Query Log sample.  This sample demonstrates an Application which issues an XPath log query for all events in the Application log and then prints out the query results to the console. Note how the XPath query ("Global/Application/ComputerAddedToDomain") maps to the Application bucket of the Global channel.  You could imagine getting much more granular with how the XPath queries are structured. Here is the source code.

3. Now go to the SDK and compile the Subscriber sample. This sample demonstrates an Application which subscribes for event notifications in the Application channel and prints the received events to the console. The subscription is expressed as an XPath query. To see this sample in action, you will need to fire up a seperate console window and run the Publisher sample in order to get an event to fire.  Each time you run that sample, the event should fire on your subscriber sample.  Here is the source code.

These three samples show the basics of firing, querying and subscribing to events. 


Comments (9)
  1. Youcef Laribi says:


    I don’t have Longhorn installed, so I cannot try to samples in the SDK, but I’d like to see small code samples in your blogs, just to give a flavour of how the feature works.

  2. would it be possible to have the eventlog queued(synched) into a DB, so to make collecting and monitoring easier

  3. Great idea on the source code — I’ve update the samples to link to the source in the Longhorn SDK.

  4. Regarding the queuing and synching of the event log into the DB…

    I’d say the two biggest problems with the event log today are (1) quality of information and (2) facility to search for information. This second point is probably what is motivating your desire to push the event log into a DB. Hopefully, what is being built in Longhorn would obviate that need because the search facility of the event log would be sufficient to perform the types of queries you seek. You will have the entire XPATH language at your disposal to write queries, which is quiet powerful. Also, one of the features of the new event log MMC is saved queries, so that you can create your own filters based on a kind of query.

  5. My main issue is with aggregation of logs

    I’d like to see a feature where the logs send copies of its entries to a central location

    -could be an application setting – which can be pushed from Active Directory or policy of some sorts, rather than something which needs to be installed on each desktop.

    Imagine doing it for 50K desktops …

  6. BTW, could you not reuse bits from EIF and the .NET Logging Application Block, they have quite some funky events sinks and publishing code in them …

  7. Regarding the administration of event logs, there will be the following options for remotely configuring an event log:

    [1] Group Policy based forwarding

    [2] Connect point-to-point manually using the new Event Viewer

    [3] Use some 3rd party tool to distribute scripts to the boxes to set up it

    [4] Run new command-line tools against a list of machines

  8. Feroz Zahid says:

    The greatest advantage I see in the new Event Viewer is the ability to publish structured events using XML.

Comments are closed.

Skip to main content