La información de este post está basada en el uso empírico del siguiente artículo “Las excepciones no controladas hacen aplicaciones que se las cierran inesperadamente en el .NET Framework, 2,0, basadas en ASP.NET”.
Cuando nos enfrentamos a caídas del worker process en Internet Information Server, la información que encontramos en el Event Log es una de las puntas para empezar la investigación.Ante una caída (crash) del proceso w3wp.exe (worker process) el sistema operativo informa el hecho en el Event Viewer con 3 entradas.
A continuación un ejemplo muestra los eventos sucedidos en forma cronológica:
Sección Application
Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 1/8/2008
Time: 7:23:11 AM
User: N/A
Computer: PC
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 mscorlib, P5 2.0.0.0, P6 46b3e871, P7 331e, P8 21c, P9 system.io.ioexception, P10 NIL.
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 1/8/2008
Time: 7:23:32 AM
User: N/A
Computer: PC
Description:Faulting application w3wp.exe, version 6.0.3790.3959, faulting module kernel32.dll, version 5.2.3790.3959, fault address 0x0000bee7.
Sección System
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1011
Date: 1/8/2008
Time: 7:23:35 AM
User: N/A
Computer: PC
Description:A process serving application pool 'MiSistema.AppPool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '10232'. The data field contains the error number.
La única punta que tenemos hasta el momento es que el tipo de la Excepción que produjo la caída es System.IO.IOException, pero necesitaríamos el stack trace para poder hacer un diagnóstico.
¿Porque se produce una caída del w3wp.exe?
Conocer porqué se produce una caída del worker process nos dará un indicio por dónde empezar a buscar.Una Excepción no atrapada en nuestro código cuyo código corre en un hilo del thread pool de ASP.NET será atrapada por el mismo ASP.NET, formateada en la típica pantalla naranja y mostrada al usuario. Lo mismo sucede con un servicio WCF que corre en IIS, la Excepción no atrapada será lanzada al invocador o en el mejor de los casos podemos atraparla centralizadamente en un behavior implementado la interfaz System.ServiceModel.Dispatcher.IErrorHandler.
La caída se produce entonces cuando la excepción no es atrapada en un hilo secundario al del thread pool de ASP.NET, o cualquier otro hilo que no corra dentro del pipeline de ASP.NET. Podría ser el caso de una excepción no atrapada en:
· Finalizer (cuyo código se ejecuta en un hilo del GC)
· Código ejecutado asinrcónicamente mediante un delegado
· Algún componente que utilice un thread pool propio.
· Etc.
En la versión de ASP.NET 2.0 el comportamiento por defecto de que sucede cuando una excepción no es atrapada en un hilo que no pertenece el thread pool es producir la caída del worker process. Esto no sucedía en versiones anteriores ASP.NET 1.0 y 1.1, donde el comportamiento es el contrario. Este cambio se debe a que una excepción no atrapada no permite la ejecución de código que en situaciones normales hubiese liberado recursos. De esta forma se evita la degradación del equipo o el abandono de locks.
Evitar caída del Worker Process (no recomendable)
En ASP.NET 2.0 es posible controlar este comportamiento modificando la entrada del aspnet.config
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
</runtime>
</configuration>
Demás está decir que esta práctica no es recomendable.
Como información agregada he aquí un extracto del documento CLR Run-Time Breaking Changes
| Short Description |
Unhandled exceptions will always be fatal to a process |
| Affected APIs |
N/A |
Severity |
Medium |
Compat Switch Available |
No |
|
| Description |
Unhandled exceptions will always be fatal to the process. They weren't necessarily always fatal in V1.0/V1.1. |
|
| User Scenario |
Applications that throw unhandled exceptions on threads other than the main thread (or ones that come into the runtime from the outside) will crash rather than continue running (when they are potentially in an invalid state) |
|
| Work Around |
Put a catch block at the top of your non-main thread, threadpool workitem, or finalizer. (Or else fix the bug that led to the exception.)
Alternatively, in the section of the application's config file, add the following:<legacyUnhandledExceptionPolicy enabled="1"/>
|
Como registrar Excepciones que producen caídas del w3wp.exe
Una forma no tan simple, pero certera de diagnosticar el problema es hacer un dump del proceso con la herramienta debugdiag.exe al momento de la caída. Pero claro no es una tarea sencilla...
Tal como lo indica el artículo, es posible registrar las excepciones que producen la caída del worker process, agregando un HttpModule de ASP.NET.
La primera ventaja que encontramos aquí es que un HttpModule se puede agregar por configuración sin necesidad de recompilar.
La segunda es que este funciona para cualquier código que corra por el pipeline de ASP.NET, ya sea código ASP.NET, un ASMX o un servicio WCF.
La clave de este module es suscribirse al evento AppDomain.CurrentDomain.UnhandledException que será lanzado frente a una First Chance Exception, y el cual no modifica el curso, con lo cual luego se lanzará la Second Chance Exception, que producirá la caída.
Es aquí entonces donde recibimos por parámetro la excepción ocurrida y la registramos en el Event Log por ejemplo.De esta forma podremos obtener información detallada de la excepción, como ser el mensaje y el stack trace.
Nota: El hecho de agregar el HttpModuile, no evita la caída del w3wp.exe.
Como probar este funcionamiento
Basta con lanzar una Exception desde un finalizer para producir la caída del worker process.
Código
El código está disponible en este artículo