The main log files 32 bit and later Windows operating systems maintain are Appevent.evt, Secevent.evt and Sysevent.evt. They are located in the "%systemroot%\system32\config\" (in my case “D:\WINDOWS\system32\config\”) directory and can be viewed with the 'Event Viewer' application or processed with several utilities (Casey, 2004). In addition to these logs, some applications have their own logging facilities which may or may not leverage Windows event viewing capability.
Appevent.evt or the “Application Log” consists of entries that applications made to the operating system. Mine contains things like ESENT notices that the wuauclt database engine stopped, warnings from EvntAgnt that there's no TraceLevel parameter in my registry and error notices from Vision faulting ntdll.dll. The application log can be very useful for debugging application instability and incompatibility. From a forensics standpoint it is probably most useful for indicating that certain programs were run, although it might also point out system (mis)configurations specific to a computer or case.
Secevent.evt or the “Security Log” consists of entries the operating system made about auditing events. If auditing is off it isn't unusual to find it empty, as mine was. Researching this paper has finally inspired me to enable it, and my first entries reflect that process: “Success Audit”s of my account making “Policy Change”s. In a production environment auditing can be very important. This log can be used to audit “account logon events”, “account management”, “directory service access”, “logon events”, “object access”, “policy change”, “privilege use”, “process tracking” and even “system events”. That could all be useful in a forensic investigation.
Sysevent.evt or the “System Log” consists of entries the operating system made about its own events. This can be a large amount of information. Mine only goes back to 28 January and it has 2520 events. Of these, 1844 are “Information”, 267 are “Warning”s and 309 are “Error”s. So, for troubleshooting a system problem this log may be useful. But from a forensics standpoint the “Event Viewer” GUI is probably not a very efficient way to deal with this much information (Ibid.): mine is a fairly quiescent system.
Windows also offers a facility to applications to maintain their own logs in the “Event Viewer” system. The only application I currently have that does so is Avast Anti-Virus. Its entries are interesting; although they're type “Information”, they look a great deal like errors. I also note that it hasn't logged since February. Avast (2010) seems to indicate that this is a result of my upgrading to 5. Obviously I haven't been checking my logs. Application logs may be a useful source of forensic information.
But applications do not necessarily avail themselves of the “Event Viewer” mechanism. I rather wish they did because the approximately 20 locations I see logs scattered about in the file system are rather inconvenient. And while more information won't make “Event Viewer” any more efficient, tools like dumpel (Microsoft, 2000) will. Once exported to text files they can be analyzed by numerous tools.
Avast (2010) Avast 5 updates not appearing in antivirus log [Online]. Available from: http://forum.avast.com/index.php?topic=56179.0 (Accessed: 27 June, 2010)
Casey, E. (2004) Digital Evidence and Computer Crime – Forensic Science, Computers and the Internet, 2nd edition. London: Academic Press
Microsoft (2000) Windows 2000 Platform Dump Event Log (Dumpel.exe) [Online]. Available from: http://www.microsoft.com/downloads/details.aspx?FamilyID=c9c31b3d-c3a9-4a73-86a3-630a3c475c1a (Accessed: 27 June, 2010)