Tras instalar KB5035849 en Windows Server 2019, algunos servidores IIS con “No Managed Code” y “Classic Pipeline” ven cómo Carbon Black termina w3wp.exe al detectar accesos a archivos en la unidad del sistema. Aquí tienes un plan práctico para resolverlo sin abandonar Classic.

Resumen del problema

Al aplicar la actualización KB5035849 en Windows Server 2019, determinados pools de aplicaciones de IIS configurados con No Managed Code y Classic Pipeline empiezan a reciclarse o a detenerse de forma súbita. La investigación revela que Carbon Black (EDR/NGAV) mata el proceso w3wp.exe al observar patrones de acceso a disco en la unidad del sistema. Al desinstalar el parche, el síntoma desaparece. Como apaño, cambiar el pool a .NET CLR v4.0.30319 + Integrated Pipeline evita las caídas, pero el proveedor de la aplicación exige conservar Classic + No Managed Code.

Señales y evidencias que verás

Indicio	Dónde verlo	Qué indica
Evento “Application Error” con w3wp.exe	Registro de Windows > Aplicación	Terminación del worker process; no siempre hay dump si lo mata el EDR.
Eventos WAS/IIS de reciclado o detención del pool	Registros “IIS-W3SVC-WP/Operational” y “WAS”	El pool se detiene por fallo del proceso; suele correlacionar con la acción del EDR.
Alarma/detección con acción Kill sobre w3wp.exe	Consola de Carbon Black / registro del sensor	Regla de prevención que bloquea una operación de archivos o comportamiento del proceso.
El síntoma desaparece tras revertir KB5035849	Comprobación controlada	La actualización cambia el patrón de acceso/telemetría que provoca el disparo en el EDR.

Causa probable, en términos prácticos

La actualización KB5035849 introduce cambios que alteran la superficie de I/O y/o el flujo de inicialización de w3wp.exe bajo Classic Pipeline, sin CLR cargado. Ese pequeño cambio hace que ciertas políticas de Carbon Black interpreten como sospechosas operaciones de lectura/escritura en rutas del sistema. Al pasar el pool a Integrated Pipeline con CLR v4, cambian las llamadas y el EDR deja de dispararse, pero eso no es aceptable para aplicaciones que requieren Classic.

Objetivo

Conservar Classic + No Managed Code sin que Carbon Black termine w3wp.exe y sin debilitar la postura de seguridad.

Plan de acción recomendado

1. Confirmar la causa exacta
   
   • En Carbon Black, identifica el ID de la detección, la regla que se activó, la acción aplicada y la ruta/operación concreta que lo dispara (por ejemplo, lectura en %SystemDrive%\Windows\Temp\ o escritura en %SystemRoot%\System32\inetsrv\config\).
   • Correlaciona con el Visor de eventos: confirma que la terminación es exógena (EDR) y no un fallo interno de la app.
2. Actualizar Windows y el sensor del EDR
   
   • Instala la acumulativa más reciente para Windows Server 2019 que sustituya KB5035849 (por ejemplo, KB5036896 y posteriores).
   • Actualiza el sensor/agent de Carbon Black a la rama recomendada por tu equipo de seguridad y aplica las políticas actuales (algunas mitigaciones llegan vía contenido de reglas).
3. Ajustar la política de Carbon Black que aplica a los servidores IIS afectados, con cambios quirúrgicos:
   • Aprobar el proceso w3wp.exe firmado por Microsoft en ese grupo de servidores (publisher/verificación de firma), de modo que ese binario concreto no se bloquee por la regla ofensora.
   • Crear exclusiones específicas de archivo/ruta basadas en las evidencias de la detección: la carpeta de la aplicación, %SystemDrive%\inetpub\, %SystemRoot%\Temp\ o %SystemDrive%\Windows\Temp\* si aparece en el evento. Evita excluir de forma genérica C:\.
   • Para la regla concreta que dispara el Kill, cambia la acción a Report o Bypass únicamente para el tag o policy group de “IIS Classic”.
   • Aplica y fuerza la actualización de política; recicla el App Pool y valida con tráfico real.
4. Mitigaciones temporales si lo anterior no está listo
   • Revertir KB5035849 hasta tener aprobada la excepción de seguridad.
   • Documentar y mantener el workaround de Integrated + CLR v4 de manera transitoria mientras se afina la política del EDR.
5. Verificación y cierre
   • Volver a Classic + No Managed Code, ejecutar pruebas de carga y monitorizar que Carbon Black ya no genera terminaciones.
   • Guardar IDs de detección y eventos para escalar a soporte de Microsoft/VMware Carbon Black si reaparece.

Checklist de investigación rápida

Acción	Comando o ruta	Resultado esperado
Comprobar presencia de KB	Get-HotFix -Id KB5035849	Confirma si está instalada en el host.
Listar últimas actualizaciones	Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10	Ordena por fecha para correlacionar con el inicio del problema.
Revisar eventos de IIS-W3SVC-WP	Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > IIS-W3SVC-WP	Encuentra eventos de terminación y reciclado del worker process.
Buscar en Application Error	Visor de eventos > Aplicación > origen “Application Error”	Detecta fallos correlados con la acción del EDR.
Correlacionar con el EDR	Consola Carbon Black > eventos para w3wp.exe	Identifica la regla, acción y ruta de archivo involucradas.

Ajustes de política en Carbon Black sin perder seguridad

El truco está en acotar la excepción. En lugar de “permitir todo en C:\ para w3wp.exe”, delega en tres mecanismos complementarios:

Regla o ámbito	Propuesta	Detalle y notas
Aprobación del proceso	Permitir w3wp.exe con firma verificada de Microsoft	Condición por publisher/firma + hash de versión. Limítalo al grupo de servidores “IIS-Classic”.
Exclusión de rutas	Excluir solo las carpetas que aparecen en la detección	Ej.: %SystemDrive%\inetpub\wwwroot\TuApp\, %SystemDrive%\inetpub\temp\, %SystemRoot%\Temp\*.
Modificación de acción	De Block/Kill a Report/Bypass para la regla gatillo	Ámbito: etiqueta del servidor o grupo. Revisa impacto con auditoría al 100%.
Supervisión reforzada	Alertar, no matar, cuando el proceso sea w3wp.exe y el signer sea Microsoft	Compensa con monitorización de integridad de archivos y de conexiones salientes.

Rutas típicas a evaluar para exclusión

Valida siempre con evidencias del evento del EDR antes de excluir. Aquí tienes candidatos frecuentes en IIS:

Ruta	Motivo habitual	Tipo de exclusión sugerida	Observaciones
%SystemDrive%\inetpub\wwwroot\TuApp\*	Lectura/escritura de ficheros temporales de la app	Lectura/escritura por w3wp.exe	Aplicar por carpeta de la app, no por inetpub completo.
%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files\*	Compresión dinámica y caché	Escritura por w3wp.exe	Muy común en sitios con compresión habilitada.
%SystemRoot%\System32\inetsrv\config\*	Lectura de applicationHost.config	Lectura por w3wp.exe	Evita excluir escritura salvo que la app lo requiera.
%SystemRoot%\Temp\ / %SystemDrive%\Windows\Temp\	Temporales generados por extensiones o módulos	Lectura/escritura por w3wp.exe	Prefiere subcarpetas específicas si es posible.

Buenas prácticas para no degradar la seguridad

• Granularidad por proceso, regla y ruta. Nada de comodines amplios.
• Ámbito acotado al grupo “IIS Classic” o a tags específicos.
• Temporalidad: pon fecha de caducidad a la excepción y revisiones periódicas.
• Compensación: aumenta el nivel de logging y la telemetría mientras la excepción esté activa.
• Pruebas en preproducción con tráfico representativo antes de tocar producción.

Procedimiento operativo paso a paso

Confirmación de causa

1. En Carbon Black, abre el evento que mató w3wp.exe y captura: ID de detección, regla, acción, hash de w3wp.exe, ruta y operación de archivo.
2. En el servidor, correlaciona hora exacta con el Visor de eventos (IIS-W3SVC-WP/Operational y WAS) y con el registro “Application Error”.
3. Comprueba la presencia del parche y el histórico de instalación con PowerShell.

# ¿Está instalada KB5035849?
Get-HotFix -Id KB5035849

Últimas 20 actualizaciones instaladas
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

Eventos recientes de IIS-W3SVC-WP en los últimos 2 horas
Get-WinEvent -LogName "Microsoft-Windows-IIS-W3SVC-WP/Operational" `
  | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-2)} `
  | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Actualización controlada

Si tu política lo permite, aplica la acumulativa que sustituye KB5035849 y, en paralelo, actualiza el sensor de Carbon Black y su política. Valida en un nodo de preproducción o en una fracción del farm.

Ajuste de políticas del EDR

En la política que aplica a los servidores IIS:

• Crea una regla de excepción para w3wp.exe firmado por Microsoft, limitada al grupo “IIS-Classic”.
• Agrega exclusiones de ruta únicamente para los directorios que aparecen en la detección.
• Cambia la acción de la regla gatillo de Kill a Report o Bypass en el ámbito de estos hosts.

Validación técnica

Reinicia el pool y lanza una prueba de humo. Un ejemplo simple:

# Reiniciar el pool afectado (sustituye NOMBREPOOL)
Import-Module WebAdministration
Restart-WebAppPool -Name "NOMBREPOOL"

Llamadas de prueba a una URL saludable

1..50 | ForEach-Object {
try {
\$r = Invoke-WebRequest "[https://tuapp/health](https://tuapp/health)" -UseBasicParsing -TimeoutSec 10
"{0} - {1}" -f (Get-Date), \$r.StatusCode
} catch {
"{0} - ERROR: {1}" -f (Get-Date), $\_.Exception.Message
}
Start-Sleep -Milliseconds 200
} 

Mitigaciones temporales

• Revertir el parche hasta que Seguridad apruebe la excepción: wusa /uninstall /kb:5035849 /quiet /norestart Documenta el rollback y el plan para reinstalar con la política ajustada.
• Mantener Integrated + CLR v4 como workaround transitorio. Registra el riesgo, fecha objetivo de retirada y plan de pruebas para volver a Classic.
• Auto-recuperación: habilita alertas y reinicio automático del pool si se detiene, para reducir impacto mientras se implementa la solución definitiva.

Verificación y criterios de aceptación

Métrica	Objetivo	Cómo medir
Terminaciones de w3wp.exe por EDR	Cero en 72 horas	Panel de detecciones de Carbon Black filtrado por host.
Eventos críticos de WAS/IIS	Cero eventos nuevos	Consultas programadas en los logs operativos de IIS.
Disponibilidad de la app	≥ 99,9% durante la ventana de observación	Monitor de salud y análisis de logs HTTP.

Preguntas frecuentes

¿Por qué solo ocurre en Classic + No Managed Code?
Porque el pipeline Classic y la ausencia de CLR cambian el orden y la forma de cargar módulos y tocar disco durante el arranque/ejecución. Ese patrón, tras la actualización, puede cruzarse con heurísticas del EDR que consideran anómalas determinadas operaciones en rutas del sistema.

¿Cambiar a Integrated + CLR v4 es seguro como solución permanente?
Solo si el fabricante de la aplicación lo certifica. Si exige Classic + No Managed Code, trata el uso de Integrated como mitigación temporal hasta cerrar la excepción en el EDR.

¿Puedo excluir C:\ entero para salir del paso?
No. Es una mala práctica que degrada gravemente la seguridad. Prefiere exclusiones acotadas por proceso y ruta concreta.

¿Hay un “Known Issue” oficial que vincule KB5035849 con IIS?
No se observa un problema conocido ampliamente documentado que atribuya fallos de IIS a KB5035849 por sí mismo; la experiencia de campo apunta a ajustar Carbon Black tras el cambio de comportamiento que introduce el parche.

Errores comunes y cómo evitarlos

• Excluir demasiado: evita comodines amplios; revisa rutas reales de la detección.
• No limitar el ámbito: aplica excepciones solo al grupo de servidores IIS afectados.
• Olvidar la caducidad: añade recordatorio para revisar/retirar la excepción.
• No probar carga: ejecuta pruebas con tráfico representativo, no solo “hola mundo”.
• Confundir causa: diferencia un crash genuino de aplicación de una terminación provocada por el EDR.

Playbook listo para ejecutar

1. Documenta la incidencia: hosts impactados, fechas, versión del sensor, políticas y reglas activas.
2. Extrae del EDR el ID de detección, la regla y la ruta/operación de archivo que dispara la acción sobre w3wp.exe.
3. Actualiza Windows a la acumulativa que sustituya KB5035849 y actualiza el sensor de Carbon Black.
4. Crea una excepción solo para w3wp.exe firmado por Microsoft y las rutas implicadas, limitada al grupo “IIS-Classic”.
5. Cambia la acción de la regla gatillo a Report o Bypass para estos hosts.
6. Recicla el pool, ejecuta pruebas de humo y de carga; monitoriza EDR y eventos de IIS.
7. Si todo es estable, vuelve a Classic + No Managed Code y mantén observabilidad reforzada 72 horas.
8. Cierra con postmortem: qué cambió, qué reglas se tocaron, cuándo se retira la excepción.

Apéndice de comandos útiles

Administración de IIS

Import-Module WebAdministration

Ver configuración del pool

Get-ItemProperty IIS:\AppPools\NOMBREPOOL | Select-Object name, managedPipelineMode, managedRuntimeVersion

Establecer Classic + No Managed Code

Set-ItemProperty IIS:\AppPools\NOMBREPOOL -Name managedPipelineMode -Value Classic
Set-ItemProperty IIS:\AppPools\NOMBREPOOL -Name managedRuntimeVersion -Value ""

Reciclar el pool

Restart-WebAppPool -Name "NOMBREPOOL" 

Consultas de eventos

# Últimos eventos de WAS relacionados con caídas del pool
Get-WinEvent -LogName "Microsoft-Windows-WAS/Operational" `
 | Where-Object {$_.Message -match "application pool"} `
 | Select-Object TimeCreated, Id, Message | Format-Table -AutoSize

Fallos de Application Error para w3wp.exe

Get-WinEvent -LogName Application ` | Where-Object {$_.Message -match "w3wp.exe"}`
\| Select-Object TimeCreated, Id, ProviderName, Message | Format-List 

Control de actualizaciones

# Desinstalar la KB como mitigación temporal
wusa /uninstall /kb:5035849 /quiet /norestart

Comprobar que una KB posterior está presente

Get-HotFix -Id KB5036896 

Notas útiles

• No existe evidencia sólida de un “problema conocido” público de Microsoft que relacione específicamente KB5035849 con caídas de IIS; lo efectivo ha sido ajustar Carbon Black tras el cambio de comportamiento introducido por el parche.
• Mantén las exclusiones lo más granulares posible (por proceso, regla y rutas implicadas) para no degradar la postura de seguridad.
• Centraliza los servidores IIS con Classic en un grupo de política propio para aislar excepciones.

Conclusión

Cuando un parche cambia el patrón de ejecución de w3wp.exe, los EDR pueden reaccionar de forma agresiva. La solución limpia aquí no es renunciar a Classic, sino alinear versiones de Windows y del sensor, y ajustar quirúrgicamente la política de Carbon Black: aprobar el binario firmado, excluir rutas concretas observadas en la detección y modificar la acción de la regla únicamente para el grupo afectado. Con validación adecuada y métricas de éxito claras, volverás a Classic + No Managed Code sin caídas y sin abrir agujeros de seguridad.