Des VM Windows Server 2019 voient le Paged Pool gonfler jusqu’au crash ? Voici un guide terrain pour diagnostiquer la fuite, corriger sans redémarrer systématiquement, et stabiliser la consommation — avec méthodes, scripts et bonnes pratiques réellement efficaces.
Vue d’ensemble de la question
Dans un parc d’environ 60 VM Windows Server 2019 (version 1809, build 17763), la mémoire paginée (Paged Pool) croît progressivement sur plusieurs jours ou semaines, jusqu’à dégrader les performances, rendre le serveur difficilement joignable puis provoquer des plantages. Deux attentes reviennent :
- Éviter le redémarrage systématique comme seul remède.
- Limiter la consommation du Paged Pool.
Plusieurs administrateurs ont relevé un pic autour de mi‑décembre 2024. Un retour d’expérience crédible rapporte qu’après installation des mises à jour cumulatives et du SSU de janvier 2025, la consommation du Paged Pool s’est stabilisée autour de 18 % sur Server 2019.
Ce qu’il faut retenir
Les hausses anormales du Paged Pool proviennent presque toujours d’une fuite d’un pilote ou d’un service en mode noyau. Dans les investigations, on retrouve des pool tags caractéristiques (ex. SM00) ainsi que des agents d’infrastructure (stockage, réseau, sauvegarde, AV/EDR, pilotes paravirtualisés, outils d’intégration cloud).
Réponse et solutions
Priorité au correctif
- Mettez à jour Windows Server 2019 avec le dernier CU + SSU. D’après des retours, le CU de janvier 2025 a stoppé la croissance du Paged Pool sur plusieurs hôtes.
- Mettez à jour les pilotes et agents tiers : réseau, stockage, pilotes virtuels, AV/EDR, sauvegarde, monitoring.
- Si la fuite apparaît après une mise à jour précise : rétrogradez le composant fautif ou appliquez un Known Issue Rollback (KIR) lorsqu’il est disponible, en attendant le correctif officiel.
Diagnostic sans redémarrage
- RAMMap (Sysinternals) pour visualiser l’utilisation mémoire (onglets Use Counts, File Summary).
- PoolMon (WDK) pour identifier les tags qui gonflent la mémoire paginée :
poolmon.exe -b -p :: trie par octets, Paged Pool uniquement - Mapper le tag au pilote correspondant :
cd %SystemRoot%\System32\drivers findstr /s /m SM00 *.sys - WPR/WPA pour une trace Memory/Pool Allocations mettant en évidence l’allocateur.
Atténuations immédiates
- Redémarrer le service associé lorsqu’il s’exécute en mode utilisateur (ex. spouleur d’impression).
- Mettre à jour ou rétrograder le pilote/agent identifié.
- Désactiver/réactiver le périphérique ou redémarrer le pilote via
devcon(lorsque supporté et sans impact critique). - En dernier recours temporaire : reboot planifié pour casser l’emballement, en attendant la résolution définitive côté pilote ou correctif Windows.
À propos de la limitation du Paged Pool
Sur Windows modernes (dont Server 2019), le Paged Pool est dimensionné dynamiquement. Les anciennes clés de tuning (PagedPoolSize, SystemPtesLimit) sont déconseillées : le plus souvent ignorées ou déstabilisantes. La bonne pratique consiste à corriger la cause (pilote/MAJ) plutôt que de plafonner artificiellement la mémoire noyau.
Procédure conseillée
Mise à niveau
- Appliquez le CU + SSU les plus récents pour Server 2019 (y compris celui de janvier 2025 si ce n’est pas déjà fait).
- Redémarrez une fois pour valider, puis surveillez l’évolution du Paged Pool.
Diagnostic si le problème persiste
- PoolMon : relevez le tag majoritaire (
poolmon -b -p), notez l’évolution des octets. - Associez le tag à un pilote :
findstr /s /m <TAG> *.syspuis vérifiez version et éditeur. - WPR/WPA : capture ciblée Memory pour confirmer l’allocateur (pile d’appels, fréquence, taille des allocations).
Remédiation sans redémarrage global
- Mettre à jour ou rétrograder le pilote/agent identifié.
- Redémarrer le service lié (si user‑mode).
- Pour un pilote noyau critique, la relance à chaud est rarement viable ; le redémarrage peut rester inévitable après planification.
- Si une MAJ Windows est en cause, déployer un KIR ou désinstaller temporairement la MAJ fautive en dernier recours.
Tableau de bord des outils
| Objectif | Outil | Commande rapide | Ce qu’il faut observer |
|---|---|---|---|
| Identifier le tag fautif | PoolMon | poolmon -b -p | Tags triés par octets ; un ou deux tags dominants en Paged Pool |
| Mapper un tag à un pilote | findstr | findstr /s /m TAG *.sys | Nom du pilote probable (.sys) portant la chaîne du tag |
| Vue d’ensemble mémoire | RAMMap | UI | Évolution du Paged Pool, pages en attente, caches |
| Alloueurs et piles noyau | WPR/WPA | wpr -start memory -filemode | Trace Pool Allocations, fonction d’allocation, module |
| Comptage en continu | PerfMon/Get‑Counter | Get-Counter | \Memory\Pool Paged Bytes, \Memory\Pool Nonpaged Bytes |
Comptoir PerfMon et seuils utiles
| Compteur | Pourquoi il est utile | Seuil de vigilance | Action |
|---|---|---|---|
\Memory\Pool Paged Bytes | Volume total du Paged Pool | Trajectoire monotone sur plusieurs jours | Identifier le tag puis corriger le pilote |
\Memory\Pool Nonpaged Bytes | Fuite potentielle côté Nonpaged | Croissance parallèle au Paged Pool | Mêmes méthodes d’enquête |
\Process(*)\Pool Paged Bytes | Contribution des processus | Un service user‑mode gonfle anormalement | Redémarrage du service, mise à jour de l’agent |
\Memory\Available MBytes | Pression mémoire globale | Chute régulière non expliquée par charge | Corréler avec Paged/Nonpaged |
Scripts PowerShell prêts à l’emploi
Suivi programmatique du Paged Pool avec alerte
# Fichier: Watch-PagedPool.ps1
param(
[int]$IntervalSeconds = 60,
[int]$Samples = 0, # 0 = boucle infinie
[int64]$AlertBytes = 8GB, # ajustez selon votre base normale
[string]$LogPath = "C:\Logs\PagedPool.csv"
)
if (-not (Test-Path (Split-Path \$LogPath))) { New-Item -ItemType Directory -Path (Split-Path \$LogPath) -Force | Out-Null }
"Timestamp,PagedPoolBytes,NonPagedPoolBytes,AvailableMB,Machine" | Out-File -FilePath \$LogPath -Encoding UTF8 -Append
function Get-PoolBytes {
\$m = Get-Counter -Counter '\Memory\Pool Paged Bytes','\Memory\Pool Nonpaged Bytes','\Memory\Available MBytes'
\$vals = \$m.CounterSamples
\[pscustomobject]@{
Time = (Get-Date)
Paged = \[int64]\(\$vals | Where-Object {\$*.Path -like '\*Paged Bytes' -and \$*.Path -like '*Pool Paged*'}).CookedValue
NonPaged = \[int64]\(\$vals | Where-Object {\$*.Path -like '\*Nonpaged Bytes'}).CookedValue
AvailMB = \[int]\(\$vals | Where-Object {\$*.Path -like '*Available MBytes*'}).CookedValue
}
}
\$i = 0
while (\$Samples -eq 0 -or \$i -lt \$Samples) {
\$r = Get-PoolBytes
\$line = "{0\:s},{1},{2},{3},{4}" -f \$r.Time, \$r.Paged, \$r.NonPaged, \$r.AvailMB, \$env\:COMPUTERNAME
\$line | Out-File -FilePath \$LogPath -Encoding UTF8 -Append
if (\$r.Paged -ge \$AlertBytes) {
Write-Warning ("Paged Pool dépasse le seuil: {0\:n0} octets" -f \$r.Paged)
\# Option: journalisez dans l’EventLog
Write-EventLog -LogName Application -Source 'Watch-PagedPool' -EntryType Warning -EventId 49001 \`
-Message ("Paged Pool élevé: {0\:n0} bytes" -f \$r.Paged)) -ErrorAction SilentlyContinue
}
Start-Sleep -Seconds \$IntervalSeconds
\$i++
}Playbook PoolMon pour isoler un tag
:: Lancer PoolMon pour le Paged Pool, tri par octets
poolmon.exe -b -p
\:: Quand un tag domine, le rechercher dans les pilotes
cd %SystemRoot%\System32\drivers
findstr /s /m TAG \*.sys
\:: Facultatif: lister la version du pilote identifié
wmic datafile where name="C:\Windows\System32\drivers\MONPILOTE.sys" get Version,ManufacturerCapture WPR centrée mémoire
:: Démarrer une capture mémoire orientée pool
wpr -start memory -filemode
\:: Reproduire sur quelques minutes la dérive
\:: Puis arrêter la capture dans un dossier de traces
wpr -stop C:\Traces\pool\_allocations.etlRelancer proprement un pilote avec devcon
Attention : à effectuer uniquement si la relance à chaud est supportée et sans impact critique.
:: Exemple réseau: identifier l’Instance ID
devcon find * > C:\Temp\devices.txt
\:: Redémarrer le périphérique ciblé
devcon restart "@PCI\VEN\_8086\&DEV\_10FB\&SUBSYS\_00008086\&REV\_01\3&11583659&0&18"Bonnes pratiques de surveillance
- Centralisez les métriques via PerfMon, SCOM, ou votre stack observabilité.
- Définissez un seuil d’alerte data‑driven (ex. 70–80 % du plafond normal observé sur vos serveurs stables).
- Consolidez les événements de changement : MAJ Windows, drivers, mises à jour d’agents. La corrélation temporelle avec la dérive Paged Pool est souvent décisive.
- Évitez les outils de “nettoyage” mémoire : l’Empty Working Sets de RAMMap n’affecte pas le Paged Pool.
Focus sur les tags et leur interprétation
Un pool tag est un identifiant de quatre caractères associé à un ensemble d’allocations noyau. Il n’est pas toujours identique au nom du pilote ; certains tags sont partagés ou générés par des bibliothèques communes. La corrélation fiable se fait via :
- Recherche binaire des chaînes du tag dans
%SystemRoot%\System32\drivers(avecfindstr). - Trace WPR/WPA avec pile d’appels et module d’allocation.
- Historique de changement : si la dérive est apparue juste après une mise à jour d’un pilote ou d’un agent, le suspect est souvent le bon.
Méthodes d’atténuation sans redémarrage
| Action | Quand l’utiliser | Impact | Risques |
|---|---|---|---|
| Mise à jour du pilote/agent | Dès identification du coupable | Durable | Nécessite parfois un redémarrage planifié |
| Rétrogradation de version | Régression post‑MAJ | Arrêt immédiat de la fuite | Perte des correctifs récents |
| Redémarrage du service user‑mode | Service isolé lié au tag | Interruption limitée | Non applicable aux pilotes noyau |
| Relance avec devcon | Périphérique non critique, supporté | Évite un reboot global | Coupure réseau/stockage transitoire |
| Known Issue Rollback | MAJ Windows reconnue problématique | Revenir au comportement antérieur | Nécessite un déploiement GPO, ciblage précis |
À ne pas faire
- Ne forcez pas des clés Registre historiques (
PagedPoolSize,SystemPtesLimit) : inefficaces ou dangereuses sur Server 2019. - N’abusez pas des “memory cleaners” : aucun effet sur le Paged Pool.
- Évitez Driver Verifier en production sans préparation : utile en labo pour confirmer une fuite, mais peut dégrader fortement le système.
Modèle d’enquête reproductible
- Congeler l’état : capture PerfMon, RAMMap, un export
poolmon -b -p. - Identifier le tag dominant et le mapper au pilote.
- Vérifier le change log : pilotes/agents mis à jour, CU/SSU récents.
- Tester en pré‑prod : mise à jour ou rollback du composant suspect.
- Déployer le correctif à large échelle avec suivi rapproché des compteurs.
Cas fréquemment rencontrés
| Contexte | Symptôme | Suspect typique | Remède conseillé |
|---|---|---|---|
| Hyperviseur et pilotes paravirtualisés | Augmentation rapide du Paged Pool sous charge I/O | Pilote réseau/stockage virtuel | Mise à jour des guest tools et pilotes paravirt |
| Environnement imprimerie | Dérive lors de pics d’impression | Spouleur ou pilote d’impression | Mettre à jour ou remplacer le driver, relancer le service |
| Agents de sécurité | Montée corrélée aux scans | Filtre fichier/EDR | MAJ de l’agent, rollback si régression, règle d’exclusion ciblée |
| Pic mi‑décembre 2024 | Forte croissance puis instabilité | Régression logicielle | CU+SSU janvier 2025 rapportés stabiliser autour de 18 % |
Mise en place d’un garde‑fou opérationnel
- Seuil d’alarme par hôte basé sur la baseline observée ; déclencher un runbook de collecte (PoolMon, RAMMap, PerfMon) et un ticket.
- Journal des changements centralisé (pilotes/agents/MAJ) pour une corrélation chronologique immédiate.
- Fenêtres de maintenance courtes mais régulières pour déployer CU/SSU et pilotes vérifiés.
Guide rapide KIR côté entreprise
- Identifier la mise à jour Windows incriminée et la présence d’un KIR disponible.
- Télécharger et intégrer le modèle de stratégie associé au KIR.
- Déployer par GPO sur le groupe d’hôtes affectés, avec retour arrière planifié.
- Surveiller étroitement les compteurs mémoire et la stabilité fonctionnelle.
Questions fréquentes
Peut‑on “vider” le Paged Pool sans reboot ?
Non : seul l’allocateur qui a réservé ces pages peut les rendre. Redémarrer un service user‑mode corrige parfois lorsque le pilote n’est pas impliqué, mais une fuite noyau réclame la correction du pilote ou un redémarrage.
Peut‑on plafonner le Paged Pool par le Registre ?
Sur Server 2019, non recommandé : Windows dimensionne dynamiquement et ignore souvent ces anciens paramètres. Le plafonnement artificiel crée des effets de bord pires que le problème initial.
Driver Verifier aide‑t‑il ?
Oui en validation labo pour reproduire et identifier une fuite, mais déconseillé en production (surcoûts, BSOD possibles). Le réserver à la qualification.
RAMMap permet‑il de libérer le Paged Pool ?
Non. Les fonctions d’Empty n’affectent pas la mémoire noyau.
Plan d’action recommandé
- Appliquer les mises à jour récentes (CU + SSU). Si pertinent, inclure le lot de janvier 2025 signalé comme stabilisant.
- Identifier le tag avec PoolMon, mapper au pilote, corriger par mise à jour ou rollback.
- Éviter les hacks de limitation du Paged Pool ; traiter la cause racine.
- Surveiller en continu, alerter sur dérive, et utiliser KIR si une mise à jour Windows est incriminée.
Exemple de checklist exécution
- Capturer un snapshot PoolMon et RAMMap avant toute action.
- Corréler avec les journaux de mise à jour et d’inventaire logiciel.
- Tester le correctif sur un sous‑ensemble représentatif de VM.
- Déployer à l’échelle via vos outils MDM/CM, puis surveiller 7 à 14 jours.
- Documenter le tag, le pilote incriminé, la version corrigée et l’effet sur les compteurs.
Conclusion
La dérive du Paged Pool sur Windows Server 2019 est presque toujours un problème de pilote ou de service noyau. La voie la plus courte vers la stabilité consiste à mettre à jour (Windows + pilotes), identifier précisément l’allocateur via PoolMon et WPR/WPA, puis corriger (update/rollback). N’essayez pas de limiter le Paged Pool par le Registre : vous déplacez le problème sans le résoudre. Enfin, mettez en place une surveillance proactive et un runbook d’investigation afin de réagir avant le crash applicatif.
Rappel rapide
- Mises à jour récentes (CU + SSU) : un cas réel rapporte que le lot de janvier 2025 a stabilisé le Paged Pool autour de 18 %.
- PoolMon → tag → pilote → mise à jour/rollback.
- Éviter les tweaks Registre hérités.
- Surveillance et KIR si une MAJ Windows est en cause.