I recently had a problem during the deployment of a windows service. Four computers did not cause any problems, but on the fifth any attempt to start the service failed due to an exception. The exception stack trace is written to the event log, so I though it should be easy to identify the cause:
protected override void OnStart(string[] args) { EventLog.WriteEntry('Starting service', EventLogEntryType.Information); try { //... base.OnStart(args); } catch (Exception ex) { EventLog.WriteEntry('Service can not start. Stack trace:' + ex.StackTrace, EventLogEntryType.Error); Stop(); return; } EventLog.WriteEntry('Service started', EventLogEntryType.Information); }
But alas, no information was ever written to the log. I finally traced it to the first log entry being written. It threw an exception because the application event log was full with recent entries, and configured to only overwrite entries older than 7 days.
What are the best practices on writing to the event log, considering that I can not change the configuration of the application event log?
Should I always put EventLog.WriteEntry in a try block, if yes, how should I handle the exception (writing it to the event log is probably a bad idea), should I check on the event log status in my OnStart method, or do you have any better suggestion?
I think logging exceptions is one of the rare cases where you are better off swallowing the exception. In most cases you don’t want your app to fail on this.
But why are you writing your logging code yourself anyway? Use a framework like NLog or Log4Net! These also swallow exceptions like I just said but you can redirect the logging output to a different location (file, messagebox etc.) with just a configuration change. This makes solving problems like this much easier.