Rammap driver locked что это

Обновлено: 07.07.2024

Что бы вы там себе не думали, а зомби существуют. И они действительно едят мозги. Не человеческие, правда, а компьютерные. Я говорю сейчас о зомби-процессах и потребляемых ими ресурсах. Это будет душераздирающая история о потерянных и снова найденных 32 ГБ оперативной памяти. Возможно, лишь некоторые из вас столкнутся с точно такой же проблемой, но если вдруг это произойдёт — у вас хотя бы будет шанс понять, что происходит.

Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:

В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.

Первой же моей догадкой стало воспоминание о том, что один из моих коллег как-то жаловался на зомби-процессы, которые иногда остаются в ОС уже не активными, но всё же ещё не до конца удалёнными ядром. Он даже написал специальную утилиту, которая выводит список таких процессов — их имена и количество. Когда он запускал эту утилиту в своих тестах, то получал до нескольких сотен зомби-процессов на обычной Windows-машине. Я нашел его инструмент, запустил на своём компьютере и получил… 506 000 зомби-процессов. Да, 506 тысяч!

Я вспомнил, что одной из возможных причин перехода процесса в состояние «зомби» может быть то, что какой-то другой процесс держит открытым его дескриптор (handle). В моём случае большое количество зомби-процессов играло мне на руку — им было сложнее скрыться. Я просто открыл диспетчер задач и добавил на вкладку Details столбец с количеством открытых дескрипторов для каждого процесса. Затем отсортировал список по убыванию значений в этом столбце. Я сразу нашел героя данной истории — процесс CcmExec.exe (часть Microsoft System Management Server) имел 508 000 открытых дескрипторов. Это было во-первых, очень много, а во-вторых, подозрительно близко к найдненному мною выше числу в 506 000 зомби-процессов.

Я убил процесс CcmExec.exe и получил следующий результат:

Всё получилось ровно так, как я того и ожидал. Как я без иронии писал выше — ядро Windows написано очень хорошо и когда процесс уничтожается, то и все занятые им ресурсы освобождаются. Закрытие CcmExec.exe освободило 508 000 дескрипторов, что дало возможность окончательно закрыть 506 000 зомби-процессов. Количество свободной оперативной памяти мгновенно выросло на 32 ГБ. Тайна раскрыта!

Что такое зомби-процесс?

До этого момента мы ещё не выяснили, что же заставило все эти процессы зависнуть в неопределённости, а не быть удалёнными. Похоже на то, что мы имеем дело с тривиальным багом в приложении (а не в ядре ОС). Общее правило гласит, что когда вы создаёте процесс, то получаете его дескриптор и дескриптор его главного потока. Вы ОБЯЗАНЫ закрыть эти дескрипторы. Если вашей задачей было просто запустить процесс — их можно закрыть сразу же (это не убъёт запущенный процесс, а просто разорвёт связь вашего процесса с ним). Если новый процесс вам для чего-то нужен (например, вы ждёте окончания его работы или вам нужен код, который он вернёт) — то нужно воспользоваться соответствующими функциями (например, WaitForSingleObject(hProcess, INFINITE) для ожидания выхода или GetExitCodeProcess(hProcess, &exitCode) для получения кода возврата) и всё-равно закрыть дескрипторы после того, как вы получили от дочернего процесса всё, чего хотели. Аналогично следует и поступать и с дескрипторами процессов, которые вы для чего-нибудь открываете с помощью функции OpenProcess().

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

Куда же девается память?

Ещё одним инструментом, который я использовал в своём исследовании, была утилита RamMap. Она показывает использование каждой страницы памяти. На вкладке Process Memory мы видим сотни тысяч процессов, каждый из которых занимает 32 КБ оперативной памяти — очевидно, это и есть наши зомби. Но

500 000 раз по 32 КБ будет равно примерно 16 ГБ — куда же делась остальная память? Сравнение состояния памяти до и после закрытия зомби-процессов даёт ответ на этот вопрос:

Мы можем чётко увидеть, что

16 ГБ уходит на Process Private Memory. Также мы видит, что ещё 16 ГБ приходится на Page Table Memory. Очевидно, что каждый зомби-процесс занимает 32 КБ в таблице страниц памяти и еще 32 КБ использует для своей личной памяти. Я не знаю для чего зомби-процессу так много памяти, но, наверное, никто никогда не думал, что число таких процессов может измеряться сотнями тысяч.

Некоторые типы занятой памяти увеличились после закрытия процесса CcmExec.exe, в основном это касается Mapped File и Metafile. Я не знаю точно, почему так получилось. Одной из моих догадок является то, что ОС решила, что свободной памяти теперь достаточно и что-то себе закешировала. Это, в общем, не плохо. Мне не жаль памяти для нужд ОС, я просто не хочу, чтобы она пропадала совсем уж бесцельно.

Важное замечание: RamMap тоже открывает дескрипторы всех процессов, так что эту утилиту следует закрыть, если вы хотите добиться закрытия зомби-процессов.

Я написал твит о моей находке и исследование продолжил другой программист, который сумел воспроизвести данный баг и передать информацию о нём разработчику из Microsoft, который сказал, что это «известная проблема, которая иногда случается, когда очень много процессов запускаются и закрываются очень быстро».

Я надеюсь, что данная проблема будет скоро исправлена.

Почему у меня на компьютере возникают такие странные проблемы?

Я работаю над кодом Windows-версии Хрома и одной из моих задач является оптимизация его сборки на этой ОС, а это требует многократных запусков этой самой сборки. Каждая сборка Хрома запускает огромное множество процессов — от 28 000 до 37 000 в зависимости от выбранных настроек. При использовании нашей распределённой системы сборки (goma) эти процессы создаются и закрываются очень быстро. Мой лучший результат сборки Хрома — 200 секунд. Но столь агрессивная политика запуска процессов выявляет и проблемы в ядре Windows и её компонентах:

Быстрое удаление процессов ведёт к зависаниям пользовательского ввода
Драйвер тачпада выделяет, но не освобождает память при каждом создании процесса
App Verifier создаёт O(n^2) лог-файлов (и об этом стоит написать отдельный пост!)
Есть баг в ядре Windows, который касается буферизации файлов, и этот баг воспроизводится на всех Windows от Server 2008 R2 до Windows 10
Windows Defender задерживает запуск каждого процесса goma на 250 мс

Что дальше?

Если вы работаете не на компьютере, управляемом политиками компании, то процесс CmmExec.exe у вас не запущен и с конкретно данным багом вы не столкнётесь. Также он коснётся вас только если вы собираете Хром или делаете ещё что-то похожее, создавая и закрывая при этом десятки тысяч процессов в короткие промежутки времени.

CcmExec — не единственная в мире программа с багами. Я нашел много других, содержащих в себе конкретно этот же тип ошибок, приводящих к созданию зомби-процессов. И есть ещё огромное множество тех, которые я не нашел.

Как знают все опытные программисты, любая ошибка, которая не была явно исправлена или предупреждена — точно когда-то произойдёт. Просто написать в документации «Пожалуйста, закройте этот дескриптор» — не достаточно. Так что вот мой вклад в то, чтобы сделать нахождение подобного типа ошибок проще, а их исправление — реальнее. FindZombieHandles — это инструмент, основанный на NtApiDotNet и коде от @tiraniddo, который выводит список зомби-процессов и информацию о том, кто сделал их зомби. Вот пример вывода данной утилиты, запущенной на моём компьютере:

274 зомби — это ещё не так плохо. Но уже и это указывает на определённые проблемы, которые могут быть найденны и исправлены. Процесс IntelCpHeciSvc.exe в этом списке имеет самые большие проблемы — похоже на то, что он открывает (и забывает закрыть) дескриптор процесса каждый раз, когда я открываю видео в Windows Explorer.

Visual Studio забывает закрыть дескрипторы как минимум двух процессов, в одном случае это воспроизводится всегда. Просто запустите сборку проекта и подождите

15 минут пока процесс MSBuild.exe закроется. Можно также выставить опцию “set MSBUILDDISABLENODEREUSE=1” и тогда MSBuild.exe закроется сразу по окончанию сборки и потерянный дескриптор будет виден сразу. К сожалению, какой-то негодяй в Microsoft исправил эту проблему и фикс должен выйти в обновлении VS 15.6, так что поторопитесь воспроизвести её, пока это ещё работает (надеюсь, не нужно объяснять, что это была шутка и никакой он на самом деле не негодяй).

Также вы можете использовать для просмотра забытых процессов программу Process Explorer, сконфигурировав её нижнюю панель так, как это показано ниже (заметьте, что в этом случае будут показаны забытые дескрипторы как для процессов, так и для потоков):

Вот пару примеров найденных багов (о некоторых сообщено разработчикам, но не о всех):

Утечка в CcmExec.exe (описанный выше случай с 500 000 зомби) — разработчики работают над исправлением
Утечка в Program Compatibility Assistant Service — проблема исследуется
Утечка в devenv.exe + MSBuild.exe (проблема уже исправлена)
Утечка в devenv.exe + ServiceHub.Host.Node.x86.exe (багрепорт отправлен)
Утечка в IntelCpHeciSvc.exe + Video.UI.exe для каждого открытого видеофайла (Intel приняла багрепорт и переслала его в Lenovo)
Утечка в RuntimeBroker.exe + MicrosoftEdge и Video.UI.exe (возможно, имеет отношение к некоторым другим багам в RuntimeBroker.exe)
Утечка в AudioSrv + Video.UI.exe
Утечка в одном внутреннем инструменте Google из-за использования старой версии psutil
Утечка в утилитах от Lenovo: tphkload.exe теряет один дескриптор, SUService.exe теряет три
Утечка в Synaptic’s SynTPEnh.exe

Используя Process Explorer, я заметил, что NVDisplay.Container.exe открывает

5000 дескрипторов на событие \BaseNamedObjects\NvXDSyncStop-61F8EBFF-D414-46A7-90AE-98DD58E4BC99, создавая новый дескриптор каждые две минуты. Я так понимаю, они хотят быть супер-уверены в том, что могут остановить NvXDSync? Багрепорт Nvidia отправлен.

Corsair Link Service создаёт

15 дескрипторов в секунду, не освобождает их совсем. Багрепорт отправлен.

Adobe’s Creative Cloud теряет тысячи дескрипторов (около 6500 в день, по моим подсчётам). Багрепорт отправлен.

Удивительно, что никто до этого особо не обращал внимание на подобные баги. Эй, Microsoft, возможно, стоит собирать статистику по таким случаям и что-то предпринимать по этому поводу? Эй, Intel и Nvidia, почистите немного ваш код. Помните, я наблюдаю за вами.

А теперь вы можете взять утилиту FindZombieHandles, запустить её на вашей машине и рассказать о своих находках. Также вы можете использовать в экспериментах диспетчер задач и Process Explorer.

В данном конкретном случае утечек памяти нет, но больше всех остальных расходуют память области с тегами NVRM и ViMm .
Они и оказались в самом верху списка после сортировки:

тобы выяснить какому драйверу принадлежит тег создайте батник, который выполнит поиск потенциального виновника по тегу при помощи программы strings.exe среди всех загруженных в данный момент драйверов, и покажет краткую информацию о каждом найденном при помощи sigcheck:

Где вместо . нужно вписать интересующий нас тег.

Например один из тегов, который был получен в предыдущем пункте:

Файлы strings.exe и sigcheck положите в папку с батником или скопируйте в C:\Windows , без них поиск выполняться не будет.

В итоге должен получиться вот такой батник (пример: strings.exe и sigcheck находятся в той же папке):

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

Выяснилось, что тег NVRM относится к драйверу nvlddmkm.sys

ринадлежность тега ViMm тем же способом выяснить не удалось:

Но на помощь приходит файл pooltag.txt.
Файл pooltag.txt содержит описание тегов пулов системных драйверов (поставляемых в составе ОС) и не содержит описания тегов сторонних драйверов.

Произведите поиск тега ViMm в файле pooltag.txt

dxgkrnl.sys - это еще один графический компонент, но на этот раз системный.

екомендации по устранению:

Если сбойный драйвер оказался драйвером стороннего производителя, то нужно произвести обновление этого драйвера или откат к более ранней версии.
Перед установкой нового драйвера настоятельно рекомендуется удалить старый драйвер и перезагрузиться.

Не вдаваясь в подробности, если этого не сделать, то, в некоторых случаях, система продолжает использовать старый драйвер даже после установки нового.
Проверяйте и сравнивайте версию драйвера до и после обновления/отката.
Если драйвер продолжает "течь" и после обновления/отката, то это может указывать на аппаратные проблемы.

Невероятно сильно забивается оперативная память
Не понимаю, как она может так забиваться. Завершил все самые требовательные процессы, но легче не.

Занята оперативная память неизвестно чем.
Совсем недавно поставил Windows 7, через некоторое время заметил что непонятно чем занята.

Забивается виртуальная память
Всем привет! Проблема такая. На трёх машинах стала забиваться виртуальная память без видимой.

UPD: перезагрузился, запустил все те же программы, открыл те же вкладки хрома (понятно, например, что вкладки того же ютуба стали меньше жрать из-за очистки подгруженной части видео, но не на десять же етить гигабайт!) и наблюдаю обычную, адекватную картину (2.1 и 2.2 скрины). Но перезагружаться ради этого каждый день, когда раньше комп работал месяц-два и отключался только чтоб почистить системник? А почему не отображается как память, выделенная его процессам? А почему не отображается как память, выделенная его процессам?

Диспетчер задач не все показывает
Вы суммируйте память выделенную каждым процессом и сравните с занято в целом, тоже возникнет вопрос )

Во время возникновения проблемы запустите resmon и смотрите кто обнаглел

Реанимирую тему с добавлением информации.
Опять возникла такая ситуация. С вечера всё работает нормально, затем простаивает ночь и на утро уже всё забито. Инструкции из этой темы не помогли.
Скрины из ResMon, RamMap и PoolMon соответственно. в rammap откройте вкладку processes и отсортируйте по столбцу private

Боюсь, я уже перезагрузился. Но разве Private не учитывается при подсчёте общей памяти процесса?

Насколько я могу видеть, для каждого процесса значение столбца "Total" вычисляется путём суммирования значений из предыдущих столбцов. И значение столбца "Total" полностью совпадает со значение столбца "Частный набор" в resmon.

Werewolf_RU, NonPag = почти 2 Гб
.отсюда и "ноги" растут.

Если бы у меня где-то потерялись 2гб, скорее всего, я бы это даже не особо заметил. Здесь же, после закрытия всех программ, у меня остались занятыми 8гб памяти. Допустим, все процессы со скрина займут 1гб, где ж оставшиеся 7?

Поправьте, если я неверно рассуждаю, я не особо разбираюсь во всём этом.

Werewolf_RU, для чего выкладываете скрин " Монитора"?
..что я (иже с ними) - должен увидеть?
мне достаточно RАМMap (пост №6) - что бы сделать вывод.

Хорошо. В таком случае, какой это вывод? Изначальный вопрос был, собственно, что является причиной утечки памяти. Информация о том, что "ноги растут" из NonPag мне мало что говорит, ибо всё что я знаю про nonpaged pool - это то, что эта часть памяти используется для важных задач и не может быть выгружена на диск.

Если говорить о RAMMap - хорошо, у меня есть 3 скрина: как только проблема была обнаружена (выше), после того как были закрыты приложения и после перезагрузки (прилагаю). Глядя на них, лично я вижу, что два немалых куска отведены под "Driver Locked" и "Mapped File". Большой же изначально NonPag уменьшился при закрытии приложений.

Werewolf_RU, Выявить виновника "утечки" : Вам ,предстоит самостаятельно.

"Это" у Вас ..установлено то или иное ПО - провацирующее "утечку".
Вот и определяйте : методом исключения.
Наверняка что то из .."изпользующего" сеть итп.

Download RAMMap (488 KB)
Run now from Sysinternals Live.

Have you ever wondered exactly how Windows is assigning physical memory, how much file data is cached in RAM, or how much RAM is used by the kernel and device drivers? RAMMap makes answering those questions easy. RAMMap is an advanced physical memory usage analysis utility for Windows Vista and higher. It presents usage information in different ways on its several different tabs:

Use Counts: usage summary by type and paging list
Processes: process working set sizes
Priority Summary: prioritized standby list sizes
Physical Pages: per-page use for all physical memory
Physical Ranges: physical memory addresses
File Summary: file data in RAM by file
File Details: individual physical pages by file

Use RAMMap to gain understanding of the way Windows manages memory, to analyze application memory usage, or to answer specific questions about how RAM is being allocated. RAMMap’s refresh feature enables you to update the display and it includes support for saving and loading memory snapshots.

For definitions of the labels RAMMap uses as well as to learn about the physical-memory allocation algorithms used by the Windows memory manager, please see Windows Internals, 5^th^ Edition.

Rammap driver locked что это

Что такое зомби-процесс?

Куда же девается память?

Почему у меня на компьютере возникают такие странные проблемы?

Что дальше?

Related Links