Windows port of Logcheck


Welcome to the Windows port of Logcheck (now called LogSentry), the famous UNIX log processing tool. Psionic was bought by Cisco who has moved the cool Abacus tools, including LogSentry, to

As you probably know if you are bothering to read this, LogSentry helps spot problems and security violations in your logfiles automatically and will send the results to you in e-mail. However, it can only work with what it's given. I personally find the Windows Event Logs to be verbose, yet un-informative. So when you get e-mailed messages with three or 4 lines on arcane gibberish, remember that it's the same information as you would see in the Event Log, except it's in a slightly different format, and you are actually SEEING it! (Of course, you would have reviewed the Event Logs anyway, right?) :-)

The beginning of each log entry contains the name of the Event Log, the date, and the time, like: "DIR,7/20/2001 11:52:12". this is followed by the event details. The three letter codes for the Event Logs are:

  • APP Application
  • SEC Security
  • SYS System
  • DNS DNS (Win2000 Server(?) only)
  • DIR Directory Service (Win2000 Server(?) only)
  • RPL File Replication (Win2000 Server(?) only)

It will help to look for those codes to isolate one event from the next, since your mailer will probably wrap the lines.

Also, the MS API for the Event Logs will return the application log if the Event Log being asked for does not exist. Once it returns the handle, there isn't any way that DumpEvt can tell which log is being read. For example, if you dump RPL on an NT box, or DNS on W2k Pro it dumps the APP log instead. This causes duplicate entries in the capture file. The only work-around right now is to edit wrapper.cmd and REM out the Event Logs that do not exist on that machine.

While the actual script could have been ported to the CMD.EXE shell, I thought it was much more efficient and effective to make as few changes to that as possible, and instead create a "wrapper" program to translate "Windows" into "UNIX."

I gave the wrapper the highly imaginative and interesting name of "wrapper.cmd." Note that it only runs under Windows NT and 2000 (and probably XP though I have not tested that). In short, logcheck is pointless without logs, which means the Event Logs. Since the Win9x series doesn't have those...

See the "Tools-Readme.txt" for details about what tools are needed.


I struggled with the default directory location for a while. I *hate* programs that put themselves in the %SYSTEMROOT% (e.g. c:\winnt) directory. However, I wanted to be a little obscure, so I thought c:\etc was a little too obvious. And I wanted to be reliable, so "c:\Program Files" or "c:\Documents and Settings" were both too long, and had annoying spaces. C:\Progra~1 and c:\Docume~1 are not 100% reliable. So %SYSTEMROOT%\etc it is... Of course, you can change that if you want.

  • %SYSTEMROOT%\etc
  • %SYSTEMROOT%\etc\lcwin Keyword files
  • %SYSTEMROOT%\etc\bin Binaries
  • %SYSTEMROOT%\etc\tmp Secured Temp directory
  • %SYSTEMROOT%\etc\bin Documentation and help files

Note the word "secured" above. YOU need to set proper permissions on those directories so that the account under which logcheck runs as the proper access, but "Everyone" else does not. See the INSTALL-Windows.txt file for more details.

At the heart of logcheck are two basic things, grep and mail. If they fail, so will logcheck. While in the UNIX world you can assume the ability to send mail from the command line, in the Windows world you can't. So make sure Blat is working. Again, see the INSTALL-Windows.txt file for more details.


This software is released under the GPLv2. See the included LICENSE file.


First, to Marcus J. Ranum and Fred Avolio for writing the deceptively simple yet brilliant original for TIS Gauntlet.

Second, to Craig Rowland for applying the idea to system logs.

Third, to all the people who wrote or ported the tools I needed to get logcheck to run under Windows, notably K. M. Syring, the guys at Somarsoft, and Tim Charron.

Fourth, to G.P. and I.P. who sent me logs to test to help me tune the keyword files, and answered various other questions.

I should also mention the guys at Bastille Linux, whos style I've copied here a bit in the Setup program "interview."


Finally, a few notes about other tools or resources that may be of interest, if you've managed to read this far.

I've found the following book to be essential in other Windows scripting projects, and it proved helpful in this project as well. For anyone who thinks you couldn't possibly find enough material in the old DOS batch file language to write a book about it -- that's what I thought when I saw it. Check it out! While not nearly as powerful, flexible or easy to use (though some would argue that last) as UNIX shells, Windows's CMD.EXE is actually a lot more powerful than you think. Forget about though...

Windows NT Shell Scripting, by Tim Hill
New Riders Publishing, Paperback, Published April 1998, 377 pages, ISBN 1578700477

Other Methods of accessing the NT Event logs (not free):

  • Win2K Server ResKit Perl scripts: &
  • NT (etc.) ResKit Elogdmp.exe event log dumper

Other Tools of interest (free):

  • Snare is a Windows service to send NT Event Logs to a SysLog server. (This used to be called Backlog, the latest version of which is Backlog 1.9b and which is archived here and here. Backlog is much more simple than Snare and may still be quite useful.)
  • NTSysLog is another Windows service to send NT/2000 Event Logs to a SysLog server, but the latest release seems to be 1.13 from October 21, 2002.
  • NTLast is a UNIX-like "last" command for NT Event Log (

Log Analysis: