Dominik, Thank you for your reply.
>> please don't expect a sensible response within hours, especially with such a >> complex problem. No problem, I looked at the archive and noticed I was the only post this month so was thinking that maybe a newer list existed. >> :-) At first sight, if it did run for over two years and suddenly keeps >> crashing on a daily basis it is >> very unlikely that something that was not modified is the actual culprit. I agree, nothing in the application has changed as I can see all of the dates of the files are from the last deployment in Nov 2015. >> Did any modifications happen lately that you are aware of? The only thing I can see is that the box has been getting regular windows updates which of course includes .NET and OS updates. Could it be that something in the framework has changed behavior of something that is now creating this issue? >> Please note that IIS has some interesting default behavior, it would for >> instance start a new instance of a site before the old site is destroyed. >> This means that multiple instances of the same site use the same >> configuration and are therefore going to log and roll into the same files. >> This is well known [1][2] and has been raised as an issue several times on >> this list. >> The symptoms you see sound very much like that, but note that this is just a >> guess. >> [1] >> https://www.google.it/search?q=log4net+iis+deadlock&oq=log4net+iis+deadlock >> [2] http://hectorcorrea.com/blog/log4net-thread-safe-but-not-process-safe/17 Yes, I read that article [2] I had our operations group modify IIS set “Disable Overlapped Recycle” to true. We are also only running 1 worker process so nothing in our install applies to the web garden scenario. Note that I figured this might be the culprit but we have had the same deadlock happen after this change. >> Please note that it is known that an application can also cause log4net to >> deadlock [3]. >> [3] https://issues.apache.org/jira/browse/LOG4NET-298 This particular application is not using any async/task code so not sure if other scenarios apply? >> Further there is also this issue [4]. >> [4] https://issues.apache.org/jira/browse/LOG4NET-178 We are not seeing an issue with logging stopping and we also changed our app pool recycle to a specific time rather than the default of 1720 minutes. When we have had our deadlock issue it has not been during an app pool recycle (unless IIS was trying to kick the process for other reasons, although nothing in event viewer indicating something was trying to recycle). Anything in this particular bug that you think I might want to look at that still might be related even though the symptom is not the same? We have also installed Debug Diagnostics on the machine to take memory dumps and analyze the results and this made it really easy to determine the deadlock issue and provide the traces previously. If you have any suggestions for further diagnosing it would be appreciated. Was thinking that maybe I would have enabled log4net debugging?
