What event id to use for my custom event log entries?

Question

Is there any ranges of valid event IDs which should be used by custom applications while logging to Windows EventLog? Or I can use any event ID of my choice (1,2,3,4....). P.S, I am developing in C#.NET.

Solution 1

EventIds are application specific so you can use whatever ranges you like. Just ensure you document what you have used and where so that you can ensure you don't use an id twice, or to facilitate easier debugging.

But keep in mind...

Like when Henry Ford said "you can have any color you want as long as it's black" - you can also use whatever range you like as long as that range falls inside the range of 0 and 65535.

Solution 2

Sure enough, it is up to the author to define and track event IDs they use and what they mean.

Here is a reference: http://msdn.microsoft.com/en-us/library/e29k5ebc.aspx - Particularly interesting is the part about not writing messages with IPv6 addresses (because of the % character) to the event log. I bet you can use a parameter to work around that though.

Solution 3

The hi bits of the ID are reserved for testing, debug and other flags used for development. The usable bits are:

0x0000 - 0xffff

See: Event Message Structure

The upper bits should be avoided but all values for the bottom bits are available if you create a custom source. If you use a system or pre-existing source you will collide and likely get the wrong message. Messages are taken from the registered sources message DLL file. A custom message file can be built using the message file compiler from the SDK.

Solution 4

Edit1: I tested that and it is not true that eventID is 32bits. It is only 16 bits.

eventId is Int32, from -2,147,483,648 to 2,147,483,647

EventLog.WriteEntry Method (String, String, EventLogEntryType, Int32)

public static void WriteEntry(
    string source,
    string message,
    EventLogEntryType type,
    int eventID
)

View more solutions

Comments

[Albert Cortada]

Yes, accepts a int32 as a parameter, but if you enter a int that is not in the range of 0 and 65535 throws an exception.

[MrHIDEn]

Yes. You are right. I tested it now and I am surprised that MS claims it is 32 bits...

[Tom Blodget]

Unfortunately, many APIs avoid unsigned integer types. They are not CLS-compliant.

[Junior Mayhé]

where 65535 is ushort.MaxValue

[MrHIDEn]

Why -1? Any comment? Prove?

[Pete]

Probably because the purpose of the eventId to to uniquely identify the type of event. All events of the same type should have the same id. This for example allows that automated monitoring can take certain actions when certain events occur. Assigning a random ID defies this purpose

[Vinod Srivastav]

@Pete That make sense when you log in the Application log although it was just a suggestion.

[KillerRabbit]

While it takes work to keep track of a set of event IDs, it does seem silly to generate a random number you cannot trace back to where it happened. What I've done for my PowerShell scripts is to use the line number of the source file where the event is being reported. Of course that only works for an app where the code is a single source file and not spread across modules.

[Vinod Srivastav]

@KillerRabbit Assuming to have the code in a single file itself is silly, information like where it happen can be written in the log itself but when it comes to modules one can define multiple source within the log for each module when the log is a custom one and not the default Application log. I was running an service that consumes 60k+ messages a day and the messages was processed in a pipeline of modules so random Id's helped me to identify & club them together as DateTime was always same