IIS si arresta dopo KB5035849 su Windows Server 2019: cause, diagnostica e fix (w3wp.exe bloccato da Carbon Black)

Dopo l’aggiornamento cumulativo KB5035849 (12 marzo 2024) su Windows Server 2019 alcuni ambienti IIS registrano arresti improvvisi dei pool configurati “No Managed Code” + “Classic Pipeline”. In molti casi l’EDR Carbon Black blocca w3wp.exe. In questa guida: diagnosi, workaround e piano di remediation.

Indice

Panoramica del problema

In seguito all’installazione del patch cumulativo KB5035849 (build 17763.5576) su Windows Server 2019, è stato osservato che taluni pool di applicazioni IIS impostati su No Managed Code (quindi senza CLR) e Classic Pipeline vanno in arresto pochi secondi dopo l’avvio. L’anomalia si manifesta con ricicli ripetuti del processo w3wp.exe e conseguente disattivazione del pool dovuta alla protezione “rapid‑fail” di IIS o ad un kill diretto da parte dell’EDR.

La diagnosi emersa sul campo indica che il processo w3wp.exe compie, immediatamente dopo il riavvio, una serie di accessi a file/chiavi di sistema che l’agente Carbon Black classifica come sospetti, bloccando l’esecuzione e determinando lo spegnimento del pool. Rollback: rimuovendo KB5035849 il problema scompare. Work‑around temporaneo: impostando il pool su .NET CLR v4.0.30319 e Integrated Pipeline i crash cessano; tuttavia, per vincoli di prodotto, alcuni fornitori richiedono No Managed Code / Classic e non accettano la modifica.

A chi può riguardare

Server applicativi con IIS 10 su Windows Server 2019 (ramo 1809) aggiornati a KB5035849.
Pool IIS configurati come No Managed Code + Classic Pipeline.
Infrastrutture con Carbon Black (CB Cloud/EDR/Endpoint Standard) o soluzioni EDR con policy restrittive su accessi ai binari di sistema.

Sintomi osservabili

Il pool passa da Started a Stopped pochi secondi dopo l’avvio.
Il processo w3wp.exe viene terminato senza dump visibili o con eventi generici di terminazione.
Nel Visualizzatore eventi compaiono segnalazioni nel canale Application e/o in Applications and Services Logs > Microsoft > Windows > WAS relative a crash/disable del pool.
Nei log dell’EDR Carbon Black si riscontrano eventi di block/deny associati a w3wp.exe con motivazioni di sicurezza su accessi file/registro ritenuti anomali.

Conferme di comportamento

Rollback di KB5035849: i crash scompaiono e il pool resta stabile in No Managed Code / Classic.
Passaggio a Integrated v4.0: il pool si stabilizza anche con KB5035849 presente, ma l’impostazione potrebbe non essere supportata dal vendor dell’applicazione.

Matrice decisionale: opzioni emerse e loro impatto

Azione	Vantaggi	Limiti / Rischi
1. Disinstallare KB5035849	Ripristina immediatamente la stabilità.	Rimuove anche le correzioni di sicurezza incluse nel patch.
2. Installare il cumulative successivo KB5036896 (9 aprile 2024)	Possibile fix già integrato; mantiene gli aggiornamenti di sicurezza.	Non garantito che risolva il problema; richiede finestre di manutenzione.
3. Verificare il portale Microsoft Support (nessun bug noto su KB5035849)	Conferma ufficiale dell’assenza di problemi noti; utile per future escalation.	Non fornisce soluzione diretta.
4. Inviare feedback a Microsoft via Feedback Hub	Consente di far emergere un nuovo bug a Microsoft.	Tempo di risposta non immediato.

Ulteriori azioni consigliate e pertinenti

Esclusione/allow in Carbon Black per w3wp.exe o per l’evento specifico, soluzione più mirata quando è l’EDR a generare il kill.
Analisi con Process Monitor e Event Viewer per identificare file/chiavi toccati da w3wp.exe dopo l’update, così da preparare una whitelist selettiva.
Confronto di build in staging (KB5035849 → KB5036896 → patch più recenti) per verificare se i cumulativi successivi attenuano o risolvono.
Allineamento col vendor applicativo per una certificazione in modalità Integrated o per una build compatibile con Classic dopo le modifiche portate dalla patch.
Ticket al supporto Carbon Black con hash, percorso, command line e dettagli del blocco: esistono spesso firme/aggiornamenti che riducono i falsi positivi dopo cambiamenti di comportamento di IIS.

Perché succede: analisi della causa probabile

Il pacchetto KB5035849 modifica componenti del sistema (e dei servizi) con conseguenti cambiamenti nel comportamento di w3wp.exe all’avvio. In ambienti protetti da EDR, piccole variazioni nei pattern di accesso (file di sistema, aree del registro, librerie caricate, handle particolari) possono essere classificate come nuove o sospette. Se la policy EDR prevede il kill del processo all’insorgere di determinate condizioni, IIS perde il worker e la protezione “rapid‑fail” disabilita il pool. Questo spiega perché il problema non si presenti universalmente ma solo in combinazione con determinate policy EDR e determinate configurazioni del pool (in particolare No Managed Code / Classic).

Diagnosi rapida: check‑list iniziale

Conferma versione: verificare la presenza di KB5035849 Get-HotFix -Id KB5035849 -ErrorAction SilentlyContinue
Controllo pool: assicurarsi che l’app pool sia in No Managed Code e Classic Import-Module WebAdministration Get-ItemProperty "IIS:\AppPools\NomePool" | Select Name, managedRuntimeVersion, managedPipelineMode
Event Viewer: ispezionare i canali Application e Microsoft-Windows-WAS/Operational per arresti/disable del pool.
Carbon Black: cercare eventi di block/deny su w3wp.exe in corrispondenza degli arresti.
Test integrato (solo per prova): portare temporaneamente il pool su .NET v4.0 + Integrated e vedere se scompare il crash.

Workaround immediati con pro e contro

Rollback della patch – massima probabilità di ripristino ma perdita delle fix di sicurezza.
Allow mirato in Carbon Black – mantiene la postura di sicurezza senza sacrificare i cumulative, a patto di una regola ben circoscritta.
Passaggio a Integrated – utile come test o ponte, ma vincolato alla certificazione del vendor.
Installazione di KB5036896 o cumulativi successivi – potenziale stabilizzazione, da validare in staging.

Procedure passo‑passo

Rollback di KB5035849

Nota: valutare i rischi di sicurezza con il Security Officer prima di procedere. Eseguire preferibilmente in una finestra di manutenzione.

Confermare la presenza della patch: Get-HotFix -Id KB5035849
Avviare la disinstallazione: wusa /uninstall /kb:5035849 /quiet /norestart oppure, se necessario, via DISM (richiede l’identità del pacchetto): dism /online /get-packages | findstr 5035849 dism /online /remove-package /packagename:<NomePacchettoEsatto> /quiet /norestart
Riavviare il server quando consentito.
Verificare la stabilità del pool in No Managed Code / Classic.

Installazione del cumulativo successivo (KB5036896) o più recenti

Allineare la macchina a KB5036896 (9 aprile 2024) o a cumulativi successivi secondo le policy di patching (WSUS/WU/installer offline).
Riavviare e testare il comportamento del pool in Classic.
Se persistono arresti, applicare comunque la regola di esclusione EDR descritta sotto.

Creazione di un’esclusione mirata in Carbon Black

L’obiettivo è consentire l’attività legittima di w3wp.exe dopo KB5035849 senza allargare eccessivamente la superficie d’attacco.

Identificare l’evento incriminato: in Carbon Black filtrare per host, processo w3wp.exe, esito blocked e timestamp in concomitanza dell’arresto del pool.
Raccogliere dettagli: percorso completo (%SystemRoot%\System32\inetsrv\w3wp.exe), hash, command line, operazione vietata (file/registry/module), policy e regola che hanno scatenato il blocco.
Creare la regola “Allow” più stretta possibile. Esempi (da adattare al proprio prodotto/console):
- Allow per Process Path = ...\inetsrv\w3wp.exe con Operation = accesso al path specifico negato.
- Allow per Process Hash = hash di w3wp.exe firmato Microsoft.
- Allow per Signatore Microsoft su w3wp.exe con condizione contestuale (solo su quell’host o gruppo di server IIS).
Distribuire in modalità “audit first” (se supportato), osservare gli eventi per 24–48 ore in staging, poi promuovere a produzione.

Best practice: limitare la regola a host label specifici (server IIS), mantenere scadenza se possibile (rule con review automatica), e documentare l’eccezione nel registro rischi.

Passaggio temporaneo a .NET v4.0 + Integrated (per test o mitigazione breve)

Se il vendor lo consente per test, usare i comandi seguenti:

REM Verifica stato attuale
appcmd list apppool /name:"NomePool"

REM Imposta Integrated + CLR v4.0
appcmd set apppool /apppool.name:"NomePool" /managedRuntimeVersion:"v4.0" /managedPipelineMode:Integrated

REM Ritorno a Classic + No Managed Code
appcmd set apppool /apppool.name:"NomePool" /managedRuntimeVersion:"" /managedPipelineMode:Classic

Equivalente in PowerShell:

Import-Module WebAdministration
Set-ItemProperty "IIS:\AppPools\NomePool" -Name managedRuntimeVersion -Value "v4.0"
Set-ItemProperty "IIS:\AppPools\NomePool" -Name managedPipelineMode   -Value "Integrated"
Restart-WebAppPool "NomePool"

Analisi tecnica con Process Monitor ed Event Viewer

Process Monitor: come isolare la causa

Avviare Procmon e impostare i filtri:
- Process Name is w3wp.exe → Include.
- Operation is CreateFile / RegOpenKey / Load Image → Include.
- Facoltativo: Path che inizia con C:\Windows\ o \Registry\ → Include.
Avviare il pool e riprodurre il crash.
Osservare le ultime operazioni prima della terminazione: file/chiavi non accessibili, ACCESS DENIED, esiti NAME NOT FOUND su componenti sensibili.
Correlare con l’evento EDR trovato in Carbon Black: il path/chiave bloccato deve comparire tra le ultime operazioni di w3wp.exe.

Event Viewer: dove guardare

Application: errori di ASP.NET/IIS/WAS.
Applications and Services Logs > Microsoft > Windows > WAS: dettagli su avvio/stop del pool, failure e disabilitazioni.
System: eventuali errori di servizio correlati.

Tip: predisporre dump on crash con strumenti come Debug Diagnostic Tool se si sospetta un crash diverso da un kill EDR; nel caso specifico, gli eventi EDR sono l’indizio principale.

Confronto di build: strategia di test

Per ridurre l’incertezza, predisporre un server di staging con snapshot/backup e provare le combinazioni:

Stato A: KB5035849 + No Managed Code / Classic.
Stato B: KB5036896 (o cumulativi successivi) + No Managed Code / Classic.
Stato C: KB5035849 + .NET v4.0 Integrated.
Stato D: Stato B + regola EDR di allow.

Per ogni stato, registrare: stabilità del pool, presenza di eventi EDR, latenza all’avvio, eventuali differenze di log. Promuovere in produzione la prima combinazione che garantisce stabilità + sicurezza + allineamento al requisito del vendor.

Runbook operativo: dalla segnalazione al fix

Stabilizzare: se produzione è ferma, valutare rollback di KB5035849 oppure applicare subito un’eccezione mirata in Carbon Black (host/gruppo specifico).
Diagnosticare: raccogliere evidenze (Event Viewer, Procmon, log EDR), confermare che l’azione di block/kill provenga da w3wp.exe.
Mitigare: applicare la regola allow più restrittiva possibile o testare Integrated (se approvato) per ripristinare il servizio.
Rimediare: aggiornare all’ultimo cumulativo disponibile (es. KB5036896 e successivi), mantenendo l’eccezione EDR solo se ancora necessaria.
Formalizzare: aprire ticket a Microsoft e Carbon Black, condividere hash/stack/log per accelerare eventuali fix di firma/policy.

Esempi di comandi utili

Verifica e gestione pool IIS

Import-Module WebAdministration

Stato e proprietà pool

Get-ItemProperty "IIS:\AppPools\NomePool" | fl Name, managedRuntimeVersion, managedPipelineMode, startMode

Avvio/stop/recycle

Start-WebAppPool "NomePool"
Stop-WebAppPool  "NomePool"
Restart-WebAppPool "NomePool"

Verifica aggiornamenti installati

# Verifica patch specifica
Get-HotFix -Id KB5035849 -ErrorAction SilentlyContinue

Elenco rapido cumulative recenti

wmic qfe get HotFixID,InstalledOn | find "5035"
wmic qfe get HotFixID,InstalledOn | find "5036"

Raccolta di base per il ticket EDR

$hostInfo = [PSCustomObject]@{
  Hostname   = $env:COMPUTERNAME
  OS         = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").ReleaseId
  Build      = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuild
  IISVersion = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp").VersionString
  AppPool    = "NomePool"
}
$hostInfo | Format-List

Hardening e sicurezza: come ridurre il rischio delle eccezioni

Scope minimale: limitare le allow rule a process path e operation necessari, evitare wildcard generiche.
Controlli compensativi: mantenere abilitati gli altri moduli di protezione EDR/AV, audit e alerting avanzato.
Revisione periodica: impostare una scadenza o un review date per le eccezioni, con retest ad ogni nuovo cumulativo.
Segregazione: applicare eccezioni solo ai server IIS interessati (tag/label), non all’intero dominio.

Interazione con il fornitore dell’applicazione

Quando la modalità Integrated non è accettata, condividere con il vendor:

Versione OS e build (17763.5576 o successiva), elenco patch recenti (inclusi KB5035849/KB5036896).
Configurazione precisa del pool (No Managed Code / Classic), pipeline, identità, rapid‑fail protection.
Log Event Viewer, traccia Procmon (filtrata) e evento EDR con hash/percorso/operazione bloccata.
Risultati dei test in staging con cumulativi più recenti.

Richiedere formalmente: (1) eventuale certificazione per Integrated, (2) indicazioni di compatibilità dopo le modifiche di marzo/aprile 2024, (3) eventuali patch dell’applicazione.

Domande frequenti (FAQ)

Il problema è un bug noto di Microsoft?
Non risultano note ufficiali su KB5035849 che descrivano il comportamento; pertanto è plausibile una interazione con policy EDR specifiche e la particolare configurazione No Managed Code / Classic.

Posso lasciare il pool in Integrated come soluzione definitiva?
Solo se il vendor lo certifica. In caso contrario, resta una mitigazione temporanea per mantenere online il servizio.

Basta aggiornare a KB5036896?
In alcuni ambienti il cumulativo successivo ha normalizzato il comportamento; in altri è stata comunque necessaria una regola di esclusione in Carbon Black. Testare in staging è essenziale.

La rimozione della patch è sicura?
È la via più rapida per ripristinare la produzione, ma riduce la postura di sicurezza. Prevedere compensazioni e un piano per tornare up‑to‑date al più presto.

Checklist di messa in produzione

Backup/snapshot del server IIS.
Verifica configurazione del pool e dipendenze dell’applicazione.
Piano di rollback documentato (WUSA/DISM).
Regola EDR predisposta con ambito minimo; approvazione del Security Officer.
Finestre e piani di test con utenti chiave.
Monitoraggio post‑change (Event Viewer, log IIS, EDR, APM se presente) per almeno 24–48 ore.

Modello di comunicazione interna

OGGETTO: Arresti pool IIS dopo KB5035849 – mitigazione e piano
CONTENUTO:
– Impatto: applicazione X non raggiungibile per arresto pool.
– Root cause probabile: block EDR su w3wp.exe dopo KB5035849.
– Mitigazione: eccezione mirata in Carbon Black e/o rollback della patch.
– Prossimi passi: test con KB5036896+, validazione con vendor, chiusura eccezione EDR appena possibile.

Conclusioni e sintesi pratica

Produzione critica: scegliere tra disinstallare KB5035849 o applicare un’eccezione in Carbon Black per ripristinare subito il servizio.
Soluzione sostenibile: aggiornare a KB5036896 (e successivi) e mantenere una regola EDR strettamente mirata finché non confermata l’assenza di falsi positivi; conservare la configurazione No Managed Code / Classic se richiesta dal vendor.
Governance: alimentare i canali di Feedback (Microsoft, Carbon Black) con evidenze dettagliate per accelerare fix ufficiali e revisioni firma/policy.

Seguendo il percorso proposto — stabilizzazione, diagnosi, mitigazione, remediation e allineamento con il vendor — è possibile tornare ad un equilibrio tra continuità del servizio e sicurezza senza rinunciare alla configurazione operativa richiesta dall’applicazione.

Allegato: mini‑playbook tecnico

Conferma update: Get-HotFix -Id KB5035849
Raccolta evidenze (Event Viewer, Procmon, EDR).
Mitigazione 1: allow EDR su w3wp.exe (host limitato).
Mitigazione 2: rollback KB5035849 (se necessario).
Remediation: installare KB5036896 o cumulativi più recenti; rieseguire test.
Conferma con vendor; revisione e possibile rimozione dell’eccezione EDR.

Glossario rapido
IIS: web server Microsoft.
w3wp.exe: worker process di IIS per i pool di applicazioni.
Classic/Integrated: modalità della pipeline di elaborazione richieste; Integrated unifica pipeline IIS/ASP.NET, Classic mantiene lo schema ereditato.
No Managed Code: il pool non carica CLR .NET, tipico per applicazioni nativamente unmanaged.
EDR: Endpoint Detection & Response, soluzione di sicurezza che monitora e, se necessario, blocca comportamenti ritenuti malevoli.
Carbon Black: piattaforma EDR ampiamente utilizzata in ambienti enterprise.