Where’s My Description?

 

The Windows Event Log is a tool that most administrators have at least a passing familiarity with. It’s one of the go-to places to look when troubleshooting a computer. It’s very handy to be able to look at logs on remote computers, or to have event logs shipped from one computer to another. In doing so, you may have run across the dreaded “The description for event ID from source AAA cannot be found.” What causes this?

The good, bad, and ugly of message files.

The event log in Windows is a bit different than the event log in UNIX. In UNIX, the log is simply a text file (or files) with a particular format. In Windows, however, the event log is stored in a database with individual events making up the records. Events follow the message file programming model that the Win32 API does. This model was designed to make translation to other languages easier.

What is a message file? These are typically .DLL files that contain nothing but text resources for use by other programs. Each piece of text in the file is referenced by a unique ID making it quick to extract one of them for display to the user. One of the resources may look like “Error writing to drive %s, it is full.” At run time the %s is replaced by the name of the drive which failed, so all that a program needs to do is call a function such as ShowMessage(ID_DISK_FULL, “C:”) to display the message. The advantage to this model is that just by swapping in a different message file, the program can be translated into another language and the program doesn’t need to change at all.

Event log entries work the same way. Each entry has a set of values which are combined with the messages from a message file to generate the text you see. This works great, as long as you have the proper message file. There are two scenarios where this might not be the case:

  1. You are looking at a remote event log and the admin shares are unavailable.
  2. You have saved the event log and are looking at it on a different computer, one where the application that generated the events isn’t installed.

In the case of #1, Event Viewer tries to open the message files on the remote computer, using one of the admin shares (admin$ or c$, for example). If the files can’t be accessed, then the messages can’t be shown. The only solution is to open up access to the admin shares. Even if the application is installed locally, Event Viewer won’t look for the local message file.

With #2 you can install the application on your computer, but this isn’t always feasable. There is, however, another solution. If you have access to a message file from the application, you can “trick” Event Viewer into using it. This involves a change to the Registry, so all of the standard caveats and “don’t-do-this-at-home”  and “we-told-you-so” apply. The key you’re looking for is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog

Registry

The screenshot shows all of the individual Event Logs. Underneath each of these are more keys, one for each Event Log Source. These are what you need. In Event Viewer you can see the Source for each event. Event Viewer looks for one of these keys to find out where the message file is. In my example, the source is PowerShell under the Windows Power Shell log.

If you have an event log from another computer, and its corresponding message file, all you need to do is to create a registry key under any of the event logs (it doesn’t really matter which, but I usually use Application) and give it the same name as the source. In the key, create a single string value called “EventMessageFile” and point it to the message file you copied. Presto! Event Viewer will now be able to show you the event messages in all their expanded glory.

The strange case of .NET

Interestingly, Microsoft has actually pulled away from message files in the .NET Framework. When .NET applications write to the event log, by default they all use a single message file with a single resource. That resource is a simple %s which just displays the single value within the event log entry. This means that most .NET applications won’t have problems with event logs on different machines. Even if you’re looking at the log without access to the message file, you’ll still see the full message below the paragraph warning you about the missing message file.

The mechanisms for the event log can at times be irritating, but a good understanding of what’s going on under the hood will smooth over the rough spots.