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

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

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

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

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

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

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

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

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

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

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

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

3. Filter — ProcMon нужно сначала отфильтровать, а потом читать

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

Этап 1: сузить по процессу. Откройте диалог Filter через Ctrl+L и добавьте условие 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) — оно раскрашивает строки по тем же условиям, что и Filter, поэтому если нужно видеть общий поток, но при этом выделить только аномальные результаты, стоит использовать не Filter, а именно выделение цветом.

Есть три особенности, о которых стоит знать заранее, иначе легко попасть впросак.

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

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

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

Из них главными действующими лицами расследования становятся три значения: 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 — практика управления конфигурацией».

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».

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

5.3 «Возникает ACCESS DENIED» — проверяем, от чьего имени выполняется процесс

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

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

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

5.5 «Медленный запуск» — определяем, где расходуется время

Если добавить столбец Duration в настройках столбцов, можно увидеть время, затраченное на каждую отдельную операцию. Кроме того, через Process Activity Summary и File Summary в меню Tools можно получить сводку по количеству операций и затраченному времени для каждого процесса и файла. Этого вполне достаточно для предварительной оценки: «при запуске выполнялись десятки тысяч операций чтения реестра» или «обращение по сетевому пути ожидало таймаута». Однако полноценное профилирование того, где расходуется CPU, не относится к области ProcMon. Если приложение медленное не из-за I/O, а из-за вычислений, эстафету принимают PerfView и dotnet-trace.

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

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

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

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

1. Запустить Procmon.exe от имени администратора и принять лицензионное соглашение
2. После запуска сначала остановить захват через Ctrl+E и очистить отображение через Ctrl+X
3. Запустить захват через Ctrl+E и воспроизвести проблемную операцию
4. Как только воспроизведение удалось (или появилась ошибка), сразу остановить захват через Ctrl+E
5. В File > Save выбрать не Events displayed using current filter, а All events, сохранить в формате PML, заархивировать в ZIP и отправить

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

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

7. Ограничения ProcMon и разграничение с другими инструментами

ProcMon — инструмент для просмотра «хронологии операций», и он подходит не для всех видов расследований. В наших расследованиях распределение ролей выглядит так.

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

• Сеть: ProcMon записывает события подключения и отправки/приёма по TCP/UDP (какой процесс с кем связывался), но содержимое пакетов не видно. Для расследования на уровне протокола нужны Wireshark или стандартный для Windows pktmon.⁴
• Память: «Постоянно растущее потребление памяти» через 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) если требуется длительное наблюдение — включить Drop Filtered Events в меню Filter, чтобы не сохранять события, не прошедшие фильтр; (3) настроить Backing File так, чтобы запись велась в файл, а не в память. Также рекомендуется проводить такие работы вне рабочего времени или после снятия снапшота — то есть проводить их через тот же процесс согласования, что и обычные изменения.

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

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

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

Нет. Это не связано с атакой переполнения буфера в смысле информационной безопасности — это нормальный обмен вызовами 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.