Since the beginning, as this was about 10 years ago, coming with the most importent Windows has a really good logging mechanisme, it is represented by the .

Don't worry, I'll not lead you to an API description, but will explain some details to understand the . Many technical processes needs some type of logging, just possibly to:

and a lot of other reasons. Events are logged by system components, services, device drivers and also applications. Even simple tools make entries into the . The results can be seen in the Eventviewer application [you'll see an image of it futher down], a build-in system management tool.

This explanation is only written, because many administrator do not not know enough about the details of the , but this helps to explain the resultslists, which are provided by the EventlogViewer and EventlogAnalyzer inside this application. Read to the end!

An usual windows machine has three different eventlogs:

  • system
  • security
  • application
These eventlogs reside each in it's own file inside the filesystem. All processes on a machine can write to one or the other eventlog, even to more than one of this eventlogs at a time. The events are stored into the filesystem by a very performant nt system service, the eventlog service. Dependend on the role a windows machine plays, this could possibly overflood the eventlog files and makes them probably unreadable, due to the huge number of written events. If a server plays one or more special roles, like offering an additional DHCP or DNS service or even play a role in the Active Directory, they use their own eventlogs. See a sample of a collection of evenlogs on a sample-machine, presented by the Computer Management management console:
Image:The Windows Eventlog Viewer

The whole logging process is all handled by the same windows nt systemservice, the eventlog service. All system drivers, services and applications are using an API provided by the . This makes it easy for applications to write events to a log and do it in a standardized way;Also using this API is easier for an application than each providing it's own mechanisme. This is also a big benefit for administrators, which can have a look for problems on all possible topics in the same way and at the same place !!!

A logged event provides several properties on each event, helping to understand the reason in all details. To understand this, first, have a look to the event shown in the following image:

This view provides a lot of columns, each giving a property about the event, as explained in the following table.

Propertyname Description
type This distinguishes between erros, warnings and informational messages
date This is one of the dates, written to the logfile. Internally, the uses three different dates:
  • TimeReceived
  • TimeGenerated
  • TimeWritten
Source The source is one of the importent facts, this will be descriped shortly.
category This corresponds to the source above, where each source can have different categories.
event Internally, this is the so called event-id, this is specific to the property source above.
user An event can be associated to a user on the system, which caused the event.
computer The computer, were the event was originally created on. Because one can log even from remote applications, this is also importent. On clusternodes, an event may appear to both's nodes local eventlog, but this computer proeprty shows, on which machine the event was caused.

Regard:This is only a limited set of properties! A full set of all stored properties can be seen in Introduction/Documentation/How it works/The Eventdatabase.

Now, let's look deeper to the details. Have a look first onto the image on the right, which shows the eventlog viewers detail view.
In this view, there are more properties, than in the image shown above or listed in the table. These are:
  • message
  • data
Message is some clear-text, which human may read and understand, while data is an application-specific information, which is mostly in binary format.

Importent to understand the results, provided inside the EventlogViewer, is mostly the property source together with category and event [now further referred to by eventid]. An application can register an for it's use with the , some register even more than one. Each is associated with exactly one eventlog file, like application or system. An is just simply a DLL, which provides the message itself or provides a template for a message. All messages may also be categorized. An eventid is always unique within a !!

Registration of an is so also specific to a machine and this registration creates some registry-keys. Depended on to which eventlogfile the registration will happen, this results into different subkeys of the registry, but all are starting at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog, like visible in the image below.

The next image just simply displays the characteristics for one registered , in this case for the Microsoft Installer.

In the image above, one can see the EventMessageFile value, which contains the full qualified name of the . This is just the mentioned DLL, which implements the messages and it's categories.

Forgetting the registration on an results in errors while logging to the . These errors are also logged itself into the event and the most admins are sad to see them over and over. This is visible in the image on the right hand. This is mostly a bug of the installation of an application or is the result of a bad design or just simply a bug of that application and/or system-driver. This snapshot was taken while developing the .

Regard:A registry can contain a lot of unused because many applications simply forget to un-register them while uninstalling!!

What one should take over to selecting events in the EventlogViewer, is mainly the uniqueness of the eventid together with the source in the selections against the event-database!

What indicates the importance of an event is the property type. In the Windows NT Eventlog Viewer, this is displayed as text in the detail view and as different symbols in the overview. The table on the right hand just list these types. The EventlogViewer displays the wmi-number for the type property and the longer translation to text is omitted to save space. Additionally, the EventlogViewer display a background-color in it's tables to indicate this importance, but for the DetailView, where the type property is displayed as a number, it is good to remember the values from the table on the right.
nt-number wmi-number name
0 0 success
1 1 error
2 2 warning
4 3 informational
8 4 audit success
16 5 audit failure

Application Programming Interface Dynamic Link Library