Невыгружаемый пул на Windows Server 2022 растёт до недоступности сервера каждые несколько дней с тегом Icp: утечка пришла с обновлением сигнатур защиты, а не с патчем

Виртуальные машины и серверы
1

Что было. Несколько серверов на Windows Server 2022 (сборка 20348.2700) с середины сентября 2024 года стали требовать перезагрузки два-три раза в неделю: невыгружаемый пул растёт с сотен мегабайт до гигабайт, через 3–5 дней сервер перестаёт отвечать. Серверы на 2019 не затронуты. Poolmon показал тег Icp.

Что оказалось. Утечку вызывал сетевой компонент встроенной защиты (SenseNDR) после обновления его сигнатур 18 сентября, без установки каких-либо обновлений Windows в этот день. Поддержка производителя подтвердила известную проблему и исправление в октябрьском обновлении безопасности. До него администраторы использовали обход: отключить драйвер мониторинга использования сети (sc config NDU start= disabled и перезагрузка) либо обновить сетевые драйверы.

Почему это важно как метод. Обычный рефлекс «что-то сломалось, значит, виноват последний патч» здесь не работал: патчей не было. Изменения приходят и другими каналами: сигнатуры и движки защиты, агенты мониторинга, драйверы через Windows Update, автообновляемые компоненты приложений. При поиске причины сравнивать даты всех обновлений: Get-MpComputerStatus | Select AntivirusSignatureLastUpdated, AMEngineVersion, журнал Setup, журналы агентов.

Диагностика утечек пула (общая для любого тега):

  1. Диспетчер задач → Производительность → Память: «Невыгружаемый пул». Норма для сервера сотни мегабайт; гигабайты и рост во времени признак утечки.
  2. poolmon -b из Windows Driver Kit (можно скопировать один poolmon.exe): верхний тег по байтам и его Diff. Если Frees не растёт вместе с Allocs, память не освобождается.
  3. Сопоставить тег с драйвером: findstr /m /l <тег> C:\Windows\System32\drivers\*.sys и файл pooltag.txt; теги встроенных компонентов ищутся в открытых списках.
  4. Найти дату начала: счётчик Memory\Pool Nonpaged Bytes в мониторе производительности за прошлые дни, если сбор был; иначе журнал перезагрузок.
  5. Известная проблема: страница состояния выпуска для вашей сборки и обсуждения по тегу. Обход и ожидание исправления обычно лучше, чем ковыряние в драйвере.

Обходы, которые всегда безопасны, пока ждёте исправления: плановая перезагрузка по порогу пула (задача планировщика с проверкой счётчика), временное отключение виновного компонента, если он не критичен, и отказ от «оптимизаторов памяти», которые лишь маскируют симптом.

Про сравнение с тегом SmFi (отдельный разбор): та же методика, другой драйвер (SMB-клиент), другой обход (отключение сжатия SMB). Тег определяет лечение, поэтому без poolmon делать выводы рано.

Инструмент описан в документации Microsoft.