System.Diagnostics.Trace not working in web app under ApplicationPoolIdentity

Question

I have a web application which does (ab)use of System.Diagnostics Tracing. As usual, everything went fine until we hit production this week, where none of our listeners were being hit.

Researching a bit, it was clearly a User Account permission issue. Changing from ApplicationPoolIdentity to LocalSystem seemed to do the trick. However, in our production environment changing the User that runs to LocalSystem is a no go. I suspect it has something to do with the security permission needed to run unmanaged code.

Is there another way to make Tracing work under ApplicationPoolIdentity? Or (as our system administrator suggested) Should we create a custom account to run that ApplicationPool?

Answer 1

What evidence do you have that your TraceListeners weren't being hit? Seems more likely to me that they were being hit, but they didn't have permission to access some required resource (such as a file). In which case the solution might be as simple as giving your ApplicationPoolIdentity permissions on the appropriate disk folder.

I suggest you post more details of the listeners you're using (e.g. the <system.diagnostics> section of your web.config file, and of the exact errors you're seeing.

I suspect it has something to do with the security permission needed to run unmanaged code.

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

We tried EventLogTraceListener and even TextWriterListener on a folder that the user should have permissions.

You need to explicitly give permissions to the application pool identity, which won't have permissions by default.

Give read/write permission to the folder used by TextWriterListener to "IIS AppPool\DefaultAppPool" or whatever application pool name you're using.

As for the event log, non-administrators don't typically have permission to create an Event Source, so you should either create the Event Source manually during application installation, or alternatively it might be possible to use an existing Event Source (such as ".NET Runtime").

I think that it's not a specific listener that needs unmanaged code permissions, but the whole tracing functionality.

You're barking up the wrong tree here. Permission to run unmanaged code is a Code Access Security permission, which wouldn't be affected by the account the application runs under. And you say it works fine under the LocalSystem account.