MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Résoudre les pics CPU de « NT Kernel & System » sous Windows Server 2016 : guide complet et bonnes pratiques

Résoudre les pics CPU de « NT Kernel & System » sous Windows Server 2016 : guide complet et bonnes pratiques

Windows Server

Des pics CPU intermittents émanant de « Système (NT Kernel & System) » peuvent paralyser vos VM, ralentir vos services critiques et compliquer la planification de capacité ; ce guide pratique détaille les méthodes d’analyse et les correctifs éprouvés pour Windows Server 2016.

Sommaire

Pic d’utilisation CPU par « Système (NT Kernel & System) » sur Windows Server 2016

Vue d’ensemble du problème

Le processus PID 4 « Système » représente en réalité l’ensemble du noyau Windows : planificateur, gestion d’interruptions (IRQ), appels différés de procédure (DPC) et pilotes en mode noyau. Lorsque ce compte système monopolise soudain 40 %, 60 % ou 100 % du CPU, la cause est presque toujours externe au noyau lui‑même : pilote instable, matériel défaillant, service tiers envahissant ou microcode manquant.

Causes probables et outils de diagnostic

CatégorieExemplesOutils de vérification
Pilotes obsolètes ou défectueuxCarte réseau, contrôleur RAID, chipsetGestionnaire de périphériques, Windows Update, site OEM
Interruptions matérielles (DPC/IRQ)I/O disque ou réseau très sollicitéesResource Monitor (onglet CPU → Interrupts/DPC), Performance Monitor (compteurs % Interrupt Time, % DPC Time)
Services ou processus tiersAntivirus, sauvegarde, outil de supervisionTask Manager, Process Explorer
Correctifs ou microcodes manquantsPatches Spectre/Meltdown, firmware BIOSWindows Update, utilitaires fabricants
Corruption système ou logiciel malveillantMinage furtif, rootkitMicrosoft Defender Offline, outils EDR
Anomalies noyau/hardwareMémoire, CPU, cartes PCI‑eWinDbg (analyse dump), diagnostics fabricant

Solutions proposées et bonnes pratiques

  1. Mettre à jour
    • Pilotes (chipset, réseau, stockage) et micro‑firmwares ; privilégiez les packages signés WHQL.
    • Correctifs cumulés de Windows Server 2016 ; vérifiez le niveau OS Build via winver.
  2. Surveiller en continu
    • Créez un Data Collector Set (perfmon.msc) consignant notamment les compteurs suivants : Processor Time, DPC Time, Interrupt Time, Process → % Privileged Time pour le PID 4.
    • Lancez une trace ETW avec Windows Performance Recorder (wpr -start generalprofile -start CPU) puis examinez‑la dans Windows Performance Analyzer.
  3. Isoler le composant fautif
    • Dans Task Manager, ajoutez les colonnes Interrupts et DPC CPU % (clic droit‑>Select columns) ; si leurs valeurs montent pendant le pic, suspectez le matériel.
    • Désactivez ou arrêtez temporairement (une seule variable à la fois) les pilotes/services tiers : antivirus, agent de sauvegarde, monitoring… Observez immédiatement l’impact sur l’usage CPU.
  4. Optimiser la configuration
    • Sélectionnez le plan d’alimentation Haute performance pour éliminer le core parking sur serveurs physiques.
    • Activez la fonctionnalité Message‑Signaled Interrupts (MSI/MSI‑X) sur les cartes réseau modernes via le registre : HKLM\SYSTEM\CurrentControlSet\Enum\PCI\…\Device Parameters\Interrupt Management\MessageSignaledInterruptProperties.
    • Vérifiez qu’aucun pilote n’est compilé en mode Checked/Debug (option rarement utile en production).
  5. Analyser les dumps noyau si nécessaire
    • Activez la génération de Kernel memory dump (type MEMORY.DMP).
    • Dans WinDbg, ouvrez le dump puis exécutez :
      !analyze -v !stacks 2 Les piles les plus fréquentes (DPC ou Interrupt) pointent souvent vers le pilote coupable.
  6. Contrôler l’intégrité du système
    • sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth pour réparer l’image.
    • Exécutez une analyse antivirus hors‑ligne ; évitez de tester en production un moteur ATP en mode « agressif » sans permettre l’exclusion des dossiers %windir%\System32.
  7. Tester le matériel
    • Outils fabricant : Dell SupportAssist, HPE Insight Diagnostics, Lenovo XClarity, etc.
    • Test mémoire (Windows Memory Diagnostic ou MemTest86) ; un simple bit‑flip suffit à déclencher des DPC storm.

Journalisation avancée : modèle perfmon prêt à l’emploi

Copiez le bloc XML ci‑dessous dans un fichier CPU_DPC_template.xml, puis importez‑le via Performance Monitor → Data Collector Sets. Il collecte une fois par seconde les compteurs stratégiques :

<DataCollectorSet>
  <Name>CPU_DPC_trace</Name>
  <PerformanceCounterDataCollector>
    <Counter>\Processor(_Total)\% DPC Time</Counter>
    <Counter>\Processor(_Total)\% Interrupt Time</Counter>
    <Counter>\Process(System)\% Privileged Time</Counter>
    <SampleInterval>1</SampleInterval>
  </PerformanceCounterDataCollector>
</DataCollectorSet>

Script PowerShell : capture WPR puis empaquetage auto

# Exécuter en admin :
$guid = [guid]::NewGuid().ToString()
wpr.exe -start generalprofile -start CPU
Start-Sleep -Seconds 90   # laisser tourner le scénario
wpr.exe -stop "C:\Trace\$guid.etl"
Compress-Archive "C:\Trace\$guid.etl" "C:\Trace\$guid.zip"
Write-Host "Archive prête : C:\Trace\$guid.zip"

Le script démarre une trace, patiente 90 s (modifiable), la stoppe puis la compresse ; idéal pour l’envoyer au support.

Cas d’étude : pic causé par un pilote réseau Broadcom

Sur un cluster Hyper‑V 2016, le processus « Système » montait à 70 % lors de sauvegardes Veeam. Les compteurs % DPC Time atteignaient 45 % sur le nœud 1 uniquement. L’analyse ETW a montré que b57nd60a.sys monopolisait la file DPC lorsque les paquets VLAN taggés s’accumulaient. La mise à jour vers le pilote Broadcom 21.6 et l’activation de MSI‑X ont supprimé le phénomène sans toucher le reste du cluster.

Meilleures pratiques de suivi post‑correctif

  • Conservez les journaux perfmon et ETW durant 24‑48 h pour valider la remédiation.
  • Planifiez une fenêtre de maintenance pour appliquer les BIOS/firmwares ; testez chaque firmware sur un nœud isolé avant généralisation.
  • Documentez chaque changement (version pilote, correctifs KB, fichier INF) dans votre gestionnaire d’actifs ou wiki interne pour pouvoir revenir en arrière si nécessaire.

Glossaire rapide

AbréviationDéfinition
DPCDeferred Procedure Call : routine noyau exécutée après une interruption matérielle.
IRQInterrupt Request : signal matériel émis par un périphérique afin d’obtenir l’attention du CPU.
ETWEvent Tracing for Windows : infrastructure de suivi haute performance du noyau.
MSI/MSI‑XMessage‑Signaled Interrupts : améliore la distribution d’interruptions sur processeurs multicœurs.

Checklist de validation avant fermeture d’incident

  • Taux % DPC Time moyen < 5 % sur chaque cœur.
  • PICD : aucun pic supérieur à 10 % d’Interrupt Time sur 24 h.
  • PID 4 « Système » stable < 2 % CPU au repos, < 10 % en charge utilisateur typique.
  • Firmware et pilotes = dernière révision validée par l’OEM.
  • Tests mémoire et diagnostics matériel : zéro erreur signalée.
  • Documentation mise à jour + restitution aux équipes exploitation.

Conclusion

En combinant mises à jour ciblées, journalisation haute résolution et désactivation méthodique des composantes suspectes, la majorité des pics CPU liés à « Système (NT Kernel & System) » sous Windows Server 2016 sont élucidés en moins d’une journée. La clé réside dans l’observation fine (ETW, perfmon) et le suivi rigoureux des changements pour sécuriser la production.

Windows Server
CPU Windows Server 2016 DPC NT Kernel & System IRQ
Sommaire