HTTP 500 errors and Wincache crashes: Request for Info

For people who are experiencing 500 errors with crashes in Wincache, I would like your help in investigating something.

It turns out that the IIS FastCGI handler will terminate requests that take too long.  The default for this is 90 seconds. (see: http://www.iis.net/configreference/system.webserver/fastcgi/application#005 , the requestTimeout setting).  Additionally, there's a timer tracking FastCGI request activity (activityTimeout, default 30 seconds, see the same page).

If the php-cgi instance is killed while a script is executing, it's highly probable that Wincache's cross-process memory will get corrupted.

If Wincache's cross-process memory gets corrupted, all PHP instances in the appPool must be terminated *simultaneously* to recover. 

So, here's the ask:

For folks who are seeing event log entries where php-cgi.exe / Wincache crashed, could you check your HTTP W3C log files (%systemDrive%\inetpub\logs\LogFiles\<site>\u_ex*.log) and see if there was a 500 status message on a PHP request *before* the crash?

I'm particularly interested in the win32 status codes that on the 500 messages that happened before the 500 associated with the crash.

I'm looking into improving the diagnosability of when the FastCGI handler terminates an instance, so we can help customers see if the Wincache crashes are due to avoidable timeouts.  Additionally, I'm looking into ways that Wincache can more gracefully recover from these kinds of corruptions.

Thank you!

    --E.