System.Diagnostics.Trace does not work in a web application under ApplicationPoolIdentity

Question

I have a web application that uses (ab) using System.Diagnostics Tracing. As usual, everything went well until we hit this week, where not one of our listeners hit.

Research a bit, this is clearly a user account permission issue. Switching from ApplicationPoolIdentity to LocalSystem seems to have done the trick. However, in our production environment, the change of the User who works in LocalSystem does not go. I suspect this is due to the security permission required to run unmanaged code.

Is there any other way to get Tracing to work under ApplicationPoolIdentity? Or (as suggested by our system administrator). Should I create a user account to run this ApplicationPool?

Answer 1

What evidence do you have that your TraceListeners were not affected? It seems to me more likely that they hit, but they did not have permission to access some required resource (for example, a file). In this case, the solution may be as simple as granting ApplicationPoolIdentity permissions in the corresponding drive folder.

I suggest you post more detailed information about the listeners that you use (for example, in the <system.diagnostics> section of your web.config file and the exact errors you see.

I suspect this has something to do with the security permissions needed to run unmanaged code.

Which of your trace listeners do you think uses unmanaged code?

We tried EventLogTraceListener and even TextWriterListener in the folder where the user must have permissions.

You need to explicitly grant permissions for the application pool identifier , which by default will not have access rights.

Give read / write permission to the folder used by TextWriterListener, to "IIS AppPool \ DefaultAppPool" or to any other application pool name that you use.

As in the event log, non-administrators usually do not have permission to create an event source, so you must either create the event source manually during application installation, or it may be possible to use an existing event source (such as ".NET Runtime").

I think this is not a specific listener that needs unmanaged code permissions, but the entire trace function.

You bark on the wrong tree here. Permission to run unmanaged code is a permission of Code Access Security that will not be affected by the account that the application is running on. And you say that this works fine under the LocalSystem account.