9

Is there a specific range of Event IDs in Windows reserved for application developers?

I'm working on a .Net application that will write errors to the windows event log. This application actually targets servers, and will be run as a scheduled task by paranoid sys admins who will want to lock it down as much as possible (including running it with a reduced privilege maintenance account). The app will not be formally installed — in fact, I'm not even building an installer for this; just a zip file with the .exe and app.config file.

Here's the trick: in Windows, you need administrator privileges to create a source in the Application event log. Since I can't count on this and I don't want to make overworked sys admins need to create one, I'm using "Application Error" (used by MS Office) as a fallback. (Picking a better fallback is on my todo list, since office isn't as often installed on servers).

The problem is that I still want my events to stand out a bit, rather than just masquerading as Office. This way, my sys admins can easily filter down to just those events in Event Viewer or the log aggregator of their choice. The best solution I'm aware of right now is using the Event ID, but I'm worried about conflicting with internal Windows Events, especially considering my target audience.

I've looked, but I can't find any documentation on this. So, is there a specific range of Event IDs I should use, will I be okay using whatever, or should I look at a completely different option here?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794

2 Answers2

4

Not really. At the top level you have an Event Source. Each Event Source has its own Event Categories. Each Event Message is "owned" by an Event Source and falls into one of its Event Categories. If you're going to be logging your events under someone else's Event Source, you're breaking this convention and could quite possibly have Event ID collisions.

On the other hand, Event IDs are structurally similar to HRESULTs and there is a Customer bit you could set. There is also a Facility Code field, but Microsoft only provides one facility for 3rd parties (the rest are reserved). Even if you mess with these bits, you are still at the mercy of the owner of the Event Source; if Microsoft were ever to write something to the Event Source you are using and set the Customer bit or Facility Code (e.g. perhaps non-Windows components such as Office or something), you would be right back in the same danger of collisions. Or if some other developer decides to do the same thing you are doing. Really the safest way is to define your own Event Source.

Luke
  • 11,211
  • 2
  • 27
  • 38
2

It seems this is the crux of the problem

I'm worried about conflicting with internal Windows Events, especially considering my target audience.

I don't think you have to worry because the Event ID's correspond to a specific Event Source so unless you use the exact same source you won't cause the admin's to get upset. For example MS does sometimes uses the same ID with different sources.

If you want to get information about the registered publishers and event ids you can use Wevtutil For example this will list the publishers.

wevtutil ep

From that you can get the specific event ids used for a publisher you can use the following (Event Log was used in this example)

wevtutil gp Microsoft-Windows-EventLog /ge /gm:true

If you're good at powershell I'm sure you could come up with a script to get all the event ids that are registred

Conrad Frix
  • 51,984
  • 12
  • 96
  • 155
  • 2
    The problem with using someone else's Event Source is that the event viewer will use the corresponding message file to format the error message, so your event logs may look something like "Microsoft Outlook experienced an application error" or whatever when in reality the message was generated by your program. Or if you use "unused" event ids the user will have to memorize them as there won't be a corresponding string in the message file. Either way, it is not a good user experience. – Luke Feb 02 '11 at 14:44
  • Old now, but re-using an existing Event Source was the whole point. Creating my own Event Source would have required administrator privileges, but I want the App to be able to run without needing administrator rights, even at install time. – Joel Coehoorn May 07 '15 at 16:42