Quando il crash non è visibile all'app
Un application pool che si ricicla spesso non segnala un errore nel codice: il problema può essere nel process model di IIS, nelle impostazioni di recycling, nella memoria o nel modulo runtime che ospita l'applicazione.
I livelli da isolare
- Event Viewer — guarda i log del sistema e dell'applicazione per i codici di errore del worker process o del runtime.
- Rapid-Fail Protection — se il pool supera un certo numero di crash in un intervallo, IIS lo arresta automaticamente.
- Configurazione del riciclo — controlla le condizioni di riciclo basate su tempo, richieste o consumo di memoria.
- Identity e accesso — un pool che non ha accesso a risorse esterne può abortire senza errori espliciti nel codice.
Errori tecnici comuni
Le cause ricorrenti includono: moduli nativi che si bloccano, parametri di process model incompatibili, risorse di memoria insufficiente, e cambi di TLS/cipher suite che interrompono la sessione. Anche i log di stdout non abilitati fanno sembrare il problema invisibile.
Come evitare ricicli silenziosi
Abilita il tracing delle richieste fallite, attiva i log stdout per applicazioni .NET, monitora i contatori di worker process e normalizza le impostazioni di recycling. Se il pool si ricicla regolarmente, preferisci una diagnosi basata su eventi e dump prima di cambiare le condizioni di riciclo.