Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Nobody ever reads the event logs…

Nobody ever reads the event logs…

Rate This
  • Comments 19

In my last post, I mentioned that someone was complaining about the name of the bowser.sys component that I wrote 20 years ago.  In my post, I mentioned that he included a screen shot of the event viewer.

What was also interesting thing was the contents of the screen shot.

“The browser driver has received too many illegal datagrams from the remote computer <redacted> to name <redacted> on transport NetBT_Tcpip_<excluded>.  The data is the datagram.  No more events will be generated until the reset frequency has expired.”

I added this message to the browser 20 years ago to detect computers that were going wild sending illegal junk on the intranet.  The idea was that every one of these events indicated that something had gone horribly wrong on the machine which originated the event and that a developer or network engineer should investigate the problem (these illegal datagrams were often caused by malfunctioning networking hardware (which was not uncommon 20 years ago)).

But you’ll note that the person reporting the problem only complained about the name of the source of the event log entry.  He never bothered to look at the contents of this “error” event log entry to see if there was something that was worth reporting.

Part of the reason that nobody bothers to read the event logs is that too many components log to the eventlog.  The event logs on customers computers are filled with unactionable meaningless events (“The <foo> service has started.  The <foo> service has entered the running state.  The <foo> service is stopping.  The <foo> service has entered the stopped state.”).  And they stop reading the event log because there’s never anything actionable in the logs.

There’s a pretty important lesson here: Nobody ever bothers reading event logs because there’s simply too much noise in the logs. So think really hard about when you want to write an event to the event log.  Is the information in the log really worth generating?  Is there important information that a customer will want in those log entries?

Unless you have a way of uploading troublesome logs to be analyzed later (and I know that several enterprise management solutions do have such mechanisms), it’s not clear that there’s any value to generating log entries.

  • That's why whenever I install Windows XP or 7 (on 7 I use the Classic XP Event Viewer msc copied from an XP installation), the first thing I do is create two new views in the Event Viewer that filter Information logs. Only errors and warnings are shown in these two views (Application Errors) and (System Errors).

  • Larry, the only thing I have noticed with the new Event Viewer is that it is noticably slower than the old one. It can, on some machines, take ages to navigate to the system events and start diagnosing a user's problems.

    I love Windows 7, and I even liked Vista, but I am not 100% onboard yet when it comes to the Event Viewer. I was able to diagnose problems just fine using the old one... And it was faster.

    But I will get used to it I suppose, and I consider it a good thing that the team spend time on improving such bits.

  • Larry, I sort of see your point (especially your response to Kim), and sort of don't. As an enterprise sysadmin I regularly read event logs (manually, not just via analysis tools), and I think your point about 'actionability' is answered by the different event classifications. If I'm looking for actionable events, I filter for Error and Warning events ... and in this way I can avoid all the chatter of “The <foo> service has started.  The <foo> service has entered the running state.  The <foo> service is stopping.  The <foo> service has entered the stopped state.”

    When I use the built-in filtering to remove the Information events (from system and app logs), what I am left with is ... tada! ... a list of actionable events!

    But when I am troubleshooting a thing and I need to know if the service even tried to start, suddenly those Information events become handy.

    So yes, people do read the event log. I coach people in how to do this regularly (at their request!), so I know that I am not the only one. If they do it very often they can easily filter out those non-actionable events. Making some grand change now to reach the goal you identify ("system and application logs should only be for actionable errors"), would seem to be a lot of work and confusion for very little real result.

  • ATI's video driver is the worst I've seen for event log pollution. Every time a video is played that the video card can decode in hardware, it spews out thousands upon thousands (no joke!) of events into the System log that are entitled "UVD information", but which contain about 5 bytes of data, the same every time. To those commentators who say that there is no such thing as too much information, I would say that they ought to try diagnosing a problem with something else after the log file has exceeded its rather small default maximum size and the relevant events are deleted as a result due to ATI spamming tens of thousands of identical events into the log.

Page 2 of 2 (19 items) 12