Su Windows Server 2016 può capitare che il processo “NT KERNEL & SYSTEM” (ntoskrnl.exe) saturi la CPU in modo imprevedibile. In questa guida trovi un percorso pratico, ripetibile e approfondito per diagnosticare l’origine (driver, servizi, firmware) e rientrare entro valori di CPU stabili.
Panoramica del problema
Quando il grafico CPU schizza verso l’alto e il colpevole appare come NT KERNEL & SYSTEM, non significa che “Windows” stia sprecando cicli senza motivo. Quasi sempre il kernel sta gestendo interrupt hardware e DPC (Deferred Procedure Calls) generati da driver o dispositivi in difficoltà (schede di rete, storage, chipset, GPU) o da servizi che interagiscono intensamente con il kernel (antivirus/EDR, agent di backup e monitoraggio). Il risultato è un monopolio dei core da parte del kernel con rallentamenti di I/O, rete e VM.
Distinguere due elementi:
- Processo “System”: rappresenta il kernel e i thread di sistema (PID 4), incluso il lavoro di driver in modalità kernel.
- “System interrupts”: voce pseudo-processo che quantifica il tempo speso in ISR/DPC (spesso visibile in Monitoraggio risorse).
Obiettivo della diagnosi: capire quale driver/stack o servizio genera ISR/DPC anomali, quindi aggiornare, riconfigurare o rimuovere il componente incriminato.
Cause tipiche
| Categoria | Esempi comuni |
|---|---|
| Driver difettosi / obsoleti | NIC, controller RAID/HBA, chipset, GPU |
| Servizi di terze parti | Antivirus/EDR, software di backup, agent di monitoraggio |
| Hardware o firmware | BIOS vecchio, problemi di disco o rete che generano interrupt e DPC elevati |
| Patch mancanti | Aggiornamenti cumulativi e micro‑patch di stabilità non installati |
Ulteriori fattori abilitanti:
- Configurazioni NIC aggressive (Large Send Offload, Receive Side Coalescing, netsh RSS mal configurato).
- Controller storage con code in saturazione o firmware non allineato alla versione del driver.
- Hyper‑V: VM ad alto I/O rete o storage che innescano tempeste di DPC sull’host.
- Telemetria e servizi legacy non necessari su server di produzione.
Verifiche rapide (triage in 10 minuti)
- Task Manager → scheda Processi e Dettagli. Conferma che è “Sistema” a consumare CPU. Apri Monitoraggio risorse e osserva “Interruzioni di sistema”.
- Event Viewer → Registri di Windows > Sistema e Applicazione in corrispondenza del picco. Cerca avvisi/errori ripetitivi di driver o dischi (es. reset dispositivo, warning rete, errori storport).
- Device Manager → controlla simboli di attenzione gialli; verifica versione e data dei driver principali (NIC, storage, chipset).
Se già in questa fase noti un pattern (es. picco CPU a ogni backup notturno o durante scansioni AV), annotalo: guiderà la diagnosi profonda.
Strumenti di diagnosi consigliati
Task Manager e Monitoraggio risorse
Ordina la colonna CPU e, nella vista dettagli, aggiungi colonne legate ai thread se disponibili. In Monitoraggio risorse, controlla le sezioni CPU e Rete per capire se le attività I/O coincidono con i picchi.
Performance Monitor (perfmon)
Crea un Data Collector Set per 24 ore includendo i contatori sotto. Correlare i tempi dei picchi è fondamentale.
| Oggetto\Contatore | Istanza | Indicazione/Nota |
|---|---|---|
| Processor(_Total)\% Processor Time | _Total e per‑core | Conferma saturazione e distribuzione sui core. |
| Processor Information(_Total)\Interrupts/sec | _Total | Picchi costanti suggeriscono interrupt anomali. |
| Processor Information(_Total)\DPCs Queued/sec | _Total | DPC elevati → sospetto driver. |
| System\Processor Queue Length | — | > 2 per core in modo prolungato indica CPU bound. |
| PhysicalDisk(_Total)\Avg. Disk sec/Transfer | _Total o LUN specifiche | I/O lenti possono scatenare DPC. |
| Network Interface(*)\Packets Outbound Errors | NIC | Errori rete correlati ai picchi CPU. |
Soglia pratica: se Interrupts/sec o DPCs Queued/sec restano > 1000 in modo costante durante l’idle o carichi moderati, è molto probabile un problema di driver/hardware.
Event Viewer
Filtra su Warning/Error e concentra l’analisi nelle finestre temporali dei picchi. Eventi ricorrenti utili:
- Storage: “Reset to device” (storport), errori NTFS, time‑out I/O.
- Rete: errori di collegamento, disconnessioni, stack TCP con esaurimento risorse.
- Driver: avvii/arresti anomali o riavvii del dispositivo.
- WHEA: errori hardware corretti/non corretti.
Driver Verifier (verifier.exe)
Serve a stressare i driver sospetti e far emergere comportamenti instabili. Usalo con cautela su server di produzione (preferibile finestra di manutenzione e snapshot/backup preventivo).
- Avvia verifier.exe → Crea impostazioni standard → seleziona driver non Microsoft o specifici sospetti.
- Riavvia. Se compare BSOD, acquisisci il dump per l’analisi.
- Per verificare lo stato:
verifier /querysettings - Per disattivare:
verifier /reset
WinDbg con dump kernel
Imposta la generazione automatica di dump kernel. Procedura tipica:
- System Properties → Advanced → Startup and Recovery → “Kernel memory dump”.
- Forza la creazione al manifestarsi del problema (BSOD o manual crash nella finestra di manutenzione).
- Apri il dump in WinDbg e avvia:
!analyze -v !thread !stacks 2Cerca stack ripetitive che coinvolgano driver di terze parti (es. filtri AV, NIC, HBA).
Windows Performance Recorder/Analyzer (WPR/WPA)
Per un’analisi precisa di ISR/DPC:
- Avvia WPR con profilo CPU Usage + Interrupt/DPC (alta precisione).
- Riproduci il picco per 2–5 minuti e ferma la traccia.
- Apri in WPA e ordina per DPC/ISR Duration → Module/Function per identificare il driver (es.
ndis.sys→ NIC,storport.sys→ storage, modulo del vendor).
Azioni correttive – ordine consigliato
- Aggiorna firmware e driver
- Allinea chipset, storage (RAID/HBA), rete e BIOS/UEFI alle ultime versioni supportate dall’OEM.
- Se l’OEM fornisce un Driver Pack per Server 2016, preferiscilo per coerenza tra stack e firmware.
- Dopo l’aggiornamento verifica le proprietà avanzate della NIC (alcune impostazioni si reimpostano ai default).
- Applica tutte le patch di Windows Update
- Installa gli aggiornamenti cumulativi di qualità e le patch facoltative che risolvono bug di stabilità.
- Se il server è isolato, utilizza cataloghi offline e pianifica un riavvio controllato.
- Verifica software di sicurezza/backup
- In finestra di manutenzione, disattiva temporaneamente real‑time scanning/EDR o il task di backup che coincide con i picchi.
- Se la CPU rientra entro pochi minuti, crea esclusioni mirate (cartelle dati DB, log, cache, VHDX, file di paging) e contatta il vendor per hot‑fix.
- Riduci servizi non essenziali
- Disabilita telemetria non necessaria, spooler di stampa se non usato, servizi legacy.
- Valuta il Server Core o la rimozione delle feature non indispensabili.
- Controllo integrità file di sistema
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealthRieseguisfcse DISM ripara componenti. - Monitoraggio a lungo termine Lascia attivo perfmon per almeno 24 ore. Se Interrupts/DPCs superano i 1000 in idle o restano elevati sotto carico moderato, torna all’analisi dei driver con WPR/WPA o WinDbg.
Ottimizzazioni specifiche per rete e storage
Rete (NIC)
- RSS (Receive Side Scaling): abilitalo per distribuire il carico su più core.
- RSC/LSO: disattiva temporaneamente Receive Side Coalescing o Large Send Offload per escludere coalescing difettoso.
- VMQ su host Hyper‑V: verifica la corretta configurazione in base al numero di code e core.
Get-NetAdapterAdvancedProperty -Name "*"
Get-NetAdapterRss
Esempi di test (reversibili)
Disable-NetAdapterRsc -Name "Ethernet"
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue "Disabled"
Set-NetAdapterRss -Name "Ethernet" -Enabled $trueStorage
- Controlla queue depth e policy cache del controller/HBA secondo linee guida dell’OEM.
- Su dischi con errori intermittenti, isola la LUN problematica e monitora Avg. Disk sec/Transfer.
- Allinea driver storport e firmware del controller; evita mix eterogenei su nodi cluster.
Procedura dettagliata consigliata (percorso pratico)
- Congela lo stato: annota orari e frequenza dei picchi, snapshot/backup, finestra di manutenzione disponibile.
- Perfmon: avvia la raccolta con i contatori proposti e abilita logging CSV ogni 15–30 secondi.
- WPR: registra 3–5 minuti durante un picco per catturare ISR/DPC.
- Event Viewer: crea una Custom View che includa i principali log Warning/Error di Sistema e Applicazione.
- Aggiornamenti: applica driver/firmware/patch; riavvia e verifica.
- Test mirati: disattiva temporaneamente AV/EDR, backup o agent di monitoraggio; ripeti WPR se il comportamento cambia.
- Rete/Storage tuning: applica le ottimizzazioni suggerite; misura l’effetto su DPC/ISR.
- Driver Verifier (se necessario): mira ai driver sospetti; analizza eventuali dump con WinDbg.
- Stabilizzazione: lascia girare perfmon 24–48 ore; raccogli evidenze per chiudere l’incidente.
Checklist “prima di intervenire”
- Confermata correlazione tra picchi e finestre orarie specifiche (backup, scansioni, job schedulati)?
- Driver e firmware sono allineati all’ultima versione raccomandata dall’OEM?
- Il server ha ricevuto gli ultimi cumulativi di stabilità?
- Esistono errori ripetitivi in registro eventi (rete, storage, WHEA)?
- Esclusioni AV adeguate per carichi intensivi (DB, file server, Hyper‑V)?
Pattern ricorrenti e risoluzioni collaudate
Tempesta di DPC su NIC 10 GbE
Sintomi: CPU del kernel sale con traffico rete, DPC/ISR altissimi, Event Viewer con warning periferica di rete.
Fix: aggiornamento driver NIC, disabilitazione temporanea RSC/LSO, configurazione RSS/VMQ coerente con i core; in alcuni casi riduzione del coalescing in advanced properties.Controller RAID/HBA con firmware non allineato
Sintomi: picchi durante job di backup, spike su Avg. Disk sec/Transfer, eventi storport.
Fix: upgrade firmware e driver in coppia, verifica della cache write‑back e delle code; controllo cavi/slot se il problema persiste.EDR/Antivirus aggressivo
Sintomi: picchi a ogni scansione o quando si generano molti file temporanei/log.
Fix: esclusioni su percorsi ad alto I/O, aggiornamento engine/definizioni, policy meno invasive per server con DB o Hyper‑V.Servizi legacy e telemetria superflua
Sintomi: aumenti sporadici senza pattern I/O chiaro.
Fix: rimozione feature non usate, disabilitazione servizi di stampa e telemetria, passaggio a installazione Server Core dove possibile.
Comandi utili e script di riferimento
Raccolta rapida di sistema con PowerShell
# Driver principali
Get-WmiObject Win32_PnPSignedDriver |
Where-Object { $_.DriverProviderName -notlike "Microsoft" } |
Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
Sort-Object DeviceName
Rete: stato RSS/RSC e proprietà avanzate
Get-NetAdapter | Format-Table Name, Status, LinkSpeed
Get-NetAdapterRss
Get-NetAdapterAdvancedProperty -Name "*"
Storage: tempi medi e code
Get-Counter '\PhysicalDisk(Total)\Avg. Disk sec/Transfer','\PhysicalDisk(Total)\Current Disk Queue Length' -SampleInterval 5 -MaxSamples 12
CPU: DPC/ISR in tempo reale
Get-Counter '\Processor Information(Total)\DPCs Queued/sec','\Processor Information(Total)\Interrupts/sec' -SampleInterval 5 -MaxSamples 12Ripristino impostazioni Verifier
verifier /reset
shutdown /r /t 0Impostazione dump kernel (alternativa CLI)
wmic RECOVEROS set DebugInfoType = 2
wmic RECOVEROS set OverwriteExistingDebugFile = 1Come leggere i risultati di WPA/WinDbg
Windows Performance Analyzer
- Apri il grafico CPU Usage (Precise) e il grafico DPC/ISR.
- Ordina per Module e Function: se compaiono moduli del vendor (es. driver NIC/HBA), hai il candidato principale.
WinDbg
!analyze -vper il riassunto;!threade!stacks 2per riconoscere stack ripetitive.- Cerca catene come
ntoskrnl.exe > ndis.sys > drivervendor.sys(rete) ontoskrnl.exe > storport.sys > driverhba.sys(storage).
Buone pratiche operative
- Change management: esegui aggiornamenti e modifiche in finestre di manutenzione, una variabile per volta, con ritorno rapido al punto stabile.
- Compatibilità: su Windows Server 2016 privilegia pacchetti OEM certificati per quella versione.
- Documentazione: conserva esport dei contatori perfmon, elenco driver e versioni, e screenshot di Event Viewer per tracciare le correzioni che hanno funzionato.
- Piano di rollback: per firmware e driver critici prepara sempre il pacchetto di ritorno.
FAQ
Perché vedo “Sistema” e non il nome del driver colpevole?
Il lavoro dei driver in kernel mode viene eseguito all’interno del processo “Sistema”. Servono WPR/WPA o WinDbg per attribuire il tempo CPU al driver preciso.
Posso ignorare i picchi se il carico utente è basso?
No: picchi da ISR/DPC possono mascherare problemi hardware o di rete che peggiorano nel tempo e impattano latenza, backup e replica.
Driver Verifier è sicuro in produzione?
È sicuro solo con adeguate cautele: eseguilo in finestre di manutenzione e solo sui driver sospetti. Può provocare BSOD per evidenziare il bug.
Esito atteso
Una volta aggiornato (o rimosso) il componente responsabile, il processo NT KERNEL & SYSTEM dovrebbe stabilizzarsi al di sotto del 5–10% di CPU in idle o sotto carichi moderati. I picchi casuali scompaiono, DPCs Queued/sec e Interrupts/sec rientrano su valori fisiologici e i job critici (backup, replica, VM) riprendono a funzionare con latenza stabile.
Riepilogo operativo in una pagina
| Passo | Azione | Esito/Decisione |
|---|---|---|
| Triage | Task Manager, Monitoraggio risorse, Event Viewer | Conferma pattern e finestra temporale |
| Misura | Perfmon 24h (CPU, DPC, ISR, I/O) | DPC/ISR > 1000? Passa all’analisi driver |
| Analisi | WPR/WPA o WinDbg | Identifica modulo driver/hardware |
| Correzione | Update driver/firmware, patch; tuning rete/storage | CPU kernel rientra < 10% in idle |
| Conferma | Perfmon 24–48h | Se stabile, chiudi l’incidente con post‑mortem |
Appendice: elenco contatori consigliati
| Oggetto | Contatore | Scopo |
|---|---|---|
| Processor / Processor Information | % Processor Time, Interrupts/sec, DPCs Queued/sec, % Privileged Time | Misurare CPU e lavoro kernel |
| System | Processor Queue Length | Backlog di thread in attesa CPU |
| PhysicalDisk / LogicalDisk | Avg. Disk sec/Transfer, Current Disk Queue Length | Verificare colli di bottiglia I/O |
| Network Interface | Packets Outbound Errors, Packets Received Errors, Output Queue Length | Individuare errori o saturazione rete |
| Memory | Available MBytes, Pages/sec | Escludere pressure di memoria |
Conclusioni
“NT KERNEL & SYSTEM” alto in CPU non è un enigma insolubile: è un segnale affidabile che qualcosa nello stack driver, nel firmware o nei servizi in modalità kernel sta richiedendo tempo di esecuzione eccessivo. Con il percorso qui descritto—misurare, correlare, attribuire e correggere—puoi rientrare rapidamente in un regime stabile e prevenire recidive attraverso aggiornamenti, esclusioni mirate e tuning di rete/storage.