EventLogTraceListener Can Cause an Application to Crash
Trace listeners are a great mechanism for troubleshooting and monitoring applications in production environment. After you have decorated your code with the necessary
Debug calls, you only have to add the desired listeners either in code or in the configuration file and voila: the application starts emitting information to the configured destinations. Usually there is no need to have trace listeners attached all the time, you can only add them to the configuration file when you need to troubleshoot a problem.
What I didn't know until recently, is that by adding a trace listener to your application you can cause it to crash. That's definitely not something I wanted or expected to happen! After investigating the issue further the offender turned out to be
EventLogTraceListener which (obviously) logs information to the event log. To do that the event log source is required and therefore it needs to be specified when adding (initializing) the
EventLogTraceListener. And here lies the root of the problem.
To register a new event log source, administrative privileges are required. If the event log source is not yet registered and the user running the application is not an administrator, the call to
Trace will raise a security exception. If this exception is not handled properly, the application will crash. To be on the safe side all
Debug calls in your application should be in a try/catch block. And I have often seen this not being the case, in particular when the calls are already placed in a catch block. The other option is of course to ensure that the account has administrative privileges or that the event log source is already registered. But is it really possible to be 100% sure of that in production environment?
What I find surprising is that there doesn't seem to be any consistency between different trace listeners provided in the framework.
TextWriterTraceListener has a similar security related problem when the user doesn't have write permissions for the specified log file location. But this situation is handled in the trace listener itself which simply doesn't write the information to the log file if it can't. It doesn't raise any exceptions which (at least for me) is the expected behavior. Why is this not the case with