在我的网站中，我启用了失败请求跟踪日志功能，并将其配置为将日志文件存储到默认文件夹%SystemDrive%\inetpub\logs\FailedReqLogFiles和我设置了一些失败的请求跟踪规则。
我已为应用程序池标识授予该文件夹的写入权限，并已检查IIS_IUSRS帐户是否也对该文件夹具有写入权限。
我的网站是一个使用WebGarden配置的ASP.NET MVC应用程序(应用程序的池设置为4个工作进程(。
日志文件正确存储在文件夹中，但我在事件日志中收到连续的警告消息，如下所示：
FailedRequestTracing模块无法将缓冲的事件写入日志与失败定义匹配的请求的文件。不会有日志生成，直到该条件得到纠正。问题发生在在过去%2分钟内至少%1次。数据就是错误。
原因似乎是多个工作进程试图在同一文件夹中创建文件日志，因此在按顺序创建具有相关编号的下一个文件名时，它们会发生冲突/冲突，正如aniler在这里解释的那样。
如何解决此问题以避免警告消息不断出现在事件日志中？
注意：我使用的是Windows Server 2012 R2 Standard下的IIS 8.5.9600.16384。
FailedRequestTracing模块未能将缓冲事件写入与失败定义匹配的请求的日志文件时，会记录此事件。你可以尝试以下步骤来解决这个问题。
- 启用对日志文件目录的跟踪访问
- 查找当前失败的请求跟踪日志文件路径设置
- 请确保配置的失败请求跟踪日志文件目录存在
- 请确保IIS_IUSRS组具有写入日志文件目录的权限
有关此错误的更多信息，请参阅此链接：FailedRequestTracing模块未能将缓冲事件写入与失败定义匹配的请求的日志文件。
当没有为某个网站编写FR日志时(例如FailedReqLogFiles\W3SVC1(，在我的情况下，原因有点像MS IIS日志记录例程错误/功能生效：
日志文件的名称类似于"；fr[递增数].log"；，在时间线中逐个创建。
因此，当由"；"修改日期"；，文件名(数字部分(应该向上。例如。凌晨1:00-fr000001.log；凌晨1:00-fr000002.log
但是"；有时"；(对我来说，原因尚不清楚(日志记录机制打破了这一原则，新的文件是用旧的DateModified编写的。也许只写log1比写log2要花更长的时间。
这种情况将阻止进一步的FR日志记录。
我写了一个PS脚本，检查这些不一致性，并将它们从文件夹中存档/移走。
一旦该操作完成(这样文件号就会随着DateModified一起上升(，就会再次创建新的FR日志。
需要注意的一点是：DateModified的不一致性可能以毫秒为单位(在Windows资源管理器中不可见(。