Creating dynamic log files via Log4Net by process ID & date without rename policy - log4net

Question

I have been scratching around Stack and the net for a solution to my particular use case but has yet have not found one.
Log4Net 1.2.10
IIS 6.1
.NET application using CastleCore
My requirement is to create a unique file name based on process id per hour with process id, date and hour in the filename. Although if the process Id were to change within that hour then create a new file name based on that process id and date/hour.
I have a service running on a web farm in IIS, this has 4 worker processes running simultaneously, 2 app pools 2 process per pool. So 4 log files being written too simultaneously.
My current config (below) appears to work upto a point. The files get created and are logged too simultaneously, great! The logging is quite heavy in that over the course of an hour it will log around
200MB per process id.
During the course of the hour one of the files out of the two simply stops writing. I have set Minimal lock and different process id's which should prevent any deadlocks, race conditions or collisions.
My current config is below
<appender name="WSG_file_appender" type="WSG.Logger.LogAppender,WSG.Logger">
<file type="log4net.Util.PatternString" value="../../WSG/IWSGServices-[%processid]" />
<datePattern value="-dd.MM.yyyy-HH'.log'" />
<staticLogFileName value="false"/>
<rollingStyle value="Date" />
<appendToFile value="true" />
<maximumFileSize value="500MB" />
<maxSizeRollBackups value="50" />
<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="[%d] [%t] %-5p [%m]%n" />
</layout>
The format of the log that is generated is:
IWSGServices[8977]-23.03.15.14.log
This is what I want, in the above example that is the log for process ID 8977 for 1400 hours. At 1500 new logs gets generated for each process id in use and the new hour stamp.
When the logging stops in log4net debug mode I get this error many times:
log4net:ERROR [LogAppender] Failed to write [].
System.ArgumentOutOfRangeException: Count cannot be less than zero.
Parameter name: count
at System.String.CopyTo(Int32 sourceIndex, Char[] destination, Int32 destinationIndex, Int32 count)
at System.IO.StreamWriter.Write(String value)
at log4net.Util.QuietTextWriter.Write(String value)
I have not found any similar cases of this error within log4net so use cases are limited. I suspect there is some I/O issue or log4net (at least this older version) is not capable of fulfilling my use case. However I am not convinced latest versions will be either. I have not upgraded log4net yet due to reported issues with later versions and Castle Core implementations.
Setting StaticLogFileName=true results in filenames being created without the date stamp i.e WSGServices[8699], and then on the hour gets renamed to IWSGServices[8977]-23.03.15.14.log for example. This is not what I want as for this use case I do not want files to get renamed as I have a log reader which sees this as a new file and parses it again.
I have tried a large number of combinations including with and without locking models, Rolling styles, datepatterns and the config above seems to be the closest I have come. It's possible this config will work if I roll per minute but this will result in over 3000 log files per day which is not practical.
I'd like to achieve this under the current version of log4net I am using, however if I patch to 2.11 there is a setting of PreserveLogFileNameExtension parameter although the file will still get renamed but just not after the extension.
One suggestion I looked at was setting the IIS pool setting Disable Overlap Recycle to false but this didn't make any difference as would only come into play on recycles of the app pool.
Another alternative is too log both processes form each app pool to a single log file although due to the amount of writes I think this solution would not work without further process collisions.
Any help appreciated in case I have missed something or if anyone has used this in current or later log4net versions.