Recientemente estuve trabajando en un caso que presentaba los siguientes síntomas: tras actualizar el sistema operativo de un servidor pasando de Windows Server 2003 RTM a SP2, el cliente observaba que al realizar peticiones a la aplicación web, el servidor siempre respondía con un error HTTP 503 - Service Unavailable. El log de eventos de sistema mostraba el siguiente evento indicando que el worker process de IIS (W3WP.EXE) finalizaba inesperadamente y devolvía el código de salida 0xffffffff:
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1009
Date: 17/04/2009
Time: 14:30:45
User: N/A
Computer: MYSERVER
Description: A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '1234'. The process exit code was '0xffffffff'.
El código de salida 0xffffffff es un código genérico que se puede dar por diversos motivos al inicializar el proceso W3WP.EXE (las más comunes son problemas al inicializar COM y problemas al cargar una DLL). Esta es su definición:
// the worker process exited due to a fatal error#define ERROR_WORKER_PROCESS_EXIT_CODE 0xFFFFFFFF
Una de las primeras pruebas que hicimos fue cambiar la identidad del application pool de NETWORK SERVICE a LOCAL SYSTEM. Haciendo esto vimos que el worker process se levantaba correctamente y la aplicación web servía peticiones correctamente. Por lo tanto estaba claro que era un problema de permisos, ¿pero cuál era el permiso que faltaba y porqué funcionaba sin problemas antes de actualizar a SP2?
Capturamos unas trazas con Process Monitor (configurando de nuevo la identidad del application pool como NETWORK SERVICE) que nos mostraban que se producía un acceso denegado en la rama del registro HKLM\System\CurrentControlSet\Services\W3SVC\Parameters poco antes de finalizar el proceso. Tras proporcionar permisos de lectura a la cuenta NETWORK SERVICE en dicha clave del registro, el acceso denegado ya no se producía, pero el problema original seguía ocurriendo.
Verificamos todos los permisos de las cuentas de servicio de IIS 6.0 tal y como vienen documentados en el KB Default permissions and user rights for IIS 6.0, pero todos los permisos mencionados en el artículo estaban configurados correctamente.
Finalmente, revisando los permisos de DCOM, observamos que el grupo de seguridad Everyone (Todos) no tenía los permisos DCOM predeterminados de Local Launch y Local Activation, tal y como viene indicado en el artículo DCOM Security Enhancements. Añadiendo el grupo de seguridad Everyone y proporcionando dichos permisos, el problema quedaba resuelto y logramos levantar el application pool con la identidad NETWORK SERVICE.
El motivo por el que esta configuración funcionaba en Windows Server 2003 RTM es debido a que como parte de SP1 se introdujeron mejoras en la seguridad de COM que incluyen comprobaciones adicionales para cada llamada, activación o inicio de cualquier servidor COM del equipo. Dichos cambios vienen documentados en el enlace al que hacía referencia antes (DCOM Security Enhancements).
Por último, si os encontráis con este problema y no fuera debido a la misma causa, podéis consultar el blog de Brian Murphy, ingeniero de escalación de IIS, donde hay un excelente post con otras posibles causas y soluciones para el evento 1009 de IIS: http://blogs.iis.net/brian-murphy-booth/archive/2007/03/22/how-to-troubleshoot-an-iis-event-id-1009-error.aspx.
Actualización (21 de diciembre de 2009): Recientemente se ha manifestado un problema con algunas instalaciones de IIS 6.0, en las que tras instalar la actualización KB973917 el worker process no arranca y en los logs de eventos vemos el evento 1009. Este problema se soluciona reinstalando el SP2 de Windows Server 2003. Más información sobre este problema en el siguiente KB:
Internet Information Services 6.0 may not function correctly after installing KB973917
http://support.microsoft.com/?kbid=2009746
Hasta el próximo post.
- Daniel Mossberg
puag! mil gracias, me has resuelto una mañana entera ;)