Windows Server 2019: leak della Paged Pool che satura la RAM, diagnosi, fix e best practice

In alcuni ambienti Windows Server 2019 la Paged Pool cresce fino a esaurire la RAM, spesso con server bloccati o riavvi non pianificati. Qui trovi una guida pratica per diagnosticare il leak, contenerlo in produzione e applicare la correzione definitiva resa disponibile con gli aggiornamenti di gennaio 2025.

Indice

Panoramica del problema

In un parco di circa sessanta macchine virtuali con Windows Server 2019 versione 1809 (build 17763), sia on‑premise sia in Azure, è stato osservato un aumento costante della Paged Pool fino a consumare tutta la memoria fisica. Il risultato tipico è degradazione progressiva delle prestazioni, RDP non disponibile, servizi che non rispondono e, nei casi peggiori, bugcheck con crash del sistema. In più indagini è stato individuato il driver SM00 (componente collegato a Hyper‑V) come primo consumatore di Paged Pool, ma non è l’unico possibile responsabile: driver di terze parti obsoleti e filtri kernel possono generare un comportamento analogo.

Come funziona la Paged Pool

La Paged Pool è una porzione della memoria kernel che può essere paginata su disco. È distinta dalla Non‑Paged Pool (che non può essere paginata) e dal working set dei processi in modalità utente. Quando un driver effettua allocazioni in Paged Pool e non le rilascia correttamente, la memoria impegnata nel kernel cresce in modo cumulativo, riducendo lo spazio per altri componenti e portando il sistema in pressione di commit. In pratica:

aumentano i byte della Paged Pool e il relativo numero di allocazioni;
cresce il commit totale e diminuiscono i margini di memoria disponibile;
i tentativi del Memory Manager di bilanciare il carico diventano inefficaci se il leak continua.

Sintomi e segnali precoci

Task Manager mostra Paged Pool in crescita costante, spesso con Non‑Paged Pool relativamente stabile.
PerfMon evidenzia trend crescenti su Memory\Pool Paged Bytes e, in parallelo, incremento di System\Handle Count o di Process(*)\Handle Count per servizi specifici.
Event Viewer può registrare eventi di esaurimento risorse e avvisi del Resource Exhaustion Detector, tipicamente quando il commit si avvicina al limite.
Instabilità di rete o Hyper‑V in host o VM con ruoli legati alla virtualizzazione, correlata a driver kernel.

Conferma del leak

Per passare dal sospetto alla certezza occorre misurare. Questi strumenti coprono sia l’analisi “a caldo” sia quella post‑mortem:

Windows Performance Recorder e Analyzer

Registra un trace mirato alla memoria e analizzalo in Windows Performance Analyzer per verificare quali stack kernel allocano Paged Pool e con quale driver vengono etichettate le allocazioni.

REM Esempio di acquisizione con WPR su server affetto
wpr -start Memory -filemode
REM Lasciare in esecuzione durante la finestra in cui la Paged Pool cresce
wpr -stop C:\Traces\PagedPoolLeak.etl

In WPA, usa i grafici Memory approfondendo le allocazioni per Pool e i relativi call stack.

RAMMap di Sysinternals

Fornisce una vista istantanea su come è usata la RAM: distinguendo fra paged/non‑paged, working set, cache file, driver e altro. Con Empty → Empty Standby List puoi liberare in sicurezza memoria inattiva per vedere se la Paged Pool rimane il problema dominante (spoiler: in caso di leak, sì).

PoolMon e i tag del kernel

PoolMon.exe (parte del Windows Driver Kit) mostra in tempo reale quali tag di memoria crescono. Cercando il tag principale e correlando il nome al driver è possibile identificare il colpevole.

REM Filtra e ordina per byte allocati in Paged Pool
poolmon.exe -p -b -g
REM Suggerimento: premi P per Paged/NonPaged, B per ordinare per byte, 
REM               T per ordinare per tag e usare i delta nel tempo.

Se il tag riconduce a SM00 o a un driver Hyper‑V, pianifica aggiornamento o disattivazione temporanea del componente per confermare la causalità.

Cause ricorrenti

Driver Hyper‑V o relativi servizi di integrazione obsoleti, con SM00 frequentemente in cima ai consumi in alcuni ambienti.
Driver di terze parti per rete, storage, antivirus, backup o filtraggio che allocano Paged Pool e non la rilasciano correttamente.
Regressioni da aggiornamenti di sistema non ancora mitigati da un KIR o da una successiva cumulative.

Piano di rimedio

La discussione tecnica ha portato a un percorso in cinque tappe che coniuga diagnosi, correzione e contenimento. La sintesi è nella tabella seguente.

Passo	Dettaglio	Note operative
Analisi mirata	Windows Performance Recorder/Analyzer per registrare l’andamento della memoria. RAMMap per separare Paged, Non‑Paged, driver, cache file e altro.	Serve a individuare il processo o il driver responsabile del leak.
Aggiornamenti	Verificare e applicare tutte le patch cumulative e gli aggiornamenti dello stack di manutenzione.	Numerosi amministratori segnalano la cumulative di gennaio duemilaventicinque come risolutiva: la Paged Pool si riduce e si stabilizza intorno a valori fisiologici.
Limiti al consumo di pool	In emergenza, limitare la crescita tramite la chiave di registro `SystemPtesLimit` in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.	Non è una cura, ma può evitare l’esaurimento totale in attesa della patch corretta.
Rollback mirati KIR	Se un aggiornamento noto causa il leak, usare Known Issue Rollback per disabilitare selettivamente le modifiche problematiche.	Utile mentre si attende il fix ufficiale.
Monitoraggio continuo	Aggiungere contatori PerfMon su Paged Pool, Non‑Paged Pool, handle kernel e commit; configurare alert o script di remediation.	Permette di intervenire prima dell’instabilità.

Dettaglio delle azioni

Analisi mirata con strumenti di sistema

Obiettivo: associare la crescita della Paged Pool a un driver o a uno scenario riproducibile.

Avvia un trace con WPR nel momento in cui il trend di Paged Pool inizia a salire. Mantienilo attivo fino a vedere una crescita netta.
Acquisisci uno snapshot RAMMap all’inizio e alla fine della finestra.
Usa PoolMon per osservare i tag che crescono in modo monotono durante la stessa finestra. Prendi nota dei primi tre tag per byte allocati e delle differenze nel tempo.

Nota: il pool tagging è abilitato per impostazione predefinita nelle versioni moderne di Windows; non attivare opzioni legacy con GFlags se non strettamente necessario.

Aggiornamenti di sistema

Obiettivo: applicare la correzione ufficiale e stabilizzare i server. Molti casi reali indicano che la cumulative update di gennaio duemilaventicinque, insieme al relativo SSU, risolve l’escalation della Paged Pool su Windows Server 2019. Dopo l’installazione e il riavvio, la Paged Pool scende e si mantiene stabile su valori tipicamente inferiori a un quinto della RAM, salvo carichi particolari.

Buone pratiche operative:

Allinea sempre lo servicing stack update prima o insieme alla cumulative.
Verifica la build con winver o interrogando HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
Testa la cumulative su un anello di pre‑produzione, ma evita ritardi ingiustificati: un leak kernel è un rischio operativo elevato.

REM Esempi rapidi
powershell -c "(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId, `
               (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').CurrentBuild"

REM Installazione con WSUS o Windows Update for Business secondo policy interne

Limiti al consumo di pool in emergenza

Obiettivo: guadagnare tempo evitando l’esaurimento della RAM mentre pianifichi patch o change strutturali.

La chiave SystemPtesLimit in Memory Management può ridurre la pressione sugli spazi di indirizzamento del sistema e, indirettamente, ostacolare la crescita incontrollata in scenari specifici. Va usata con estrema cautela e solo previa prova in staging, perché può avere effetti collaterali su driver e mapping I/O.

REM Backup del registro prima di ogni modifica
reg export "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" C:\Backup\mm.reg

REM Creazione o modifica del valore (esempio indicativo)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" ^
/v SystemPtesLimit /t REG_DWORD /d 0 /f

REM Valore 0 = gestione dinamica (ripristino impostazione predefinita).
REM Qualsiasi altro valore modifica il limite e deve essere documentato e testato.

Attenzione: non confondere questa tattica con la risoluzione del problema. Non sostituisce l’aggiornamento correttivo. Evita di toccare chiavi obsolete come PagedPoolSize o PoolUsageMaximum su versioni moderne di Windows, perché non più supportate e potenzialmente dannose.

Rollback mirati con KIR

Obiettivo: mitigare una regressione introdotta da un aggiornamento senza disinstallare l’intera cumulative su larga scala. Con Known Issue Rollback, Microsoft può disattivare selettivamente modifiche problematiche. In ambienti enterprise, l’applicazione avviene spesso via Criteri di Gruppo distribuendo il modello amministrativo dedicato.

Passi tipici: importazione del modello KIR nell’editor dei Criteri, creazione di una GPO a livello di dominio o OU, attivazione della voce specifica e aggiornamento delle policy sui server affetti. Documenta sempre l’intervallo di applicazione e pianifica il rientro quando la cumulative risolutiva è disponibile.

Monitoraggio continuo e automazione

Obiettivo: prevenire downtime e attivare contromisure automatiche prima che il server diventi instabile.

Aggiungi contatori Memory\Pool Paged Bytes, Memory\Pool Nonpaged Bytes, System\Handle Count, Memory\Committed Bytes.
Configura soglie e avvisi per escalation tempestiva.
In casi estremi, prepara un riavvio controllato fuori orario di punta.

REM Creazione di un Data Collector Set circolare
logman create counter "PagedPoolWatch" -f bincirc -max 200 -si 00:00:15 ^
  -c "\Memory\Pool Paged Bytes" "\Memory\Pool Nonpaged Bytes" "\System\Handle Count" "\Memory\Committed Bytes" ^
  -o C:\PerfLogs\PagedPoolWatch

logman start "PagedPoolWatch"

# Esempio PowerShell di controllo soglia e remediation leggera
$thresholdBytes = 0.18 * (Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory
$pp = (Get-Counter '\Memory\Pool Paged Bytes').CounterSamples.CookedValue
if ($pp -gt $thresholdBytes) {
  Write-EventLog -LogName Application -Source "PagedPoolGuard" -EventId 9001 `
    -EntryType Warning -Message "Paged Pool oltre soglia: $([math]::Round($pp/1MB)) MB"
  # Facoltativo: programmare riavvio controllato tra centoventi secondi
  # shutdown /r /t 120 /c "Riavvio preventivo per crescita Paged Pool"
}

Procedure operative

Sequenza di triage

Conferma il trend con PerfMon e annota tempi, servizi e operazioni in corso.
Esegui PoolMon e identifica i tag che crescono stabilmente nell’arco di trenta minuti.
Se il tag riconduce a un driver noto, prepara una finestra per l’aggiornamento o la disabilitazione temporanea del componente per validare l’ipotesi.
Acquisisci trace con WPR e analizza in WPA per ottenere i call stack: questa prova è spesso decisiva in eventuali escalation al fornitore.

Applicazione della correzione

Installa la cumulative di gennaio duemilaventicinque, includendo il relativo SSU.
Riavvia i server e verifica la build aggiornata.
Monitora la Paged Pool per almeno settantadue ore sotto carichi ordinari; un andamento piatto o ondulazioni entro margini contenuti confermano l’efficacia.

Gestione di driver specifici

Per SM00 o moduli Hyper‑V: allinea i pacchetti dei driver/servizi di integrazione alla versione coerente con la piattaforma host. Valuta la disattivazione temporanea delle integrazioni non necessarie nelle VM di test per vedere se il trend si spegne.
Per driver di terze parti: aggiorna dal repository del vendor, documenta versioni e date, e se il leak persiste apri un ticket allegando screenshot PoolMon, report WPR/WPA e finestra temporale del problema.

Contenimento e automazione

Quando non è possibile patchare subito (vincoli di change freeze o finestre ridotte), adotta strategie di contenimento:

Script di trim: liberare working set dei processi critici può ridurre la pressione di commit complessiva; non risolve la Paged Pool ma può guadagnare minuti preziosi.
Gestione degli handle: con Process Explorer puoi individuare handle che crescono in modo anomalo. La chiusura forzata di handle nel processo System è rischiosa e non raccomandata in produzione; usa questa opzione solo come estrema ratio su macchine di test o quando il downtime è già inevitabile.
Riavvio pianificato: meglio un riavvio controllato fuori orario di punta che un crash durante il picco.

Ambienti Azure

In Azure conviene centralizzare il monitoraggio con Azure Monitor, raccogliendo i contatori Memory – Pool Paged Bytes, Memory – Pool Nonpaged Bytes, System – Handle Count e creando regole di avviso su soglie relative alla RAM disponibile. Esempio di query Kusto per Log Analytics:

// Trend della Paged Pool per macchina
Perf
| where ObjectName == "Memory" and CounterName == "Pool Paged Bytes"
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| order by Computer asc, TimeGenerated asc

Configura un’azione che apra un incidente nel sistema ITSM e, se previsto, attivi un runbook per uno shutdown ordinato di servizi non critici.

Verifica post intervento

Dopo patch o cambio driver, definisci criteri di accettazione chiari:

la Paged Pool non presenta trend monotoni crescenti nelle finestre di carico tipiche;
il rapporto Paged Pool/RAM resta all’interno dei limiti stabiliti nelle tue SLO (per esempio sotto un quinto della RAM nelle VM general purpose);
nessun evento di esaurimento risorse registrato in System o Application;
nessun incremento anomalo di System\Handle Count correlato a specifici servizi.

Domande frequenti

Il riavvio risolve davvero?
Sì, resetta lo stato della Paged Pool, ma se il driver continua a perdere memoria, il problema si ripresenterà. È solo un palliativo.

Posso affidarmi a chiavi di registro per “fissare” i limiti?
No. Le impostazioni moderne sono dinamiche e la manipolazione di chiavi legacy può introdurre regressioni. Usa i limiti solo per contenimento e sempre con test adeguati.

Il problema è limitato a Hyper‑V?
No, ma in diversi ambienti tag e driver correlati a Hyper‑V sono risultati in cima alle classifiche di consumo. Non escludere altri driver finché non hai prove con trace e PoolMon.

È necessario un KIR?
Solo se una cumulative recente ha introdotto la regressione e non puoi attendere la successiva con la correzione. Quando la cumulative risolutiva è disponibile, rimuovi il KIR.

Checklist di emergenza

imposta soglie e alert su Paged Pool, Non‑Paged Pool, handle e commit;
prepara script di remediation leggera e, se serve, riavvio pianificato;
acquisisci dati con WPR, RAMMap e PoolMon per identificare il driver;
aggiorna a cumulative e SSU correnti; verifica stabilità;
se il trend persiste, isola e aggiorna o disabilita i driver incriminati, aprendo ticket al vendor con evidenze tecniche;
documenta una runbook di emergenza con soglie, escalation, orari e responsabilità.

Raccomandazioni supplementari

PoolMon è ideale per individuare i tag che crescono: se un tag mappa a un driver, aggiornalo o sostituiscilo.
In Azure, integra Azure Monitor con alert automatici su Memory – Pool Paged Bytes per ogni VM.
Per server che non puoi riavviare subito, Process Explorer consente di identificare e, in casi estremi, chiudere handle problematici. Agisci con prudenza e preferisci ambienti di test.
Documenta una procedura di emergenza: soglia Paged Pool → avviso → script di trim → riavvio fuori orario di punta.

Conclusioni

La crescita incontrollata della Paged Pool su Windows Server 2019 è riconducibile nella maggior parte dei casi a driver in leak. Le evidenze raccolte in più ambienti indicano che l’installazione della cumulative di gennaio duemilaventicinque (insieme all’SSU) stabilizza il sistema riportando la Paged Pool su livelli normali. Dove il problema persiste, la strada maestra è eliminare o aggiornare il driver responsabile, con particolare attenzione ai componenti Hyper‑V e ai driver di terze parti. Nel frattempo, monitora in modo proattivo e applica misure di contenimento per proteggere la continuità operativa.

Appendice – Esempi utili per inventario e audit

REM Elenco driver con versione e data
driverquery /v /fo table > C:\Temp\driverquery.txt

REM Inventario aggiornamenti installati
wmic qfe list full /format:table > C:\Temp\hotfix.txt

REM Verifica rapida memoria fisica e commit
powershell -c "Get-Counter '\Memory\Committed Bytes','\Memory\Commit Limit' |
Select-Object -ExpandProperty CounterSamples |
ForEach-Object { '{0} : {1:N0}' -f $.Path, $.CookedValue }"

Appendice – Esempio di pianificazione di riavvio controllato

REM Crea un'attività pianificata che riavvia se la Paged Pool supera una soglia
powershell -c "$act = New-ScheduledTaskAction -Execute 'powershell.exe' `
 -Argument '-NoProfile -WindowStyle Hidden -Command "&amp; { $th = 0.8*(Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory; `
 $pp = (Get-Counter ''\Memory\Pool Paged Bytes'').CounterSamples.CookedValue; `
 if($pp -gt $th){ shutdown /r /t 120 /c ''Riavvio preventivo per Paged Pool'' } }"'; `
 Register-ScheduledTask -TaskName 'PagedPoolSafeReboot' -Action $act -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration ([TimeSpan]::MaxValue)) -RunLevel Highest -Force"

Stato attuale

In molti ambienti, l’installazione della cumulative di gennaio duemilaventicinque più SSU ha risolto l’escalation della Paged Pool, stabilizzando il valore attorno a percentuali fisiologiche.
Dove il problema persiste, indaga e agisci sul driver incriminato, privilegiando aggiornamento o disabilitazione temporanea e apertura di ticket al fornitore.

Consiglio pratico – Inserisci nel tuo runbook di piattaforma una sezione dedicata alla Paged Pool: definizioni, contromisure, strumenti, procedure di test post‑patch e criteri di accettazione. Ti farà risparmiare ore nei prossimi incident.