Logging problems in production environment

Topics: Exception Handling Application Block, Logging Application Block
Apr 27, 2007 at 2:11 PM
I defined a Logging Handler in the Exception Handling config section, to write information about exceptions to a Flat File and to the Event log. Everything works fine in local machine.
The problem is that when I move the application to the server, the writes are not always done or even worst, sometimes the file is not created.
Could you give some tips to guarantee that the file is always created and all the work done in the file and in the Event Log.
I don´t know if this could cause any problem but just in case, I´m using Windows authentication mode with identity Impersonate in my web site.
May 2, 2007 at 2:36 AM
Unfortunately, it could be a lot of things causing the problem, but sounds like a permissions problem.

The Logging Application Block has a Special Sources -> Logging Errors & Warnings Category that it will use to write logging problems to a TraceListener. This is your best way to find out errors occuring during logging. It may help determine why the file is not created sometimes and why all exceptions are not written to the log. Of course, it needs to be able to write to that TraceListener to log any problems.




David Hayden
Microsoft MVP C#

May 2, 2007 at 2:30 PM
I found out this. If you have 2 listeners, the first that writes the Event Log and the other that writes the file and you are running the application with a non admin user, even when you have file and directory rights correctly set, if the datasource that you are using in the event log does not exist, nothing happens. I think that this happens because the Logging Block fails in using the first listener and then does not run the other.
Regards, Javier.
Jul 17, 2008 at 9:54 PM
I have to confirm this and surprised it has not been fixed yet.

I had two listeners (eventlog an file) and both didn't work. I removed EventLog and boom! file was created and populated.

I thought the whole point is that one may have several listeners an if one failes - the other one still used...