Tips on Debugging W3SVC Errors?

I'm getting the following error in the System event log:

Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1011
Date:  2/18/2008
Time:  11:35:24 AM
User:  N/A
Computer: [servername]
Description:
A process serving application pool '[websitename]' suffered a fatal
communication error with the World Wide Web Publishing Service. The process id
was '4104'. The data field contains the error number. 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 6d 00 07 80               m..€    


The following .NET Runtime error is also recorded in teh Application log:

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date:  2/18/2008
Time:  11:35:22 AM
User:  N/A
Computer: [servername]
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 system.web, P5
2.0.0.0, P6 450b6659, P7 1feb, P8 1ef, P9 system.web.httpexception, P10 NIL.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 63 00 6c 00 72 00 32 00   c.l.r.2.
0008: 30 00 72 00 33 00 2c 00   0.r.3.,.
0010: 20 00 77 00 33 00 77 00    .w.3.w.
0018: 70 00 2e 00 65 00 78 00   p...e.x.
0020: 65 00 2c 00 20 00 36 00   e.,. .6.
0028: 2e 00 30 00 2e 00 33 00   ..0...3.
0030: 37 00 39 00 30 00 2e 00   7.9.0...
0038: 31 00 38 00 33 00 30 00   1.8.3.0.
0040: 2c 00 20 00 34 00 32 00   ,. .4.2.
0048: 34 00 33 00 35 00 62 00   4.3.5.b.
0050: 65 00 31 00 2c 00 20 00   e.1.,. .
0058: 73 00 79 00 73 00 74 00   s.y.s.t.
0060: 65 00 6d 00 2e 00 77 00   e.m...w.
0068: 65 00 62 00 2c 00 20 00   e.b.,. .
0070: 32 00 2e 00 30 00 2e 00   2...0...
0078: 30 00 2e 00 30 00 2c 00   0...0.,.
0080: 20 00 34 00 35 00 30 00    .4.5.0.
0088: 62 00 36 00 36 00 35 00   b.6.6.5.
0090: 39 00 2c 00 20 00 31 00   9.,. .1.
0098: 66 00 65 00 62 00 2c 00   f.e.b.,.
00a0: 20 00 31 00 65 00 66 00    .1.e.f.
00a8: 2c 00 20 00 73 00 79 00   ,. .s.y.
00b0: 73 00 74 00 65 00 6d 00   s.t.e.m.
00b8: 2e 00 77 00 65 00 62 00   ..w.e.b.
00c0: 2e 00 68 00 74 00 74 00   ..h.t.t.
00c8: 70 00 65 00 78 00 63 00   p.e.x.c.
00d0: 65 00 70 00 74 00 69 00   e.p.t.i.
00d8: 6f 00 6e 00 20 00 4e 00   o.n. .N.
00e0: 49 00 4c 00 0d 00 0a 00   I.L.....


The scenario is as follows:

I've got a custom IHttpAsyncHandler that creates an instance of a custom
AsyncOperation object in the BeginProcessRequest() method.  The custom
AsyncOperation object is responsible for handling a number of file extensions
mapped in the <httpHandlers> section of the Web.Config file.  19 files
types are being handled in all, and among them is JPG.  

The AsyncOperation's StartAsyncTask() method analyzes the request string and
determines whether the file is static, and can be served from disk, or if the
file is dynamic and must be requested from a secondary source.   

If the file is dynamic, the method creates a new TcpClient object and uses it to
connect to a remote server.  It then commands this remote server to generate the
requested file.  The remote server returns an array of byte data representing
the requested file.  

If the file is static, the method checks to see if the file exists on disk and
if so, it uses the File.ReadAllBytes() method to return the array of byte data
representing the file - it should also be noted that if a particular query
string variable is found, the code generates a tumbnail of the jpeg as the
return data rather than the original jpeg itself.  

In either event, the resulting byte array is then written to the
Context.Response.OutputStream which what obtained during the custom
AsyncOperation's constructor.  It should also be noted that if the
Request.Headers indicate that gzip encoding is accepted, a GZipStream object is
used to write the byte array data back to the client.  Context.Response.Buffer
is also set to True.

This all seems to work fine.  There was no significant change in page load times
after moving the processing of JPEG files into this custom routine.  The
functionality this code provides seems to work perfectly and no errors are ever
presented to the user.  But something is failing to cause the errors shown
above.  I have also had to increase the error threshhold on the site's
Application Pool, because there were a couple of times where this error occured
frequently enough to cause IIS to shutdown the app pool.  But again, there is no
visible problem within the site when these errors occur.  There are some try
block and custom errors coded to be written to the Context.AddError() method,
but these do not appear in the event log so I don't think it is my code directly
causing the errors.

 Does anyone have any advice as to how I might track down exactly what is
failing between the site and the WWW service?

Hope this helps. This solution describes a way to implement a error handler (
for all the unhandled errors that are happenign in a child thread spawned by UI
thread) that would otherwise crash the web server. I recommend you modify the
sample code from the below link remove the check thats there for preventing
duplicates.

 http://support.microsoft.com/kb/911816

Now to make sure your worker process does not crash ( this is the reason W3SVC
is returning an error stating it lost contact with worker process) you need to
add the below entry in file called ASPnet.config ( also documented in the above
KB) in your framwork folder.

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy enabled="true" />
    </runtime>
</configuration>

Thanks for the link to the kb article.  The article describes a situation
similar to mine, but not the same.  In my case, actual HttpExceptions are being
generated, rather than system exceptions, and the code does not seem to cause
the application to exit - that is, the request does not seem to come to an
abrupt end...  But I may be able to borrow from some of the logging example.

I suppose I can wrap the entire async method in a Try block and log whatever
exception it might generate, but I was hoping to have a way to actually debug
the process...

Thanks though for the input.