Spamming the event log doesn’t make things any better

Date:April 4, 2006 / year-entry #119
Orig Link:
Comments:    19
Summary:A common suggestion is that if a problem is detected which the system automatically recovered from but which an administrator might be interested in knowing about, then an event log entry should be created. Be careful, however, not to abuse the event log in the process. If the problem is not security-related and it can...

A common suggestion is that if a problem is detected which the system automatically recovered from but which an administrator might be interested in knowing about, then an event log entry should be created. Be careful, however, not to abuse the event log in the process.

If the problem is not security-related and it can occur, say, more than a few times a day, then generating an event log entry may do more harm than good. The event log has a maximum log size (default 512KB on Windows XP), and when the log fills, older log entries are discarded to make room. If you generate a lot of events, you can end up filling the event log with your events, pushing out all the other events that the administrator might have been more interested in. Even worse, the administrator may have disabled automatically discarding old event log entries, in which case the system will generate error messages once the event log fills.

Network administrators make it a habit to go through the event logs of the machines on their network looking for unusual activity. If you fill the event log with chatter, this makes it harder for them to spot the real problems.

Comments (19)
  1. Adam says:

    Do you happen to know why the default event log size so small?

    And would there be any mileage in being smart about what to discard, so that you discard younger "information" log items in favour of older "error" items?

    (On some other systems, old copies of the "critical" log are kept longer than old copies of the "debug" log. If the "debug" log is kept at all)

  2. David Nesting says:

    Logging services on other operating systems notice when a particular message is getting logged repeatedly.  Depending on the problem, applications may attempt to log messages thousands of times a second.  In these situations, the logging service would, when the flood stops (or a different message is received), record how many times the previous message was repeated.  This seems to be a good balance between recording the events accurately and preserving space.

  3. Steve Kemp says:

    I’ve seen several scenarios where the eventlog gets spammed with dozens of identical messages.

    One thing that I like about syslog implementations is the way multiple identical messages in succession can be “collapsed” into “previous message repeated N times”.

    That would seem to be a good solution.

  4. Dave says:

    If you use the MSFTP service at a busy site, you have probably seen hundreds of log-clogging "connection closed because of inactivity" messages every day. No way to keep the service from barfing those out, as far as I can tell.

  5. L7 says:

    Windows is guilty itself.

    For a single scratched cdrom, it often fills entire pages of I/O read errors.

  6. Dave says:

    For a single scratched cdrom, it often

    > fills entire pages of I/O read errors.

    I saw a Monty Python episode about this many years ago. Simply return the CD to the retailer and tell them, "I will not buy this CD, it is scratched." If they quarrel, tell them that you don’t like eventlog spam. At that point the Vikings should chime in and everything will be fine.

  7. Wang-Lo says:

    It’s not scratched! It’s passed on! This CD is no more! It has ceased to be! It’s expired and gone to meet its maker! It’s a stiff! Bereft of bits, it rests in peace! If you hadn’t stuffed it in its sleeve it’d be pushing up the daisies! Its decodable processes are now ‘istory! It’s off the twig! It’s kicked the bucket, it’s shuffled off its mortal coil, run down the curtain and joined the bleedin’ choir invisibile!! THIS IS AN EX-CD!!


  8. BryanK says:

    Better yet (at least IMO): Let the admin configure what gets logged in the first place.  (This would be per program, though, not a setting in the event log system itself.)

    If everyone followed this, then I wouldn’t have to deal with Dell’s once-per-half-hour "OMG your chassis has been opened!!!1!1" messages, because I could disable them.  (Yes, I can disable chassis intrusion in the BIOS, but not remotely, and I have to take the machine down to do it.  These particular machines run our barcode labeling program, and usually can’t be taken down except in an emergency.)

    I also wouldn’t have to deal with Microsoft’s "service X has been sent a start control" … "service X has successfully started" … "service X has been shut down" trio of events in the system log for *every service* at *every reboot* in XP.  (Sigh.)

  9. Mark Steward says:

    Ugh and SSHD which by default logs *five* messages for every failed connection attempt in the Application log…

  10. Annoyed person says:

    For a single scratched cdrom, it often

    > fills entire pages of I/O read errors.

    Yes, and then this happens:

    Whoever was responsible for this should be shoot in the legs. Four times. And made spend the rest of his/her life in prison, not to cause more pain and grief to the rest of the world. This is incredibly stupid on so many levels. Specially on the “you can’t turn it back on with the standard UI” one.

    This pretty much guarantees that everybody’s optical drives will be running on PIO mode sooner or later. It only takes one slightly scratched CD/DVD…

  11. David Candy says:

    I don’t read event logs. They are filled with irrelevent stuff. It’s also a mistake I made once, writing all status of a program to the app log so I could diagnose by phone. It made the app log useless for any other, say its normal, purpose. But then I only added to the useless clutter.

    The errors I chased down in the log have all been irrelevent. I’ve learnt not to waste my time. Error notification is a flawed design.

    If admin logged on errors should be reported (system notification area – I’m a pro tooltip and similar person – there are too few tooltips with too little extra info that take too long to popup). If not they should be either sent to the DC console or shown on next admin loggon (depending if wks or domain).


    Above is a message from a thread today with someone’s bewilderment of getting info from XP.

    Perhaps this is a chance for MS to develop a massively over-engineered solution with 5000 critical points of total system failure. The System Restore guys may be free.

  12. AndyB says:

    Linux syslog doesn’t actually store collapsed messages, instead when you view the log (using logwatch perhaps?) a perl script kicks in to parse them and display them in the ‘blah blah blah – x times’ format.

    I think that would make sense for the Eventlog, even if it is a ‘collapsed’ view where all multiple messages are collated under a collapsed treeview item. The disadvantage is that you couldn’t see the timeline of events, but it would make initial viewing of the log much easier.

  13. danb1974 says:

    Linux syslog actually DOES filter duplicate entries

    # grep repeated /var/log/syslog

    Apr  5 09:13:43 xxxx last message repeated 3 times

    Apr  5 09:14:37 xxxx last message repeated 5 times

    Apr  5 09:15:50 xxxx last message repeated 7 times

    But if there are two programms spamming at the same time or the log line changes even one letter, you’re out of luck.

  14. Ben Hutchings: There’s a team working on the next generation of event logging, called "Crimson". There’s a brief mention of it here:,1895,1826615,00.asp

    That’s pretty much all I know about Crimson.

  15. Ben Hutchings says:

    Writing a logging system worth a damn would make things better.

    * Provide a generic message DLL, or make message DLLs optional. The requirement for message DLLs makes remote access to event logs nigh-on useless.

    * Allow logs to grow larger and implement configurable log rotation.

    * Allow exporting entire log files as plain text.

    * Use the log consistently. Currently I often see message boxes for service failures, directing me to the event log, which doesn’t actually show me the messages.

  16. KoryG says:

    Don’t forget that some people (or possibly governments) audit everything, and cannot afford neither losing events (full eventlog/overwrites) nor crashing when the eventlogs are full (crashonauditfail), so there is;en-us;312571 which implements AutoBackupLogFiles.

  17. el says:

    The default value on install is delete items older than 7 days. This is a pain as the event logs fail if 512k is reached. It’s on my checklist of changes for "things that are really irritating" on a fresh install.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index