Практическое руководство по Process Monitor (ProcMon) — за 10 минут находим «настройки не читаются» и ACCESS DENIED

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

Записать «что произошло на самом деле» умеет бесплатный инструмент Microsoft из набора Sysinternals — Process Monitor (ProcMon). Он в реальном времени фиксирует всю активность файловой системы, реестра, процессов и потоков: по сути, регистратор действий Windows. В наших расследованиях сбоев он появляется не реже WinDbg.¹

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

1. Сначала — вывод

• Вопрос, на который отвечает ProcMon: «этот процесс когда, к какому пути, что сделал и чем закончилось». За несколько минут видно, откуда читается конфигурационный файл, в каком порядке искали DLL и какая операция вернула ACCESS DENIED.
• Рабочий порядок: сначала Include по Process Name на нужный процесс, затем сузить по Result до неуспешных результатов. Это не инструмент, который читают сверху вниз по сырому потоку.
• В столбце Result много значений, которые выглядят как сбой, а на деле нормальны. BUFFER OVERFLOW — штатный обмен вызовами API, NAME NOT FOUND почти всегда — промежуточный шаг порядка поиска (глава 4).
• Фильтр — это только ограничение отображения; в записи остаются все события. Когда лог сохраняют и отдают другому человеку, сохраняют все события. Наоборот, при долгом захвате память берегут через Drop Filtered Events (глава 5).
• ProcMon не закрывает всё. «Какой процесс сейчас держит этот файл» — зона Process Explorer, состояние в момент падения — аварийный дамп, где тратится CPU — PerfView (глава 7).

Сначала — таблица, какой инструмент брать по симптому.

«10 минут» в заголовке — это такая разбивка по времени. Сколько уйдёт по факту, зависит от симптома и среды, но заранее зафиксировать шаги и лимит времени — лучшая защита от того, чтобы полдня смотреть в поток событий.

В первые пять минут смотрите только на три вещи. (1) ACCESS DENIED у целевого процесса, (2) цепочка NAME NOT FOUND по имени конфигурационного файла или DLL, (3) SUCCESS по пути, которого вы не ждали. Если ни одного из трёх нет, причина, скорее всего, вне зоны ProcMon (файлы, реестр, процессы) — не упирайтесь, вернитесь к таблице выше и смените инструмент.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 18, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое ProcMon — установка занимает минуту

Process Monitor — один из инструментов Sysinternals, средство наблюдения, которое в реальном времени показывает активность файловой системы, реестра, процессов и потоков. Это объединённый и усиленный преемник двух прежних инструментов, Filemon и Regmon: подробности по каждому событию, фильтр, который не выбрасывает записанное, запись стека потока, журналирование с момента загрузки.¹

Ставится просто. Отдельного установщика нет: ZIP со страницы загрузки, распаковать, запустить Procmon.exe. Для срочного расследования можно взять сервис Sysinternals Live и запустить напрямую с https://live.sysinternals.com/procmon.exe.² При первом запуске просят принять лицензионное соглашение, а поскольку загружается драйвер ядра, нужны права администратора (повышение через UAC). Когда вообще нужны права администратора, разобрано в статье «Когда в Windows нужны права администратора — UAC, защищённые области и как это отличить на этапе проектирования»: инструмент, который видит события всей ОС, как раз из категории «нужно повышение».

Захват начинается сразу после запуска, события пошли по экрану. Достаточно запомнить три операции.

Строка события состоит из Time (время), Process Name (процесс), PID, Operation (операция), Path (целевой путь), Result (результат), Detail (подробности). Operation по гранулярности в целом соответствует Win32 API: CreateFile (открыть / создать файл), ReadFile / WriteFile, RegOpenKey / RegQueryValue и так далее. Иначе говоря, лог ProcMon — это запись разговора приложения с ОС: «приложение собиралось прочитать конфигурационный файл» и «куда оно реально пошло» видны как есть.

3. Фильтры — ProcMon читают после того, как сузили выборку

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

Диалог фильтра открывается через Filter > Filter… (Ctrl+L). В верхней части диалога в один ряд стоят поля условия, слева направо четыре: столбец (Process Name, Path, Result и т. д.), отношение (is / is not / contains / begins with / ends with и т. д.), значение (вводите сами), Include / Exclude. Условие попадает в список снизу только после нажатия Add. Набрали поля, нажали OK без Add и удивились, что «фильтр не работает» — через эту ошибку проходит каждый. Уже добавленное условие можно временно выключить флажком слева в списке и удалить через Remove. Дальше условия записываю как столбец / отношение / значение / Include или Exclude.

Этап 1: сузить по процессу. В диалоге фильтра добавьте Process Name / is / myapp.exe / Include. Другой способ — перетащить значок-прицел на панели инструментов на окно нужного приложения: фильтр встанет только на этот процесс.

Этап 2: сузить по результату или операции. Ищете неудавшиеся операции — Result / is not / SUCCESS / Include (на экране только неуспешные). Нужна только запись — Category / is / Write / Include. Нужно понять, кто трогает конкретный конфигурационный файл, — не сужайте по процессу, добавьте Path / contains / app.config / Include. И так далее.

На практике ещё чаще сужают интерактивно с правого щелчка по строке. Нашли одну строку рядом с целью — правый щелчок, «Include ‘этот путь’» или «Exclude ‘этот процесс’»: условия копятся без диалога. Базовое движение — Exclude по источникам шума (антивирус, индексатор и т. п.), пока не останутся только окрестности нужной операции. Для глаз есть ещё подсветка (Ctrl+H): теми же выражениями, что и фильтр, она красит строки. Если нужен общий поток, но неуспешные должны бросаться в глаза, берите не фильтр, а подсветку.

Три особенности, без которых легко застрять.

• Фильтр сужает отображение, а не запись. По умолчанию в записи остаются все события; сняли фильтр — снова виден полный поток. Поэтому фильтр и называют неразрушающим: конструкция как раз против сценария «слишком сильно сузили и потеряли доказательство».¹
• Настройки фильтра переживают перезапуск. Фильтр с прошлого расследования остался, «ничего не видно» — через это проходит каждый. Если картинка странная, первым делом смотрите Reset Filter (Ctrl+R) в меню Filter.
• Несколько Exclude уже стоят по умолчанию. Сам ProcMon, paging I/O и ряд другого уже исключены. Если требование — «вся система без дыр», помните про фильтры по умолчанию.

4. Как читать столбец Result — выглядит как сбой, на деле норма

После сужения до неуспешных результатов обычно удивляет объём «похожих на сбой» строк. Важно другое: большая часть «плохих» значений Result — часть нормальной работы. Ниже — как читать основные Result.

И сами логи читают не по одной строке, а цепочкой. На примере «при старте не находится mylib.dll» — как читать строки. Таблица ниже для пояснения оставляет только Operation / Path / Result; на реальном экране слева и справа ещё Time, Process Name, PID, Detail (в Detail у CreateFile попадают параметры вроде Desired Access: и ShareMode:).

Самое частое неверное чтение — по строкам 1–3 решить «нет DLL, вот причина». Смотреть нужно два пункта: есть ли SUCCESS в конце и, если есть, тот ли это путь. Вывод в этом примере: «DLL нашлась. Но это не экземпляр из C:\Program Files\MyApp, который должны были разложить, а старая копия в C:\Tools, оставшаяся на машине разработчика». Если четвёртой строки нет (до конца NAME NOT FOUND, сразу после этого процесс завершился) — тогда действительно не нашли. Запомните: смотрите не «сколько раз NAME NOT FOUND», а чем заканчивается цепочка.

Главные действующие лица расследования из этого списка — NAME NOT FOUND, ACCESS DENIED и SHARING VIOLATION. У каждого есть типовая схема; в следующей главе смотрим со стороны симптомов.

Легко пропустить и обратный рисунок: «причиной оказался SUCCESS». Ответ на «исправленный конфигурационный файл не применяется» не раз оказывался SUCCESS по старому файлу в другом месте. Если смотреть только неуспешные результаты, успешно прочитанный «не тот правильный ответ» ускользает. Надёжнее сузить по Path и пройти все обращения к файлам этого типа, включая успешные.

5. Типовые схемы расследования по симптомам

5.1 «Настройки поменял — эффекта нет» — выясняем, откуда идёт чтение

Поставьте Include Path / contains / имя конфигурационного файла и запустите приложение: видно, из каких папок и в каком порядке оно искало файл с этим именем. Частая правда — одна из следующих.

• Читали не файл рядом с exe, а копию под %APPDATA% или ProgramData (по задумке копия создаётся при первом запуске)
• Обращения 32-разрядного процесса к реестру и системным папкам ушли через перенаправление WOW64, и «то место, куда смотрели», не совпало с реальным
• Запись в Program Files по месту установки ушла в виртуализацию (VirtualStore), и чтение с записью оказались в другом месте

В любом из этих случаев ProcMon показывает полный путь в Path, поэтому причина видна сразу. Обратная сторона — как проектировать размещение конфигурации — в статье «Не только appsettings.json — практическое руководство по управлению конфигурацией Windows-бизнес-приложений (настройки окружений, секреты и место записи)».

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

1. Сверьте сторону чтения со стороной записи. Тем же фильтром снимите сохранение из экрана настроек и посмотрите, на какой путь уходят WriteFile или RegSetValue. Если путь чтения и путь записи не совпадают — это и есть симптом. Когда один и тот же параметр есть и в реестре, и в файле, по порядку строк в логе видно, что читают первым.
2. Решите, какая сторона «правильная». Это уже не расследование, а проектное решение. На практике спокойнее резать по правам на запись: то, что пользователь меняет с экрана, — под профилем (можно писать); то, что должно быть фиксированным для среды, — в каталоге установки (только чтение). Если пишут в Program Files и это уезжает в VirtualStore, это сигнал пересмотреть само место хранения.
3. После правки снимите тот же захват ещё раз. «Починилось» подтверждают не внешним видом приложения, а логом. Нужно увидеть SUCCESS по целевому пути и что чтение со старого места пропало. Копии в VirtualStore и под профилем продолжают читаться, даже если исходный файл уже исправили, поэтому сначала удалите старый файл, иначе решение будет ложным.

5.2 «Не запускается только в этой среде» — идём по поиску DLL

Если падает сразу после старта или появляется ошибка вроде «DLL не найдена», поставьте Include по процессу, добавьте Path / ends with / .dll и смотрите цепочку NAME NOT FOUND. Поиск DLL в Windows идёт по папкам в фиксированном порядке, поэтому в логе ProcMon это видно как есть: «NAME NOT FOUND выстраиваются в порядке поиска, и где-то SUCCESS (либо до конца не нашли)». Виновник — та DLL, для которой SUCCESS так и не появился. Здесь же находится и обратный рисунок: SUCCESS есть, но взяли старую DLL не из того места. Логику порядка поиска стоит читать вместе со статьёй «Как работает разрешение имён DLL в Windows — порядок поиска и SxS».

«Класс не зарегистрирован» вокруг COM/ActiveX устроен так же и наблюдается как NAME NOT FOUND при RegOpenKey под CLSID. Когда из‑за путаницы 32/64 бит смотрят не то представление реестра, кратчайший путь — ProcMon по порядку из статьи «Office 2024/Microsoft 365: почему не работает ActiveX и как это диагностировать».

5.3 «Получаем ACCESS DENIED» — смотрим, от чьего имени идёт процесс

Нашли ACCESS DENIED — дважды щёлкните событие и на вкладке Process в свойствах посмотрите, от какого пользователя шёл процесс. Здесь всплывают расхождения вроде «служба работала не как SYSTEM, а под ограниченной служебной учётной записью» или «при запуске из Планировщика заданий это был другой пользователь». Если объект — файл, сверка с ACL этого пути обычно закрывает причину. Когда вмешивается антивирус, часто видно, что сразу до или после к тому же пути обращается другой процесс (движок антивируса) — это как раз доказательство, которое даёт хронология ProcMon. После правки ACL или учётной записи службы тем же фильтром снимите захват ещё раз и убедитесь, что операция стала SUCCESS. Сняли первый ACCESS DENIED — упёрлись в следующий путь: поэтапный отказ встречается часто, и без лога это выглядит как «починили, а симптом тот же».

5.4 «Иногда падает обработка файлов» — ищем, кто даёт SHARING VIOLATION

Нарушение совместного доступа расследуют по времени. Include по Path, фильтр по процессу не ставить, снять захват: в строках до и после сбоя видно, кто в тот момент держал тот же файл открытым. Типичные «кто» — резервное копирование, антивирус, застрявший процесс Excel. Как проектировать обмен файлами так, чтобы этой гонки не было, — в статье «Интеграция через файлы: блокировки, атомарный claim и практические рекомендации»; застрявший Excel — в «Почему после работы с Excel из C# остаётся EXCEL.EXE — освобождение COM-ссылок и решение о замене». Отдельно: если нужно только «кто держит файл прямо сейчас», поиск по хендлам в Process Explorer (Ctrl+F) быстрее ProcMon.³

5.5 «Долго стартует» — намечаем, где уходит время

Откройте Options > Select Columns… и в списке столбцов включите Duration — видно, сколько заняла каждая операция. Через Process Activity Summary и File Summary в меню Tools можно свернуть число операций и время по процессам и файлам. Для первой оценки вроде «при старте десятки тысяч чтений реестра» или «доступ по сетевому пути ждал до таймаута» этого достаточно. Но серьёзное профилирование, где уходит CPU, — не зона ProcMon. Если медленно не из‑за I/O, а из‑за вычислений, эстафету берут PerfView и dotnet-trace.

5.6 Проблемы при загрузке и входе — Boot Logging

Когда проблема случается раньше, чем ProcMon успевают запустить руками, — «служба падает ещё до входа», «приложение из автозагрузки не стартует» — берут Enable Boot Logging в меню Options. При следующей загрузке события пишутся с самого начала boot, а при следующем запуске ProcMon предложит сохранить их. Журналирование с момента загрузки — официальная функция ProcMon,¹ и в расследованиях порядка автозагрузки и скриптов входа это единственный взгляд на те события.

6. Сохранение и передача лога — когда захват делает заказчик

В расследовании сбоев нередко среда, где симптом воспроизводится, есть только у заказчика. Лог ProcMon сохраняется как PML, и на другой машине видны все столбцы и все подробности, поэтому разделение «заказчик снимает, мы разбираем» работает. Инструкцию для заказчика держим в таком виде.

1. Запустить Procmon.exe от имени администратора и принять лицензионное соглашение
2. После запуска сначала Ctrl+E — остановить захват, Ctrl+X — очистить экран
3. Ctrl+E — начать захват и воспроизвести проблемную операцию
4. Как только воспроизвели (или появилась ошибка), сразу Ctrl+E — стоп
5. File > Save… (Ctrl+S). В диалоге задать два пункта и сохранить:
   • Events to save: из трёх вариантов (All events / Events displayed using current filter / Highlighted events) выбрать All events
   • Format: из трёх вариантов (Native Process Monitor Format (PML) / Comma-Separated Values (CSV) / Extensible Markup Language (XML)) выбрать Native Process Monitor Format (PML)
6. Полученный PML упаковать в ZIP и отправить

Формат Native (PML) нужен потому, что только PML держит все данные и открывается как есть в ProcMon на другой машине.¹ CSV удобно открыть в таблице, но туда уходят только видимые столбцы, без стека и прочих подробностей. Для разбора на нашей стороне это не подходит.

Ключ — пункт 5, «All events». Даже если на экране у заказчика остался фильтр, в записи полный объём, и фильтр можно поставить заново у нас. Если воспроизведение долгое или момент неизвестен, иначе память будет расти без остановки: задайте хотя бы одно из двух — Filter > Drop Filtered Events, чтобы писался только нужный процесс, либо File > Backing Files, чтобы писать в файл, а не в виртуальную память. Оставить захват на ночь, не зная этих двух пунктов, — типичный путь исчерпать память и упереться в предел ProcMon раньше, чем в исследуемую проблему.

Если нужна автоматизация, есть ключи командной строки. /AcceptEula убирает диалог согласия, /BackingFile задаёт файл записи, /Runtime останавливает через указанное число секунд, /Terminate завершает уже запущенный ProcMon. Из этого собирают схему «при сбое оператору достаточно одного пакетного файла — данные останутся». Заранее решить, что снимать при сбое, — та же мысль, что в статьях про сбор аварийных дампов и проектирование журнала событий.

7. Где ProcMon кончается и какие инструменты брать вместо него

ProcMon смотрит хронологию операций и подходит не для любого расследования. В наших работах роли делятся так.

Таблица выше — от инструментов. Ниже то же, перевёрнутое: чего ProcMon не показывает. Если расследование промахнулось, ищите замену здесь.

На границе чаще всего путают три зоны.

• Сеть. ProcMon пишет события подключения и отправки / приёма TCP/UDP (какой процесс с кем говорил), но содержимое пакетов не видно. Разбор протокола — Wireshark или штатный pktmon Windows.⁴
• Память. «Память всё растёт» ProcMon не отслеживает. Для управляемой кучи — как отличить ожидание GC от утечки, для хендлов — порядок из расследования утечки хендлов.
• Стек. На самом деле ProcMon тоже пишет стек потока, из которого ушло каждое событие (двойной щелчок → вкладка Stack). Если настроены символы, на уровне кода видно, «кто инициировал это обращение к файлу». Здесь уже общая граница с миром WinDbg, и начинает работать учёт символов (PDB).

8. Итог — «сначала факты, потом код»

Первое в расследовании сбоев, которые зависят от среды, — не читать код и не строить гипотезы, а записать, что произошло на самом деле. ProcMon — кратчайший путь к этому: минута на установку, несколько минут на захват, и на руках уже твёрдые факты — какие пути, в каком порядке, с какими правами трогали и на чём споткнулись. Два этапа фильтра (процесс → Result), чтение Result, которые выглядят как сбой, а на деле нормальны, передача лога со всеми событиями — этих трёх вещей достаточно, чтобы расследование, застрявшее на «у разработчика не воспроизводится», за тот же день сдвинулось с места.

Мы берёмся за расследование сбоев с неизвестными условиями воспроизведения, за порядок сбора данных в среде заказчика и за разбор причин в связке ProcMon, WinDbg и PerfView. Можем помочь уже на стадии «в логах пусто, а приложение не работает».

Связанные статьи

• Как читать аварийные дампы в WinDbg + SOS — практика анализа после сбора
• Как точно найти причину «медленной работы» с PerfView и dotnet-trace — практическое введение в анализ производительности .NET
• Сбор дампов сбоев Windows — введение: WER, ProcDump, WinDbg
• Как работает разрешение имён DLL в Windows — порядок поиска и SxS
• Утечка хендлов: почему приложение промышленной камеры падает после месяца работы

Похожие направления консультаций

ООО «Komura Soft» (合同会社小村ソフト) занимается поиском причин сбоев, которые плохо воспроизводятся из‑за зависимости от среды, порядком сбора данных при отказе и поддержкой в устранении неполадок существующих Windows-приложений.

• Расследование сбоев и анализ причин
• Техническая консультация и обзор проектных решений
• Доработка и поддержка существующего Windows-ПО
• Контакты

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли запускать ProcMon в продакшене?

Кратковременный захват на практике делают часто, но это не безусловно безопасно. ProcMon загружает драйвер и записывает огромный поток событий, поэтому на серверах, где событий много, нагрузка на CPU и память заметна. Три меры: (1) начинать запись непосредственно перед воспроизведением и останавливать сразу после, сводя время захвата к минимуму; (2) если наблюдение должно быть долгим — включить в меню Filter пункт Drop Filtered Events, чтобы события вне фильтра не сохранялись; (3) задать Backing File, чтобы писать в файл, а не в память. Имеет смысл проводить это вне рабочего времени или после снимка системы — то есть через тот же процесс согласования, что и обычные изменения.

Событий слишком много, нужную строку не найти. Как сузить выборку?

Рабочий порядок: сначала Include по Process Name, оставив только нужный процесс, затем сузить по Result до неуспешных результатов (NAME NOT FOUND, ACCESS DENIED и т. п.). Когда нашлась одна подходящая строка, дальше сужают интерактивно: правый щелчок по строке → Include или Exclude. Обратная ошибка тоже частая: сохранили лог уже с фильтром и потом не хватило данных. Если файл уходит другому человеку, помните: фильтр только прячет строки на экране — сохраняйте все события. Настройки фильтра переживают перезапуск, поэтому если «ничего не видно», первым делом проверьте через Reset Filter в меню Filter, не остался ли фильтр с прошлого раза.

BUFFER OVERFLOW в столбце Result — это баг или признак атаки?

Нет. К атаке переполнения буфера из мира безопасности это не относится. Это штатный обмен вызовами API: «данные не поместились в буфер, который подготовил вызывающий код, поэтому API вернул нужный размер». Многие API сначала вызывают с маленьким буфером, узнают размер, выделяют память и вызывают снова — если сразу после этого по тому же пути идёт SUCCESS, проблемы нет. NAME NOT FOUND тоже часто значит лишь «на этом шаге порядка поиска объекта не было»; если в конце где-то SUCCESS, это не отклонение. Неуспешный Result можно назвать причиной только после того, как видно, что сбой этой операции связан с симптомом приложения.

Когда брать Process Explorer, а когда Process Monitor?

Process Monitor пишет хронологию операций: когда, какой процесс, к какому пути, что сделал и чем закончилось. Process Explorer показывает состояние прямо сейчас: какие файлы и DLL открыты каким процессом, как используются CPU и память. «Этот файл не удаляется, кто его держит» быстрее всего ищут поиском по хендлам в Process Explorer. «Когда и в каком порядке приложение читает этот файл» — это Process Monitor. На практике оба инструмента держат в Sysinternals Suite и запоминают простое правило: состояние — Process Explorer, история — Process Monitor.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.