Рост потребления оперативной памяти системными процессами Windows

Процесс System связан с работой ядра и драйверов, но рост его показателей сам по себе ещё не доказывает утечку: часть памяти занимает файловый кэш, а некоторые категории Windows использует и освобождает по мере необходимости.

Чтобы разобраться, сначала нужно отделить память пользовательских процессов от памяти ядра, затем посмотреть, какая категория меняется со временем. И только после этого искать возможный источник. У каждого инструмента здесь своя роль: Монитор ресурсов помогает оценить общую картину, RAMMap показывает распределение физической памяти, PerfMon записывает динамику, а Process Explorer даёт дополнительную информацию о системных потоках.

Анатомия процесса System: почему ntoskrnl.exe связан с расходом памяти

ntoskrnl.exe — ядро Windows NT. С ним связаны управление памятью, планирование процессов и выполнение кода в режиме ядра. Процесс System, обычно с PID 4, — не обычное приложение, а точка, в которой Диспетчер задач показывает часть работы ядра и системных потоков.

Поэтому высокое значение памяти у System — повод для диагностики, но не указание на конкретный драйвер. Диспетчер задач не раскладывает это значение по компонентам ядра. Кроме того, размер рабочего набора процесса System и объём занятой физической памяти — связанные, но не взаимозаменяемые показатели. По одному числу нельзя заключить, что ядро удерживает утекшую память.

Одна из категорий, которую стоит отслеживать, — Nonpaged Pool, или невыгружаемый пул. В нём хранится память ядра, которая должна оставаться в оперативной памяти и не может быть перемещена в файл подкачки. Другой важный показатель — Paged Pool, выгружаемый пул: его страницы при определённых условиях могут быть выгружены.

Рост этих пулов может быть связан с драйвером или системным компонентом, но не всякий рост означает утечку. Память может увеличиться из-за нагрузки, устройств и выполняющихся задач. Диагностический признак — не просто большой показатель, а его устойчивое изменение во времени без понятной связи с нагрузкой и без последующего снижения.

Процесс System показывает, что память занята работой ядра, но не называет виновника. Сначала нужно определить, какая категория растёт, и лишь потом искать компонент.

Условно источники повышенного расхода памяти можно разделить на две группы:

• Пользовательские процессы. Их собственные показатели — например, Private Bytes — помогают заметить приложение, которое со временем накапливает память. Если после завершения процесса его приватная память освобождается, это важная подсказка, но не окончательное доказательство причины.
• Ядро и драйверы. Здесь смотрят на пулы памяти, системные счётчики и теги аллокации. Диспетчер задач и Монитор ресурсов дают лишь часть картины; для углублённого анализа нужны дополнительные инструменты.

Источником проблемы может оказаться драйвер стороннего устройства, фильтр файловой системы, сетевой компонент или программное обеспечение, тесно интегрированное с системой. Но заранее исключать код самой Windows нельзя: по одному увеличению пула установить происхождение проблемы невозможно.

Экспресс-диагностика через Монитор ресурсов и Диспетчер задач

Начните с Диспетчера задач: нажмите Ctrl+Shift+Esc, откройте вкладку «Процессы» и отсортируйте список по памяти. Это помогает увидеть, не забирает ли заметную долю ОЗУ обычное приложение — браузер, редактор, виртуальная машина или другой пользовательский процесс.

Для наблюдения за динамикой полезно сравнивать показатели в одинаковых условиях. Если приложение закрыли, но общий расход памяти не изменился, это не обязательно указывает на неисправность: освобождённая память может остаться в кэше или перейти в другую категорию. Важно записать исходные значения и проверить, что происходит после повторения того же действия.

Монитор ресурсов можно запустить через окно «Выполнить»: нажмите Win+R и введите perfmon /res. На вкладке «Память» отображаются процессы и распределение физической памяти. В нижней части окна показаны категории, среди которых:

• Аппаратно зарезервировано — память, недоступная Windows, поскольку она зарезервирована аппаратными устройствами.
• Используется — физическая память, занятая процессами, ядром и драйверами.
• Изменено — страницы, которые перед освобождением нужно записать на диск.
• Ожидание — кэшированные страницы, которые могут быть востребованы другими задачами.
• Свободно — память, которая сейчас не используется.

Названия и отображение отдельных значений могут немного отличаться в зависимости от версии Windows. Монитор ресурсов не показывает скорость записи в pagefile.sys под названием «Изменение (подкачка)»: категория «Изменено» описывает состояние страниц, а не скорость записи. Для наблюдения за использованием файла подкачки применяют соответствующие счётчики PerfMon.

Если свободной памяти мало, но при этом заметна большая категория «Ожидание», это не равно утечке: кэш может быть использован повторно. Если же со временем растут «Используется» или показатели пулов, а ожидаемая память не объясняет изменение, есть основание перейти к более детальному анализу.

В Мониторе ресурсов удобно сопоставить общую картину со списком процессов, но он не раскрывает теги выделения памяти в ядре. Поэтому не стоит пытаться определить по нему конкретный драйвер. Следующий шаг — проверить, в каких категориях физической памяти находится расход.

Глубокий анализ утечек: RAMMap и классификация пулов памяти

RAMMap — утилита Microsoft Sysinternals для анализа использования физической памяти. Она не требует установки; для полного доступа её запускают с правами администратора. В ней есть несколько представлений, каждое отвечает на свой вопрос. Для общей классификации полезна вкладка Use Counts: она показывает, как память распределена между типами использования, в том числе между пулами ядра.

Среди категорий, которые можно увидеть в RAMMap:

Не следует считать конкретный размер Nonpaged Pool универсальной границей между нормой и неисправностью. Значение зависит от конфигурации, драйверов и текущей работы системы. Полезнее открыть RAMMap в несколько моментов времени при сопоставимой нагрузке и посмотреть, какой показатель последовательно меняется. Также стоит проверить, уменьшается ли он после завершения нагрузки или отключения устройства.

RAMMap помогает увидеть общий объём и тип занятой памяти, но не содержит вкладки Pools для анализа тегов аллокации. Чтобы исследовать теги пула, обычно используют Poolmon из набора средств Windows Driver Kit. Poolmon группирует выделения по тегам — идентификаторам, которые применяются при работе с памятью. Тег может сузить поиск, но сам по себе не всегда однозначно указывает на конкретный драйвер: для расшифровки нужны сведения о системе и загруженных компонентах.

В Poolmon полезно сравнивать не только общий объём выделений, но и то, как меняются значения по отдельным тегам во времени. Если один тег последовательно растёт в периоды, когда увеличивается пул, его стоит проверить дальше. Таблицы соответствия тегов из сторонних или системных справочников могут подсказать направление поиска, однако не являются гарантированной картой «тег — конкретный виновник». Один и тот же тег может требовать проверки по файлам драйверов и дополнительным данным.

Практический порядок такой:

1. В RAMMap зафиксировать текущие значения Paged Pool и Nonpaged Pool.

2. Повторить наблюдение позже, желательно при похожей нагрузке.

3. Если изменение устойчивое, открыть Poolmon и посмотреть, какие теги растут вместе с соответствующим пулом.

4. Сопоставить найденный тег с установленными драйверами и событиями, после которых начался рост.

5. Проверить гипотезу обновлением, откатом или временным отключением конкретного компонента — и снова измерить показатели.

Одна фотография экрана редко даёт ответ. Например, большой пул после длительной активной работы ещё не доказывает утечку, а умеренный показатель не исключает медленного роста. Решающее значение имеет повторяемая динамика.

Настройка мониторинга производительности для выявления медленных утечек

Некоторые изменения возникают не постоянно, а после сна, подключения периферии, смены сети или запуска определённой программы. В таком случае разовый осмотр RAMMap может не поймать момент. PerfMon позволяет записывать счётчики в журнал и сравнивать их с тем, что происходило на компьютере.

Запустите perfmon.msc. В левой панели откройте «Группы сборщиков данных» → «Определяемые пользователем», затем создайте новую группу сборщиков данных и выберите ручное добавление счётчиков производительности. Названия пунктов могут немного различаться между версиями Windows.

Для наблюдения за памятью ядра пригодятся:

• Memory\Pool Nonpaged Bytes — объём невыгружаемого пула;
• Memory\Pool Paged Bytes — объём выгружаемого пула;
• Paging File\% Usage — использование файла подкачки;
• System\System Up Time — время с момента запуска системы.

Чтобы сопоставить системную динамику с отдельными приложениями, можно добавить:

• Process\Private Bytes — приватную виртуальную память процесса;
• Process\Virtual Bytes — виртуальное адресное пространство процесса.

У счётчиков Process нужно выбрать нужный экземпляр: при нескольких похожих процессах ориентируйтесь не только на имя, но и на то, какой экземпляр изменяется. Если задача — наблюдать за системными пулами, счётчики Process не заменяют счётчики Memory.

Интервал записи выбирайте с учётом ситуации. Частые замеры дают больше подробностей, но для медленной утечки могут быть лишними; редкие не покажут короткое событие. Продолжительность тоже лучше задавать под реальный сценарий: если рост проявляется после пробуждения или подключения устройства, журнал должен захватить это действие. Фиксированное расписание не универсально.

После сбора данных важна не только форма графика. Сопоставьте изменение пулов со временем работы системы, использованием файла подкачки, запуском программ и подключением оборудования. Рост счётчика на графике говорит об изменении объёма, но сам по себе ещё не устанавливает причину. Если одновременно растёт конкретный пользовательский процесс, проверяйте его отдельно; если растут пулы ядра — переходите к анализу тегов и драйверов.

Журнал можно сохранить и сравнить с системными событиями. Это помогает отличить постоянный рост от краткого всплеска после нагрузки. Командная строка и logman также подходят для настройки сбора счётчиков, но графический интерфейс PerfMon удобнее, если нужно сначала разобраться в доступных параметрах.

Идентификация проблемных драйверов с помощью Process Explorer

Process Explorer показывает дерево процессов, свойства объектов и системные потоки. Его можно использовать как дополнительный инструмент, когда показатели памяти уже указывают на возможную проблему в ядре. Запуск от имени администратора расширяет доступ к системным данным, но не превращает утилиту в анализатор утечек пулов.

Найдите процесс System и откройте его свойства. Вкладка Threads показывает системные потоки и их начальные адреса. Эти адреса могут относиться к модулю ядра или драйвера, однако имя модуля не доказывает, что именно он удерживает растущую память. А тем более не доказывает утечку количество потоков с похожим адресом: создание потоков и выделение памяти — разные события.

Путь к устройству, например \Device\Harddisk0\DR0, также нельзя приравнивать к адресу модуля драйвера. Это имя объекта устройства, а не прямое указание на компонент, который выделил память. Если в списке отображается сторонний модуль, это полезная зацепка для проверки версии и назначения драйвера, но не готовый диагноз.

У Process Explorer есть и представление дескрипторов. Оно может помочь при поиске проблем с открытыми объектами, но незакрытый дескриптор сам по себе не подтверждает утечку оперативной памяти. Для подтверждения гипотезы нужно сопоставить сведения из Process Explorer с динамикой пулов в PerfMon или RAMMap, а при необходимости — с результатами Poolmon.

Проверять драйвер лучше последовательно: выяснить, к какому устройству или программе он относится, посмотреть установленную версию, затем обновить или откатить его штатным способом. Если подозрение связано с отдельным компонентом, временное отключение может помочь в проверке, но после него нужно повторить измерения в сопоставимых условиях. Изменение показателей после отключения — основание продолжить проверку, а не автоматическое доказательство вины.

Эмуляторы, виртуализация и контекст нагрузки

Мобильные эмуляторы Android, WSL2, Hyper-V и Docker Desktop добавляют к системе виртуализированные среды и связанные с ними компоненты. При их работе меняется распределение ресурсов, поэтому диагностику стоит проводить с учётом того, какие виртуальные машины и эмуляторы запущены. Это не означает, что любой такой продукт вызывает утечку или обязательно нагружает Nonpaged Pool.

Если рост совпадает с запуском эмулятора, полезно сравнить показатели до и после его остановки, а затем повторить сценарий. Учитывайте, что закрытие окна не всегда сразу завершает все фоновые процессы и виртуальные машины. Также важно различать память, занятую самим эмулятором, и память ядра: первую видно среди пользовательских процессов, вторая проявляется в системных категориях и счётчиках пулов.

При разработке мобильных приложений диагностика хоста не заменяет профилирование внутри эмулируемого устройства. Это два разных уровня: один помогает исследовать Windows и её драйверы, другой — работу приложения в Android. О связи этих этапов с общим процессом разработки рассказывает материал о жизненном цикле мобильного приложения от идеи до работающего решения.

От симптома к проверяемой причине

Рост памяти у процесса System — не диагноз и не основание сразу отключать службы, удалять антивирус или менять настройки реестра. Сначала нужно отделить пользовательские процессы от памяти ядра, затем проверить, какой именно показатель меняется и повторяется ли это при сопоставимой нагрузке.

RAMMap показывает категории физической памяти, PerfMon — их динамику, Poolmon — распределение выделений по тегам, Process Explorer — процессы и системные потоки. Ни один из этих инструментов в одиночку не обязан назвать виновный драйвер. Надёжнее всего работает связка наблюдений: рост конкретного пула, повторяемость изменения, совпадение по времени с определённой нагрузкой и проверка соответствующего компонента.

Если данные не указывают на сторонний драйвер, это не повод исключать проблему Windows или считать причину установленной по умолчанию. Сначала стоит собрать журнал, уточнить конфигурацию и проверить системные обновления. В сложных случаях для дальнейшего анализа могут потребоваться дампы памяти и отладчик ядра. Перезагрузка способна временно изменить картину, но не объясняет, почему память росла; задача диагностики — найти воспроизводимую связь, а не только сбросить симптом.