Windows Server 2019: Paged Pool consume toda la memoria — diagnóstico con PoolMon y solución sin reiniciar

Si el “Paged Pool” se come toda la RAM en Windows Server 2019, no es un “rasgo” del sistema sino la señal de que algún controlador o servicio está fugando memoria. Aquí tienes un procedimiento probado para detener la hemorragia sin reiniciar el host cada vez, aislar al culpable y aplicar la corrección definitiva.

Índice

Resumen del problema

Entorno con ~60 máquinas Windows Server 2019 (v1809, build 17763). La memoria del Paged Pool crece continuamente durante días o semanas hasta volver los servidores lentos o inaccesibles, obligando a reinicios. Se busca: (1) cómo mitigar sin reiniciar todo el equipo y (2) si es posible limitar el Paged Pool.

Idea clave y respuesta corta

  • El Paged Pool no “crece porque sí”: casi siempre hay un controlador o servicio que “olvida” liberar memoria (fuga).
  • No hay un tope soportado para el Paged Pool en Windows Server 2019. El sistema calcula y gestiona dinámicamente esos límites.
  • La solución real es encontrar y corregir el componente que fuga (actualización, hotfix, reconfiguración o retirada).
  • Mitigación temporal sin reiniciar: reinicia el servicio o controlador implicado, y amplía el pagefile para ganar margen mientras aplicas el fix.

Acciones inmediatas (sin reiniciar el servidor)

Estas medidas suelen recuperar memoria del Paged Pool de forma segura mientras avanzas con el diagnóstico.

  1. Reinicia el servicio que fuga (si ya lo identificaste): sc stop <NombreServicio> sc start <NombreServicio> En muchos casos el contador Memory\Pool Paged Bytes cae tras reiniciar el servicio.
  2. Reinicia el controlador (NIC, filtro de backup, antivirus, etc.). Puedes usar Administrador de dispositivos o PowerShell: Get-PnpDevice | ? Status -eq 'OK' | ? FriendlyName -like '<patrón>' | ForEach-Object { Disable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false; Start-Sleep -Seconds 2; Enable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false } Nota: requiere privilegios de administrador y puede interrumpir temporalmente el servicio asociado.
  3. Actualiza o desinstala temporalmente el agente/controlador sospechoso (EDR/AV, backup, agentes de virtualización, multipath de almacenamiento, etc.).
  4. Amplía el pagefile para evitar caídas mientras corriges el origen (mitigación, no solución). En la mayoría de casos, tamaño administrado por el sistema funciona mejor. En servidores con picos fuertes, fija un máximo alto para evitar fragmentación.

Importante: Vaciar cachés de archivo (por ejemplo, la Standby list con RAMMap) no reduce el Paged Pool. Tampoco los “memory cleaners”.

Diagnóstico paso a paso (enfoque práctico)

Medir y alertar

Crea alertas tempranas para detectar crecimientos sostenidos.

ContadorDescripciónUmbrales recomendados
Memory\Pool Paged BytesTamaño del Paged Pool en bytes.Alerta si sube día a día sin estabilizarse (tendencia > 5–10% por día durante ≥3 días).
Memory\Pool Nonpaged BytesTamaño del Nonpaged Pool.Útil para diferenciar si la fuga está en paged o nonpaged.
Process(*)\Handle CountNúmero de handles por proceso.Escalada si algún proceso > 100k–200k y creciendo.

Atajos de PowerShell para muestrear:

# Muestreo rápido (bytes)
Get-Counter '\Memory\Pool Paged Bytes','\Memory\Pool Nonpaged Bytes'

Top procesos por handles

Get-Process | Sort-Object Handles -Descending | Select-Object -First 15 Name,Id,Handles,PM,VM

Identificar la etiqueta (“pool tag”) que crece

Usa PoolMon (Windows Driver Kit) para ver qué etiqueta acumula memoria:

poolmon.exe -b -p
  • -b: ordena por bytes.
  • -p: muestra solo Paged Pool.

Campos típicos de PoolMon:

CampoSignificado
TagLa etiqueta de 4 caracteres asociada a las asignaciones.
TypeP (Paged) / N (Nonpaged).
Allocs/FreesNúmero de asignaciones/liberaciones.
DiffAllocs – Frees. Un crecimiento anómalo indica fuga.
BytesMemoria retenida por esa etiqueta.

Mapear etiqueta → controlador/servicio

Una vez que conoces el tag, localiza el binario asociado. Métodos prácticos:

  • Buscar en pooltag.txt (incluido en el WDK) por la etiqueta.
  • Rastrear en disco a qué controlador pertenece: findstr /s /m /i SM00 C:\Windows\System32\drivers\*.sys Sustituye SM00 por tu etiqueta. Si hay coincidencia, ese .sys es un fuerte candidato.

Confirmar actividad anómala con trazas

Una traza corta puede revelar quién está asignando:

wpr -start Memory -filemode
rem Reproduce el crecimiento durante 5–10 min
wpr -stop C:\Temp\mem.etl

Abre mem.etl en WPA para investigar “Heap Allocations”, “Pool Allocations” y correlacionar con módulos. RAMMap (Sysinternals) da una foto útil del uso pero no siempre etiqueta el origen con precisión.

Correlacionar con eventos y cambios

Las fugas suelen aparecer tras un cambio en drivers o agentes:

  • Revisa Visor de eventos → System / Application / Setup por instalaciones/actualizaciones coincidentes con el inicio del problema.
  • Compara con tu CMDB/inventario: nuevos agentes EDR/AV, filtros de backup, drivers de HBA/NIC, agentes de virtualización, utilidades de monitorización, etc.
# Eventos de instalación/actualización recientes
Get-WinEvent -FilterHashtable @{LogName='Setup'; StartTime=(Get-Date).AddDays(-14)} |
 Select-Object TimeCreated,Id,LevelDisplayName,ProviderName,Message

Corregir en origen (la parte que realmente lo arregla)

  • Actualiza o reemplaza el componente asociado a la etiqueta: drivers de red/almacenamiento, filtros de backup (VSS), antivirus/EDR, agentes de monitorización, componentes de virtualización (integrations, paravirtual NIC/Storage), software de DLP, etc.
  • Si el problema empezó tras un parche del sistema o un driver, considera aplicar un KIR (Known Issue Rollback) o deshacer el cambio mientras llega el fix.
  • Mantén Windows Server 2019 al día con el último Cumulative Update (CU) y Servicing Stack Update (SSU). Varios administradores han observado que actualizaciones recientes (enero de 2025 en adelante) estabilizaron el Paged Pool de forma significativa en entornos afectados.

Mitigaciones para “ganar tiempo” (mientras corriges)

No son la solución, pero reducen el riesgo de caída:

MitigaciónCómo aplicarlaNotas
Reinicio controlado del servicio con fugaTarea programada fuera de horario con sc o PowerShell.Evita reiniciar el host completo; valida impacto en dependencias.
Reiniciar el dispositivoDeshabilitar/habilitar el dispositivo (NIC, HBA) bajo ventana controlada.Puede interrumpir temporalmente la red/IO. Úsalo con prudencia.
Aumentar pagefileSistema gestionado o máximo alto predefinido.Mitiga Memory Pressure y retrasos; no corrige la fuga.

Lo que no conviene hacer

  • No “capar” el Paged Pool con el registro. Claves heredadas como PagedPoolSize están desaconsejadas; Windows 2019 dimensiona dinámicamente. SystemPtesLimit se relaciona con PTEs, no limita el Paged Pool, y tocarlo puede desestabilizar.
  • No desactivar el pagefile. Suele empeorar la fragmentación y reduce la resiliencia ante picos.
  • No confiar en “limpiadores de RAM”. Pueden dañar el rendimiento y no liberan el Paged Pool.
  • No vivir a base de reinicios del host. Solo ocultan el problema y aumentan el riesgo operativo.

Checklist operativo recomendado

  1. Parchear 2–3 servidores piloto con el CU/SSU actual y comparativa de 24–72 h.
  2. Vigilar con PerfMon: Pool Paged Bytes, Pool Nonpaged Bytes, tendencia y Handle Count.
  3. Aislar con PoolMon: etiqueta → controlador/servicio. Confirmar con WPR/WPA.
  4. Mitigar sin reinicio: reinicia el servicio/driver; si procede, deshabilita/habilita el dispositivo fuera de horario.
  5. Corregir: actualizar o retirar el componente con fuga; si es bug de parche, aplicar KIR o CU que lo corrige.
  6. Validar: tras la corrección, el Paged Pool debe estabilizarse en carga habitual. Mantén alertas permanentes.

Parches y experiencias recientes

Administradores reportaron un inicio repentino de fugas de Paged Pool a finales de 2024 y principios de 2025 en entornos Windows Server 2019. En al menos un caso, instalar el Cumulative Update y el Servicing Stack Update de enero de 2025 detuvo el crecimiento sostenido del Paged Pool (estabilidad varios días en torno al ~18% de uso). Recomendación: mantener el sistema actualizado y validar siempre en un anillo piloto antes de desplegar masivamente.

Preguntas frecuentes (FAQ)

¿Puedo limitar el Paged Pool para que nunca pase de X GB?

No de forma soportada. Windows gestiona ese umbral dinámicamente y “caparlo” rompe supuestos del kernel. Lo correcto es eliminar la causa de la fuga.

¿Vaciar la Standby list o desactivar cachés ayuda?

No. La Standby list es memoria reutilizable de caché de archivos; limpiarla no devuelve memoria al Paged Pool.

¿Y si el problema es el Nonpaged Pool?

La metodología es análoga: PoolMon con -n para ver nonpaged, mapea la etiqueta y corrige el controlador. Monitorea también Memory\Pool Nonpaged Bytes.

¿Cómo dimensiono el pagefile?

Regla práctica: administrado por el sistema o tamaño máximo fijo suficiente para absorver picos (p. ej., entre 1× y 2× la RAM, según carga y volcados). Evita quedarte corto y evita cambiarlo a menudo.

¿Qué componentes suelen fugar?

Frecuentes: filtros de antivirus/EDR, controladores de backup y VSS, drivers de red/almacenamiento (incluidos paravirtuales/multipath), agentes de monitorización/telemetría y herramientas de DLP o cifrado.

Ejemplo de trabajo de campo (ficticio pero realista)

  1. Alertas: Pool Paged Bytes sube de 6 GB a 22 GB en 5 días.
  2. PoolMon: etiqueta SM00 con tipo P y Diff creciendo; 12 GB retenidos.
  3. Mapeo: findstr apunta a un driver de filtrado de red.
  4. WPR/WPA: picos de asignación al mismo módulo al ritmo de 50–100 MB/min.
  5. Corrección: actualización del driver publicada por el fabricante; tras aplicarla, el Paged Pool se estabiliza < 6 GB con misma carga.
  6. Mitigación temporal: tarea programada que reiniciaba el servicio cada madrugada para evitar caídas durante la semana de pruebas.

Anexo: comandos útiles

PoolMon

poolmon.exe -b -p             rem Top etiquetas (Paged)
poolmon.exe -b -n             rem Top etiquetas (Nonpaged)
poolmon.exe -b -p -i 5        rem Refresco cada 5 s

Mapeo de etiqueta a binario

findstr /s /m /i <TAG> C:\Windows\System32\drivers\*.sys
findstr /s /m /i <TAG> C:\Windows\System32\*.dll

PerfMon rápido con PowerShell

# Muestra Paged/Nonpaged en MB cada 5 s
1..30 | % { 
  $c = Get-Counter '\Memory\Pool Paged Bytes','\Memory\Pool Nonpaged Bytes'
  $p = [math]::Round(($c.CounterSamples | ? {$_.Path -like '*Paged Bytes'} |
                      Select -First 1 -ExpandProperty CookedValue)/1MB,2)
  $n = [math]::Round(($c.CounterSamples | ? {$_.Path -like '*Nonpaged Bytes'} |
                      Select -First 1 -ExpandProperty CookedValue)/1MB,2)
  "{0} | Paged={1} MB | Nonpaged={2} MB" -f (Get-Date), $p, $n
  Start-Sleep 5
}

Crear Data Collector Set (DCS) mínimo

logman create counter PagedPoolDCS -c "\Memory\Pool Paged Bytes" "\Memory\Pool Nonpaged Bytes" ^
-f bin -o "C:\PerfLogs\PagedPool.blg" -si 00:01:00 -v mmddhhmm -rf 24:00
logman start PagedPoolDCS

Reiniciar un servicio con ventana de mantenimiento

$svc = 'NombreServicio'
if ((Get-Service $svc).Status -eq 'Running') {
  Write-Host "Reiniciando $svc..."
  Restart-Service $svc -Force -ErrorAction Stop
}

Anexo: plantillas y umbrales de alerta

SeñalCondiciónAcción sugerida
Tendencia Paged Pool> 5%/día durante ≥ 3 díasEjecutar PoolMon. Abrir ticket de driver/servicio sospechoso.
Diff en PoolMonPositivo y creciente en una misma etiquetaMapear etiqueta → binario. Revisión de versión y cambios recientes.
Handles por proceso> 200k y subiendoPerfilado del proceso. Revisar hooks y filtros cargados.
Pagefile comprometido> 80% sostenidoAumentar tamaño. Plan de corrección prioritario.

Buenas prácticas preventivas

  • Anillos de despliegue: primero piloto, luego anillo limitado, y por último producción completa. Métricas comparativas antes/después.
  • Inventario de drivers y agentes: versión, fecha de instalación, proveedor y hash. Te ahorrará horas al correlacionar problemas.
  • Documenta etiquetas recurrentes: guarda capturas de PoolMon y mapeos; muchas fugas vuelven con variantes.
  • Pagefile estable: evita crecer/disminuir constantemente; en VMs, considera fijar un máximo alto para impedir fragmentación.

Conclusión

Cuando el Paged Pool crece sin freno en Windows Server 2019, el sistema está “gritando” que un controlador o servicio fuga memoria. No hay un límite soportado que puedas imponer; la vía robusta es identificar la etiqueta con PoolMon, mapearla a su binario, y corregir el componente (actualización, rollback o retirada). Para cortar el síntoma sin reiniciar el host, reinicia el servicio o driver implicado y amplía el pagefile como mitigación temporal. Mantén el sistema con los CUs y SSUs más recientes y valida siempre en pilotos: muchos entornos han visto estabilizarse el Paged Pool tras actualizar. Con monitoreo continuo, anillos de cambio y el flujo de trabajo aquí descrito, puedes devolver estabilidad a tus servidores y evitar reinicios de emergencia.

Índice