IIS Application Pool falha após KB5035849 no Windows Server 2019: causa Carbon Black, soluções e mitigação

Após instalar a atualização de março para Windows Server 2019, alguns ambientes IIS passaram a encerrar o application pool logo após a inicialização. Este guia explica por que isso ocorre, como confirmar a causa e quais mitigações aplicar sem abrir mão de segurança ou de suporte do fornecedor.

Índice

Visão geral do problema

Logo após a instalação do patch de março do sistema, o application pool configurado com No Managed Code e Classic Managed Pipeline passa a ser terminado de forma abrupta. Em muitos casos, a troca temporária para .NET CLR v4.0.30319 com Integrated Pipeline mantém o site de pé, mas o fornecedor da aplicação exige a configuração original.

A causa mais frequente observada em campo é uma interação do mecanismo de proteção do Carbon Black com um padrão novo de acesso a arquivos do processo w3wp.exe introduzido pela atualização. O EDR interpreta esse padrão como comportamento suspeito e finaliza o processo, o que, do ponto de vista do IIS, aparece como falha do worker do pool.

Cenário observado

Configuração do pool: No Managed Code + Classic Managed Pipeline.
Comportamento: o w3wp.exe inicia e é encerrado pelo agente de segurança segundos depois.
Mitigação provisória: ao alternar o pool para .NET CLR v4.0.30319 + Integrated Pipeline, o EDR deixa de agir e o site volta a responder; porém, essa mudança nem sempre é suportada pelo fornecedor.

Causa raiz e contexto

O w3wp.exe, processo do worker do IIS, faz chamadas intensivas a arquivos, chaves de registro e módulos nativos durante a inicialização e o carregamento de handlers. A atualização de março ajustou o fluxo e a ordem de algumas dessas operações. O Carbon Black, em determinados perfis de política, passa a classificar esse fluxo como potencialmente malicioso e conclui por bloquear o processo. Trata-se de um falso positivo clássico provocado por:

Mudança de comportamento legítimo do sistema após atualização cumulativa.
Políticas de endurecimento agressivas no EDR, especialmente em servidores com application control estrito.
Combinação específica de pipeline Classic com No Managed Code, que ativa percursos diferentes de carregamento de módulos ISAPI e filtros.

Como confirmar o impacto

Antes de alterar produção, colete evidências para confirmar que o encerramento vem do EDR e não de erro de código, permissões ou conexão com recursos externos.

Passos rápidos

Ver no Visor de Eventos:
- Em Aplicativo, procure eventos de Application Error associados a w3wp.exe (ex.: falha de aplicação com módulo desconhecido), e, se houver, anote o carimbo de data/hora, offset e o nome do pool.
- Em Sistema, filtre por Microsoft‑Windows‑WAS e W3SVC: entradas indicando reciclagens rápidas, falha de comunicação com o processo do pool ou rapid‑fail protection acionada são típicas.
Checar os registros do Carbon Black:
- No console do EDR, busque eventos de prevention ou termination cujo alvo seja w3wp.exe no mesmo carimbo de tempo.
- No servidor, verifique os logs do agente (pasta do sensor) e os logs sob Applications and Services Logs do sistema, se disponíveis para o produto.
Reproduzir com cautela:
- Recicle o pool, gere uma requisição simples e observe se o encerramento retorna com os mesmos eventos do EDR.

Mitigações e estratégia

A tabela abaixo resume as medidas discutidas em sessões de perguntas e respostas, com observações práticas para orientar a decisão.

Medida	Detalhes	Observação prática
1. Desinstalar o KB5035849	Remover o patch em Configurações ► Windows Update ► Histórico de atualizações.	Restaura o funcionamento, mas perde correções de segurança.
2. Instalar o CU mais recente (KB5036896, abril / 2024)	Disponível no Microsoft Update Catalog.	Pode conter correções que eliminem o falso‑positivo do Carbon Black.
3. Verificar “Known Issues” da Microsoft	A Microsoft não lista atualmente problema semelhante para o KB5035849.	Útil para acompanhar futuras atualizações do artigo de suporte.
4. Reportar via Feedback Hub	Enviar logs e reprodutor a fim de acelerar uma correção oficial.	Importante quando há interação entre patch e software de terceiros.

Árvore de decisão para equipe de produção

Se o fornecedor exige Classic + No Managed Code: priorize exceção no EDR para w3wp.exe e diretórios do site; caso não seja possível, remova o patch e agende implantação de cumulative update posterior em janela segura.
Se há margem para Integrated Pipeline: teste em homolog; se funcionar, documente o desvio com aceite do fornecedor e mantenha o patch e o EDR.
Em todos os cenários: mantenha o agente do EDR atualizado e reporte o incidente a ambos os fabricantes com evidências concretas.

Passo a passo detalhado

Preparação segura

Formalize janela de manutenção com retorno aprovado.
Tenha backup ou snapshot recente da VM.
Se for servidor de farm, planeje método em ondas para reduzir indisponibilidade.

Desinstalação do patch problemático

Use somente quando exceções não são viáveis de imediato e o negócio demanda a configuração original do pool.

Interface gráfica:

Abra Configurações ► Atualização e Segurança ► Windows Update ► Histórico de atualizações.
Selecione Desinstalar atualizações, localize o pacote e confirme.

Linha de comando:

REM Verificar presença
powershell -NoProfile -Command "Get-HotFix -Id KB5035849"

REM Desinstalar de forma silenciosa e sem reiniciar
wusa /uninstall /kb:5035849 /quiet /norestart

REM Agendar reinício fora do horário crítico
shutdown /r /t 600 /c "Reboot pós-desinstalação do KB5035849"

Quando o WUSA não encontra o pacote, remova com DISM após identificar o nome exato:

dism /online /get-packages | findstr /i 5035849
dism /online /remove-package /packagename:PackageforKB5035849~31bf3856ad364e35~amd64~~17763.XXXX.1.0 /quiet /norestart

Instalação de atualização cumulativa posterior

Implante a cumulativa de abril ou qualquer CU mais nova aprovada internamente. O objetivo é absorver correções complementares que ajustem o comportamento do IIS e reduzam side effects com soluções de segurança.

REM Verificar cumulativas instaladas
powershell -NoProfile -Command "Get-HotFix | ? {$_.HotFixID -match 'KB5036896|KB5039'} | Sort InstalledOn -Descending | Select HotFixID,InstalledOn"

REM Aplicar pacote offline (exemplo .msu em pasta local)
wusa C:\Pacotes\windows10.0-kb5036896-x64.msu /quiet /norestart

Finalize com reinício controlado e monitore o pool por pelo menos um ciclo completo de carga.

Exceções no EDR

Quando a política permitir, esta é a abordagem preferida para manter segurança e disponibilidade:

Permitir o binário assinado: C:\Windows\System32\inetsrv\w3wp.exe com editor confiável do sistema.
Escopo por caminho para diretórios do site e temp do IIS (ex.: %SystemDrive%\inetpub\wwwroot e %SystemDrive%\inetpub\temp), limitando a escrita e execução conforme necessário.
Condição por ancestral: processos originados do serviço WAS/W3SVC.
Lista por hash apenas em último caso, com rotina de atualização a cada CU.

Documente a justificativa de exceção, prazo de revisão e indicadores de abuso para auditoria.

Alternância temporária do modo do pool

Se o fornecedor aceitar testes com Integrated Pipeline, faça em ambiente de homolog e, se aprovado, aplique em produção com comunicação de mudança:

No IIS Manager:

Abra Application Pools, selecione o pool da aplicação.
Clique em Basic Settings… e mude .NET CLR version para v4.0.30319.
Altere Managed pipeline mode para Integrated e confirme.

Via linha de comando:

%SystemRoot%\System32\inetsrv\appcmd set apppool "NomeDoPool" /managedRuntimeVersion:v4.0 /managedPipelineMode:Integrated

Para reverter ao estado original:

%SystemRoot%\System32\inetsrv\appcmd set apppool "NomeDoPool" /managedRuntimeVersion:"" /managedPipelineMode:Classic

Após a troca, valide handlers, filtros ISAPI, autenticação e permissões, pois o pipeline integrado unifica eventos e pode alterar a ordem de execução de módulos.

Ajustes mínimos para compatibilidade com integrado

Revise o mapeamento de handlers e remova curingas obsoletos.
Confirme permissões de leitura e execução no diretório do site para a identidade do pool.
Se houver módulos ISAPI legados, avalie substituição por módulos gerenciados.

Atualização e afinamento do EDR

Garanta a versão mais recente do agente e das assinaturas.
Reaplique políticas com exceções afinadas para servidores IIS.
Valide com o time de segurança que o novo padrão do w3wp.exe está classificado como known good.

Perguntas frequentes

Por que só ocorre com Classic e sem CLR gerenciado?
Esse modo ativa cadeias de carregamento de módulos nativos específicas do IIS. Pequenas mudanças no padrão de I/O e carregamento de DLLs após a atualização podem acionar heurísticas do EDR nessa combinação específica.

É seguro excluir completamente o w3wp.exe das políticas?
É preferível escopo mínimo: permita o binário assinado do sistema e o caminho do site, com monitoramento reforçado. Exclusões amplas e permanentes elevam risco.

Instalar uma CU mais nova resolve sempre?
Nem sempre, mas cumulativas posteriores frequentemente ajustam regressões e compatibilidades. É uma etapa de baixo atrito que pode encerrar o falso positivo.

O fornecedor rejeita Integrated. O que fazer?
Priorize exceções no EDR e mantenha o modo Classic. Se não for possível, avalie remoção do patch com retorno programado assim que houver correção.

Complementos úteis

Excluir o w3wp.exe ou o diretório do site nas políticas do Carbon Black – Se a política de segurança permitir exceções, essa é a forma mais rápida de manter o patch sem alterar o modo do application pool.
Atualizar ou reconfigurar o Carbon Black – Verifique se há regras, assinaturas ou versões do agente que já reconheçam o novo comportamento do IIS.
Testar modo integrado com o fornecedor – Alguns aplicativos antigos funcionam com integrado quando há ajustes mínimos (handlers, permissões). Isso remove a dependência do modo Classic.
Monitorar futuras cumulativas – Problemas entre antivírus e patches de IIS costumam ser resolvidos em cumulativas subsequentes ou por hotfixes específicos.
Registrar evento de encerramento no Visor de Eventos – Entregar evidências concretas (ID de evento, hash do processo) ao suporte Microsoft e ao suporte do Carbon Black acelera a triagem.

Checklist de evidências para suporte

Nome do application pool, modo do pipeline e versão do CLR.
Carimbos de tempo e IDs de evento do Visor de Eventos (Application e System), destacando w3wp.exe e mensagens de WAS/W3SVC.
Eventos do Carbon Black que mostram a prevenção/encerramento do processo, com política e regra disparada.
Hash do w3wp.exe coletado com SHA256 e assinatura digital válida.
Lista de atualizações instaladas antes e depois da ocorrência.
Informações de carga: volume de requisições, reciclagem do pool, alterações de configuração correlatas.

Comandos de diagnóstico

Ver eventos do IIS e do processo em janela recente:

# Eventos de falha de aplicação relacionados a w3wp
powershell -NoProfile -Command ^
"Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000; StartTime=(Get-Date).AddDays(-7)} |
 Where-Object {$_.Message -match 'w3wp.exe'} |
 Select-Object TimeCreated, Id, ProviderName, Message | Format-List"

Eventos de WAS/W3SVC sugerindo falhas do pool

powershell -NoProfile -Command ^
"Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WAS'; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Id, Message | Format-List"

Calcular hash do binário:

certutil -hashfile %SystemRoot%\System32\inetsrv\w3wp.exe SHA256

Inspecionar atualizações instaladas:

powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 HotFixID, InstalledOn"

Coletar despejos controlados para análise (usar em ambiente de teste preferencialmente):

REM Habilitar WER local para w3wp (desabilitar depois)
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpCount /t REG_DWORD /d 5 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpFolder /t REGEXPANDSZ /d "C:\Dumps" /f

Boas práticas para continuidade

Homologação replicável: mantenha um servidor de teste com cópia fiel de políticas do EDR e do IIS para validar CUs antes da produção.
Monitoramento: ative métricas de rapid‑fail protection, tempo de vida do w3wp.exe e códigos de resposta HTTP.
Documentação: registre o racional de cada exceção aplicada e a data de revisão.
Rotina de patching: priorize cumulativas recentes, especialmente quando há interações de compatibilidade conhecidas com middleware de segurança.

Conclusão e recomendações práticas

O encerramento do application pool após a atualização decorre, em grande parte dos casos, de prevenção indevida pelo EDR ante um novo padrão legítimo de comportamento do w3wp.exe. O caminho mais objetivo para manter disponibilidade e segurança passa por três frentes: exceções bem recortadas no Carbon Black, instalação de cumulativas posteriores e, quando aceito pelo fornecedor, uso do pipeline integrado.

Resumo executivo – Se a aplicação precisa continuar em No Managed Code + Classic, a mitigação imediata é desinstalar o KB5035849 ou definir uma exclusão no Carbon Black. Em paralelo, aplique o KB5036896 ou futuras CUs, mantenha o antivírus atualizado e reporte o caso aos dois fabricantes para uma correção definitiva.

Anexo de referência rápida

Item	O que registrar	Como coletar
Identidade do pool	Nome, modo de pipeline, versão CLR, identidade do processo	IIS Manager ► Application Pools ► Advanced Settings
Eventos do sistema	IDs, mensagens, horário, correlação com reciclagem	Visor de Eventos ► Application e System
Atuação do EDR	Política, regra, motivo do bloqueio, ação tomada	Console do Carbon Black e logs locais do sensor
Inventário de patches	Atualizações instaladas antes/depois do incidente	`Get-HotFix` e histórico do Windows Update
Validação pós‑mudança	Disponibilidade do site, telemetria, ausência de novos bloqueios	Monitoramento, logs HTTP e contadores de desempenho

Com essas informações e o passo a passo acima, você restaura o serviço com controle de risco, preserva a postura de segurança e cria base de evidências para uma correção definitiva pelos fabricantes.