我有一个 Web 应用程序，它（ab）使用 System.Diagnostics Tracing。像往常一样，一切都很顺利，直到我们本周开始制作，我们的听众都没有受到打击。
研究了一下，这显然是一个用户帐户权限问题。从ApplicationPoolIdentity更改为LocalSystem似乎可以解决问题。但是，在我们的生产环境中，更改运行到 LocalSystem 的用户是不行的。我怀疑它与运行非托管代码所需的安全权限有关。
是否有另一种方法可以在 ApplicationPoolIdentity 下进行跟踪？或者（正如我们的系统管理员建议的那样）我们是否应该创建一个自定义帐户来运行该应用程序池？
你有什么证据表明你的 TraceListeners 没有被击中？在我看来，他们被击中的可能性更大，但他们无权访问某些必需的资源（例如文件）。在这种情况下，解决方案可能就像在适当的磁盘文件夹上授予您的 ApplicationPoolIdentity 权限一样简单。
我建议您发布您正在使用的侦听器的更多详细信息（例如<system.diagnostics>，您的 web.config 文件的部分，以及您看到的确切错误。
我怀疑它与运行非托管代码所需的安全权限有关。
您认为哪些跟踪侦听器使用非托管代码？
我们在用户应该拥有权限的文件夹上尝试了 EventLogTraceListener 甚至 TextWriterListener。
您需要显式授予应用程序池标识权限，默认情况下它没有权限。
将 TextWriterListener 使用的文件夹的读/写权限授予“IIS AppPool\DefaultAppPool”或您正在使用的任何应用程序池名称。
至于事件日志，非管理员通常没有创建事件源的权限，因此您应该在应用程序安装期间手动创建事件源，或者可以使用现有的事件源（例如“ .NET 运行时”）。
我认为它不是需要非托管代码权限的特定侦听器，而是整个跟踪功能。
你在这里叫错树了。运行非托管代码的权限是一种Code Access Security权限，不受应用程序运行帐户的影响。你说它在 LocalSystem 帐户下工作正常。