References Available On Request...

Today we're going to tackle one of the biggest misconceptions among admins about the Windows Event Log. In particular, the notion that it is a.) a self-contained file and/or b.) a text file. It is in fact neither one.

If you drop a saved EVT file into a text editor like Notepad, you will see some text strings, but you're also going to see a lot a gibberish. Together, the readable text and the gibberish make up a bunch of linked data structures. Microsoft calls this structure an EVENTLOGRECORD, and a saved EVT file has a ton of them, one for each log entry in the file. An EVENTLOGRECORD contains a whole bunch of information, including the date/time the log entry was written to the file, the security identifier (SID) of the user performing or logging the action, the category of the event, the source, event identifier, etc.

Earlier, it was mentioned that event log files are not self-contained. For example, the log file doesn't contain the name of the user performing the action - instead, it contains the SID number (security identifier). In other words, a log entry generated by NT AUTHORITY\SYSTEM wouldn't have NT AUTHORITY\SYSTEM as a text string in the EVT file - it would contain the SID "S-1-5-18" represented in binary. In some respects this seems tedious, but since usernames get renamed often in a Windows domain, it makes sense. If you decide to review an EVT file again in the Microsoft Event Viewer many months after it was initially saved, you want to see the usernames the SIDs resolve to at that instant, not what they resolved to months ago. So, any application that consumes or reads event log files needs to be able to resolve that information, typically via the domain controller or the member server/workstation where the log file originated from.

Another wrinkle in the Windows Event Log format is how the Description field - which often contains very valuable information - gets put together. EVT files don't contain all the data that you see in the Description field of events you view in the Microsoft Event Viewer. Instead, they contain the key nuggets of data that get combined together with message frameworks from resource files to form a complete description.

For instance, your antivirus software may elect to write Event ID 20 to the Application Event Log. Event ID 20 corresponds to the following message template in the Antivirus software's message files: Virus %1 was detected in file %2

However, the Antivirus software will only send the two parameters needed by the message framework when it logs the event. In this example, MyDoom for the virus name and c:\dropper.exe for the file.

In other words, your EVT file will only contain MyDoom and c:\dropper.exe ... and it's up to the program displaying the event to you to put together the complete description, which in this case is: Virus MyDoom was detected in file c:\dropper.exe.

Given that event log files contain so many references to information that in many cases can only be obtained from the machine where the files were generated, here are some tips that will serve you well:

1.) If you routinely save your event log files, consider saving them in both the EVT/EVTX format and another self-contained format like comma-delimited text or a database table. The EVT file will contain valuable information like the original SIDs, and the text file/database table will contain a snapshot of how that data was translated at a certain instant in time.

2.) If you uninstall software, you may find entries in your event logs where the Description field cannot be correctly formatted. This is because message files often get uninstalled alongside the software. If you reinstall the software, even temporarily, you should be able to see the full event descriptions again.

3.) Transplanting Windows Event Log files to a network outside the one they originated from is a losing proposition. When the Microsoft Event Viewer or other log viewing application attempts to resolve the many references in the file, it will more often than not fail and produce incomplete data. As a result, you will only see limited amounts of information, such as Well-Known SIDs and events from software/hardware that match the software/hardware installed on the originating machine.