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.
- track changes of some status
- write errors
- make a notice on process progress
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:
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
The whole logging process is all handled by the same windows nt systemservice,
the eventlog service. All system drivers, services and applications are using
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.
||This distinguishes between erros, warnings and informational messages
This is one of the dates, written to the logfile. Internally,
the uses three different dates:
The source is one of the importent facts, this will
be descriped shortly.
This corresponds to the source above, where
each source can have different categories.
Internally, this is the so called event-id, this
is specific to the property source above.
An event can be associated to a user on the system, which
caused the event.
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 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
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.
Application Programming Interface
Dynamic Link Library