Практика применения утилиты process monitor. Диагностика медленной загрузки Windows с помощью Process Monitor

17.04.2019

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

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

Утилита многофункциональная, но в данном примере нас интересует одна функция - мониторинг запускаемых во время загрузки Windows процессов. Работает она следующим образом: в ключе реестра HKLM\SYSTEM\CurrentControlSet\Services создается специальная служба, загружающая драйвер procmon23.sys , который отслеживает запуск всех процессов, стартующих после запуска основного файла загрузки Winload.exe . Данные записываются в лог и выводятся в окне утилиты в графическом виде, позволяя легко определить, загрузка какого компонента занимает больше всего времени.

Итак, скачиваем с сайта разработчика technet.microsoft.com/en-us/sysinternals/processmonitor.aspx и запускаем от имени администратора. В главном меню выберите -> Enable Boot Logging.

В открывшемся окошке отметьте галочкой Generate thread profiling events с включенной радиокнопкой Every second .

Нажмите «OK» и перезагрузите компьютер . Когда появится рабочий стол, запустите повторно. Откроется окошко с уведомлением «A log of boot-time activity was created…» . Нажмите «OK» и сохраните файл PML в любое удобное вам расположение.

П римечание: протоколирование событий драйвером procmon23.sys запустится сразу после перезагрузки системы и будет продолжаться в фоновом режиме до тех пор, пока пользователь не запустит утилиту . Если утилиту не запустить, временный файл дампа procmon.pmb в каталоге *C:\Windows* заполнит все свободное пространство на диске.

В нашем примере было создано два файла дампа Bootlog .pml и Bootlog-1.pml общим размером 464 Мб . Перед тем, как приступить к их анализу, кликните в окне по заголовку таблицы данных правой кнопкой мыши, нажмите

И отметьте в открывшемся окошке пункт (столбец) .

И установите в окне создания фильтра параметры Duration, more than и 10 , как показано на скриншоте.

10 в данном примере это количество секунд, затраченных процессами на выполнении своих операций.

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

Для более детального анализа можно воспользоваться опцией из меню Tools , отображающей процессы в виде древовидного списка с указанием дополнительных сведений о продолжительности, времени старта и завершения каждого процесса.

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

Для диагностики причин медленной загрузки ОС Windows существует ряд довольно мощных утилит и методик анализа журналов событий, позволяющих выполнить детальную отладку всех этапов процесса загрузки системы и запуска служб (xperf/xbootmgr из Windows Performance Toolkit / Analyzer). Но их использование может вызвать ряд трудностей, особенно для начинающего системного администратора. В этой статье мы покажем, как с помощью Process Monitor можно довольно просто и быстро определить, какие программы, службы и драйвера долго выполняются при старте системы, увеличивая тем самым общее время загрузки для пользователя.

Безусловно, всем системным администраторам Windows, должна быть знакома утилита Process Monitor из комплекта системных утилит Sysinternals. Утилита Process Monitor позволяет в реальном времени отслеживать активность запущенных процессов, обращения к файловой системе и реестру. Одной из малоизвестной функцией Process Monitor является возможность включения режима мониторинга процессов запускаемых во время загрузки Windows.

Для диагностики этапа загрузки, Process Monitor создает отдельную службу в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services. Данная служба загружает драйвер режима загрузки procmon23.sys , стартующий после запуска Winload.exe, который протоколирует активность всех, процессов выполняющихся во время запуска системы и входа пользователя.

Скачайте и распакуйте архив с Process Monitor (http://download.sysinternals.com/files/ProcessMonitor.zip)
Запустите с правами администратора файл procmon.exe
В меню Options выберите пункт Enable Boot Logging
В появившемся окне выберите опцию . В этом режиме драйвер procmon будет перехватывать состояние всех процессов каждую секунду
Перезагрузите компьютер и дождитесь появления рабочего стола
Драйвер procmon23.sys будет записывать все события до тех пор, пока пользователь не запустит утилиту Process Monitor . После этого режим протоколирования загрузки отключается.
В окне Process Monitor соглашаемся с предложение сохранить собранные данные в файл.
Примечание . Если не остановить работу Process Monitor, то временный файл журнала %windir%\procmon.pmb со временем займет все свободное место на системном диске.
Выберите каталог, в котором нужно сохранить файл и дождётесь его сохранения. В моем случае в целевом каталоге появилось три файла Bootlog .pml, Bootlog-1.pml и Bootlog-2.pml общим размером 700 Мб.
Щелкните по заголовку таблицы в окне ProcMon, выберите Select Columns и включите отображение столбца Duration
Создадим новый фильтр в меню Filter .
В качестве параметра фильтрации укажем Duration , условие more than и значение 10. Нажмите кнопку Add и ОК.
Таким образом, в списке процессов окажутся только те процессы, у которых на выполнение некоторых операций ушло больше 10 секунд (10 секунд я выбрал для большей наглядности примера).
Также для анализа процесса загрузки можно воспользоваться функцией в меню Tools ->Process Tree , позволяющей отобразить все процессы в виде графического дерева с информацией о начале, завершении и длительности процесса.

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

Как правило, этот анализ поможет выявить «тормозящие» процессы, засевший в системе троян (в первую очередь нужно анализировать дочерние процессы Winlogon.exe), принять решение о необходимости удалить/обновить проблемное ПО или драйвер устройства, отключить некоторые службы или изменить тип их запуска (отложенный запуск или ручной по запросу), убрать программы из . Чаще всего в этом списке оказываются антивирусы и другое «тяжелое» ПО.

По программе Process Monitor дано уже довольно-таки много материала, да и изучение основ функционирования утилиты всегда было доступно даже для неподготовленного пользователя. Но все же, я лично не совсем понимал многие аспекты работы (а некоторые не понимаю до сих пор:), поэтому и решил набросать очередную заметку по поводу данной, весьма полезной утилиты, дабы впоследствии можно было использовать статью как своего рода подсказку. Если рассматривать любую операционную систему с точки зрения обобщения, то можно условно дифференцировать её на блоки кода/данных, которые взаимодействуют между собой на основе определенных закономерностей. Чтобы приблизиться к привычным нам терминам, будем считать упомянутый блок процессом, объединяющим в себе и код и данные, предназначающимся для решения определенной задачи. Таким образом, взаимодействие между подобными процессами и составляет (за некоторым исключением) понятие функционирования операционной системы. Во время работы операционной системы, в ней выполняется большое количество процессов и назначение любого из этих процессов может варьироваться в достаточно широком диапазоне.

Каждый процесс в операционной системе совокупностью собственных операций и результатов их выполнения, фактически определяет отпечаток активности системы в тот или иной момент времени. Но, как мы знаем из теории, сами процессы являются лишь контейнерами для потоков (нитей), которые непосредственно и делают всю вычислительную работу. Понятно, что потоки представляют собой код, набор машинных команд, исполняемых процессором, но это на достаточно низкоуровневом восприятии. Если же оперировать структурами Windows, то потоки все так же содержат машинный код, однако весь функционал операционной системы доступен через обращение к функциям различных системных библиотек и вызовы драйверов, поэтому потоки, помимо простых арифметико-логических операций, взаимодействуют с различными подсистемами Windows: виртуальной памятью, файловой системой, реестром, аппаратными компонентами и многими другими. Межпроцессное взаимодействие настолько интенсивно, что в каждый момент времени в системе выполняются тысячи подобных операций. Соответственно, в реалиях Windows нам было бы интересно наблюдать взаимодействие процессов именно с определенными компонентами операционной системы на уровне функций и результатов их исполнения, поскольку именно такой уровень активности вполне достаточен для решения большинства задач. Подобная информация была бы нам крайне полезна и с точки зрения чисто исследовательского интереса к изучению алгоритмов, и с точки зрения поиска решения тех или иных проблем, возникающих в процессе работы. Но нам потребуется инструмент, который в состоянии предоставить столь подробную информацию, ведь нам необходимо погрузиться в межпроцессное взаимодействие значительно глубже уровня встроенного инструментария, понять, что конкретно делают процессы. Что-то подобное нам предоставляет средство под называнием Process Monitor , принадлежащее к классу инструментов с расширенной функциональностью, и будет темой нашей сегодняшней статьи.
Process Monitor - программа мониторинга активности процессов в операционной системе, которая в режиме протоколирования операций позволяет отслеживать активность процессов по отношению к таким подсистемам ОС как файловая система, реестр, сеть. Позволяет оценивать количество процессорного времени, расходуемого для выполнения потоков в рамках процессов.
Process Monitor выполняется наблюдение в реальном времени для следующих классов событий:

Файловая система: создание(открытие)/закрытие/чтение/запись/удаление элементов файловой системы: файлов, каталогов, атрибутов, содержимого.
Реестр: создание/чтение/запись/перечисление/удаление элементов реестра: ветвей, ключей, значений.
Сеть: установка соединения, передача данных, закрытие соединения. Информация об источнике/приемнике TCP/UDP трафика. Общая информация о протоколах, пакетах. Сами передаваемые данные не записываются.
Процесс/поток: Создание процесса, создание потока внутри процесса, завершение потока/процесса. детальная информация о процессе (путь, командная строка, ID пользователя/сессии), запуск/завершение, загрузка образов (библиотеки/драйвера), стек выполнения.
Профилирование: Специальный класс событий, записываемых с целью отслеживания количества процессорного времени, затрачиваемого каждым процессом. Использование памяти процесса.

На ум сразу приходят основные, наиболее вероятные сценарии применения Process Monitor:

В каких именно ключах реестра та или иная программа хранит свои установки?
Какие операции совершает процесс при старте, в процессе функционирования и на этапе закрытия?
Кому принадлежат те или иные файлы? Как часто владелец к ним обращается?
Какой процесс обращается к внешним узлам сети?
Какой процесс тормозит загрузку операционной системы?

Process Monitor позволяет получить ответ на вопрос: какие действия выполняет тот или иной процесс в системе.

Но, в отличии от таких инструментов, как Process Exploer, это не утилита реального времени, позволяющая на ходу взаимодействовать с процессами, закрывать хендлы, убивать процессы и производить другие подобные действия, это скорее глобальный журнал, состоящий из событий, происходящих в операционной системе. Ключевым словом в предыдущем предложении было "подробный", потому как имеются в виду не те события, которые мы привыкли видеть, к примеру, в Журнале событий, а более низкоуровневые, происходящие на заданного набора функций API некоторых компонентов ОС. Эти, как и некоторые другие, уникальные особенности функционала делают программу Process Monitor практически незаменимым инструментом для устранения неполадок и выяснения причин подозрительной активности в системе.
Но не спешите очаровываться, ибо на каждую бочку меда всегда припасена своя ложка дегтя. Так и в случае с Process Monitor имеются некоторые "нюансы". Не стоит рассматривать Process Monitor в качестве эдакой волшебной палочки-выручалочки на все случаи жизни, поскольку "видит" он далеко не все. К примеру, он не отследит перемещение указателя мыши, перетаскивание окон, не покажет содержимое пакетов сетевого трафика, не покажет все многообразие вызываемых программой функций, и это далеко не полный перечень тех вещей, которых Process Monitor делать не умеет. Как и в любом деле диагностирования проблем операционной системы, подобный инструментарий предоставляет, грубо говоря, ограниченный набор функций и операций потока, оставляя поле для деятельности и требуя от специалиста самостоятельных выводов и порой достаточно глубоких знаний, которые и составляют основу любого анализа. Я не берусь утверждать, что абсолютно все диагностируемые с помощью Process Monitor проблемы требуют высокого уровня знания архитектуры ОС, но это не такое уж и редкое явление. Пример из дикой природы: как-то раз попался баг с Outlook 2010, когда в свойствах программы outlook.exe были выставлены опции совместимости, которые препятствовали запуску программы со стартовой ошибкой "Невозможно открыть почтовые папки, используемые по умолчанию. Не удается открыть банк сообщений". Отследить данную проблему при помощи утилиты Process Monitor можно, но надо знать, что именно искать в огромном стоге сообщений от процесса Outlook. Для того случая надо было искать флаги WINSRV08SP1 и RUNASADMIN при считывании ключа AppCompatFlags , что уже само по себе говорит о том, что порой надо представлять что мы хотим найти. В идеале (а идеал недостижим), неплохо бы представлять себе, как именно меняется профиль загружаемой в режиме совместимости программы на уровне генерируемых событий по отношению к типовой загрузке приложения. В конечном итоге надо было понять, почему именно почтовому клиенту не удалось загрузить конфигурацию пользователя. Конечно, возможно именно этот пример не такой уж и показательный, потому как достаточно сложен, и было бы разумнее использовать другие средства, просто я хочу обратить внимание на то, что Process Monitor это не отладчик, и он не может отловить место вызова функции отображения окна с ошибкой, не сможет проникнуть в логику работы той или иной внутренней функции, не покажет состояние регистров, областей памяти и прочих важных для процесса структур. Иногда нет видимого результата об отсутствии доступа, поэтому иногда собираемая информация неявно содержит описание проблемы и над полученными результатами, выдаваемыми Process Monitor, надо еще поразмышлять. Изредка и вовсе наблюдаются случаи, когда функциональных возможностей Process Monitor"а просто не хватает чтобы докопаться до сущности проблемы, но это никак не умоляет достоинств данного инструмента, поскольку в большинстве случаев он довольно быстро позволяет добраться до причины бага. Ну не будете же Вы по каждой ошибке сразу браться за отладчик и тратить часы на пролет в попытке изучить алгоритм работы сбойного модуля? .. хотя:)
Утилита Process Monitor включает в себя возможности более ранних программ Sysinternals: программы отслеживания обращений к реестру Regmon и программы отслеживания обращений к файловой системе Filemon, давно уже сошедших со сцены. В дополнение ко всему Process Monitor может сохранять весь журнал событий в файл весом до 1 гигабайта.

Как это работает

В процессе наблюдения за активностью Process Monitor была выявлена интересная особенность, оказывается программа использует собственный драйвер режима ядра (а как же подпись? а подпись от Symantec). В 32-разрядной системе Process Monitor использует 32-битный драйвер-фильтр под названием procmon23.sys как в процессе работы непосредственно исполняемого образа, так и на этапе загрузки операционной системы (при включении опции Enable Boot Logging). Но ведь кроме самого исполняемого образа procmon.exe в рабочей директории приложения нет никаких других бинарных файлов? Дело в том, что драйвер упакован в тело главного исполняемого модуля procmon.exe . При помощи любого средства работы с ресурсами PE-файлов можно удостовериться в том, что драйвер procmon23.sys содержится внутри исполняемого файла в ресурсе RCDRIVERNT директории BINRES секции ресурсов, то есть является частью основного файла:

В 64-разрядной системе Process Monitor при запуске распаковывает во временную директорию %TEMP% скрытый файл с именем Procmon64.exe . Образ procmon64.exe содержится в ресурсе 1308 директории BINRES внутри ресурсной секции основного файла procmon.exe . А вот уже в самом Procmon64.exe , в секции BINRES ресурсной секции содержится 64-битный драйвер, который используется в процессе работы.

Драйвер procmon23.sys может работать и как драйвер режима загрузки. Когда пользователь активирует опцию Enable Boot Logging , Process Monitor копирует драйвер в папку %SystemRoot%\System32\Drivers и прописывает его в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services со значением параметра Start = 0, что говорит о том, что драйвер будет загружен на стадии выполнения Winload.exe при загрузке операционной системы.

Похоже, через этот драйвер-фильтр проходят все события, отслеживаемые Process Monitor. В дополнение к этому, Process Monitor использует технологию Трассировки событий (ETW, Event Tracing for Windows), как минимум для наблюдения за событиями сетевой активности. Не совсем пока ясно, тот же драйвер используется в качестве контроллера и получателя для ETW или же сам исполняемый модуль? Напомню, что ETW это своеобразная расширяемая система журналирования, встроенная в систему Windows, реализованная на уровне ядра и позволяющая (по запросу) собирать события от приложений пользовательского режима и модулей режима ядра. А как мы знаем, практически во все компоненты операционной системы включена возможность отслеживания выполняемых операций. Понятное дело, что функционал ETW значительно шире, он предоставляет обширнейшую информацию по функционированию: переключение контекста, статистика по прерываниям, отложенные вызовы процедур (DPC), процедуры обработки прерываний (ISR), создание и уничтожение процессов и потоков, дисковый ввод-вывод, ошибки страниц, переходы процессора между режимами в рабочем состоянии (p-state), операции с реестром, и многое другое.

Интерфейс

Перед запуском неплохо было бы получить исполняемый модуль утилиты. Скачать Process Monitor можно отсюда . Утилита распространяется в виде портабельного приложения и не требует инсталляции, а просто может быть извлечена из архивного файла в произвольную директорию, что крайне полезно при диагностировании с переносных носителей и при интегрировании в среду предустановки (WinPE).

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

В случае запуска Process Monitor с установленными в предыдущих сеансах работы фильтрами, программа открывает окно настройки фильтров (Filter). Делается это для того, чтобы пользователь смог, при желании, модифицировать фильтры перед началом процедуры сбора данных.
Интерфейс программы Process Monitor чрезвычайно прост и по умолчанию выглядит следующим образом:

Согласитесь, всё гениальное действительно просто. Простота интерфейса обуславливает интуитивность восприятия происходящего в системе. Непосредственно после запуска Process Monitor сразу же начинает захватывать события, происходящие в операционной системе, производится мониторинг основных компонентов, таких как: файловая система, реестр, сеть, активность процессов/потоков. После захвата события, не попавшие под фильтр, выводятся в хронологическом порядке в главное окно приложения. Причем пользователь наблюдает такое огромное количество данных, которое просто по первости может запросто обескуражить, вся эта тонна данных мгновенно переполняет основное окно программы и устремляется за её пределы, о чем красноречиво говорит стремительно уменьшающийся боковой ползунок прокрутки. Каждая выводимая таким образом строка представляет собой событие, произошедшее в системе, видимое и захваченное драйвером Process Monitor и не попавшее под правила фильтрации. Основной массив информации отформатирован в виде таблицы, соответственно каждая строка поделена на некоторое количество столбцов, состав и расположение которых может быть изменен через настройки программы. В конфигурации по-умолчанию используются следующие столбцы:

Столбец	Наименование	Обозначение
1	Time of Day	Время возникновения события. Отображается в долях секунд в формате ЧЧ:ММ:СС,ССССССС с точностью в семь десятичных знаков после запятой. Точность выводимого временного значения зависит от точности используемого в компьютере аппаратного таймера (8254/RTC/HPET).
2	Process Name	Имя процесса. Колонка отображает имя процесса, который выполнил операцию. Выводится только лишь имя процесса, однако если вы наведете курсор мыши на интересующее имя, дополнительно отобразиться и полный путь к модулю. В колонке отображается иконка (значок) приложения, запакованная в ресурсной секции бинарного файла.
3	PID	Идентификатор процесса. Довольно полезный параметр, особенно для "комплексных" процессов, таких как svchost.exe.
4	Operation	Операция. Имя зафиксированной низкоуровневой операции, производимой процессом по отношению к целевому объекту. Обычно данное имя соответствует имени функции, которая вызывается для выполнения операции. Дополнительно отображается иконка класса события (регистр, файл, сеть, процесс).
5	Path	Путь к целевому объекту, по отношению к которому процесс выполняет операцию. Не путайте с путем к процессу (модулю). Выводится только в том случае, если путь применим к объекту. Возможные значения: Путь файловой системы, начинающийся с буквы диска; Путь к ветви/ключу реестра; Сетевой путь (исходные и целевые адреса и порты); Сетевой путь (в формате UNC);
6	Result	Результат операции. Возвращаемый функцией результат операции, обозначающий степень успешности того или иного действия. Более подробно описан в отдельной таблице, приведенной ниже.
7	Detail	Развернутая информация о деталях произошедшего события. Как то: Запрашиваемый уровень доступа, размер данных, тип данных, размер пакета сетевого ввода-вывода, коды атрибутов файлов.

Поле результата операции (Result) является одним из ключевых и требует дополнительного пояснения:

Результат	Результат	Описание
SUCCESS	УСПЕХ	Операция завершена успешно.
ACCESS DENIED	ОТКАЗАНО В ДОСТУПЕ	Операция не выполнена. Дескриптор защиты объекта не предоставляет процессу необходимые права доступа к объекту.
SHARING VIOLATION	НАРУШЕНИЕ СОВМЕСТНОГО ДОСТУПА К ФАЙЛУ	Операция не выполнена. Объект уже кем-то открыт и не поддерживает режим совместного использования.
NAME COLLISION	КОНФЛИКТ ИМЕН	Процесс пытался создать уже существующий объект.
NAME NOT FOUND	ИМЯ НЕ НАЙДЕНО	Попытка открытия несуществующего объекта: путь найден а имя объекта нет. Не смотря на "громкую" формулировку, в большинстве случаев не представляет интереса при поиске проблем. Дело в том, что данный результат довольно часто возвращается как результат штатных операций. Типичным примером может служить проверка существования файла или ключа реестра по определенному пути. После возврата подобного результата, код, выполнявший проверку, просто пойдет по другому логическому ветвлению. Поэтому: Данный результат может использоваться для поиска проблем с оговорками.
PATH NOT FOUND	ПУТЬ НЕ НАЙДЕН	Попытка открытия несуществующего объекта: путь не найден. То же самое, что и предыдущий. Данный результат может использоваться для поиска проблем с оговорками.
NO SUCH FILE	ФАЙЛ НЕ СУЩЕСТВУЕТ	Попытка открытия несуществующего объекта или группы объектов. Обычно возвращается при запросе группы объектов по маске, например *.exe указывает на все файлы с расширением.exe в запрашиваемой директории. Если ни одного файла, подпадающего под установленную маску не найдено, то возвращается подобный результат.
NAME INVALID	НЕПРАВИЛЬНОЕ ИМЯ	Процесс запросил объект с неправильным именем. Вероятно возникает, когда имя запрашиваемого объекта имеет неправильный формат, содержит недопустимые символы, в общем, является недопустимым.
NO MORE ENTRIES	ЗАПИСИ ОТСУТСТВУЮТ	Процесс завершил перечисление содержимого раздела реестра. Обычно говорит о фактическом окончании данного процесса, указывает на то, что больше записей нет.
NO MORE FILES	ФАЙЛЫ ОТСУТСТВУЮТ	Возникает при запросе перечисления объектов в каталоге файловой системы. Обычно говорит о фактическом окончании данного процесса, указывает не то, что больше файлов нет.
END OF FILE	КОНЕЦ ФАЙЛА	Достигнут конец файла. Процесс достиг конца файла в одной из своих операций (например: чтение из файла).
BUFFER TOO SMALL	БУФЕР СЛИШКОМ МАЛ	Недостаточный объем буфера. Выделенный буфер слишком мал для завершения данной операции, требуется выделить буфер большего объема. Исключительно информативный статус, информирует функцию процесса о том, что заданный во входных параметрах функции буфер мал и следует его увеличить. В большинстве случаев не рассматривается как ключевая информация при анализе сбоев.
BUFFER OVERFLOW	ПЕРЕПОЛНЕНИЕ БУФЕРА	Буфер переполнен. Выделенный приложением буфер слишком мал для размещения запрашиваемых данных. Вызываемая функция сообщает вызывающей функции, что необходимо выделить буфер большего объема. Исключительно информативный статус, информирует функцию процесса о том, что следует увеличить буфер. В большинстве случаев не рассматривается как ключевая информация при анализе сбоев, но все еще продолжает пугать пользователей необоснованными подозрениями во взломе и прочей вредоносной активности:).
REPARSE	ПОВТОРНАЯ ОБРАБОТКА	Процесс запросил объект, ссылающийся на другой объект. Обычно возвращается при обнаружении ссылки.
NOT REPARSE POINT	НЕТ ПОВТОРНОЙ ОБРАБОТКИ	Запрашиваемый объект не ссылается на другой объект. Обычно возникает как ответ на передачу управляющего кода FSCTL_GET_REPARSE_POINT к драйверу файловой системы.
FAST IO DISALLOWED	БЫСТРЫЙ ВВОД-ВЫВОД ЗАПРЕЩЕН	Механизм FAST I/O не доступен для запрашиваемого объекта, то есть запрос ввода/вывода с использованием механизма FAST I/O к драйверу не поддерживается. В большинстве случаев не рассматривается как ключевая информация при анализе сбоев.
FILE LOCKED WITH ONLY READERS	ФАЙЛ ДОСТУПЕН ТОЛЬКО ДЛЯ ЧТЕНИЯ	Файл или проекция файла заблокирована. Файл доступен только для чтения. Диспетчер памяти обращается к файловой системе для захвата блокировки на время создания секции файла в памяти в процессе проецирования. Другими словами этот результат говорит о блокировке записи в файл на время создания секции файла и сейчас никто не имеет доступ на запись для данного файла. Таким образом диспетчер памяти может контролировать неизменность данных на время блокировки. Результат должен рассматриваться как информативный.
FILE LOCKED WITH WRITERS	ФАЙЛ ДОСТУПЕН ДЛЯ ЗАПИСИ	Файл или проекция файла заблокирована. Как минимум один пользователь может записывать в него данные.
IS DIRECTORY	ОБЪЕКТ ЯВЛЯЕТСЯ КАТАЛОГОМ	Запрашиваемый объект является каталогом (директорией).
INVALID DEVICE REQUEST	НЕДОПУСТИМЫЙ ЗАПРОС К УСТРОЙСТВУ	Данный запрос не является допустимым для целевого устройства.
INVALID PARAMETER	НЕВЕРНЫЙ ПАРАМЕТР	Службе или функции был передан неверный параметр.
NOT GRANTED	НЕ ПРЕДОСТАВЛЕНО	Запрашиваемая блокировка файла не может быть предоставлена из-за наличия других блокировок.
CANCELLED	ОТМЕНЕНО	Запрос ввода-вывода был отменен. Например, часто возвращается на вызов NotifyChangeDirectory при проверке каталога файловой системы на наличие изменений.
BAD NETWORK PATH	СЕТЕВОЙ ПУТЬ НЕ НАЙДЕН	Не найден сетевой путь.
BAD NETWORK NAME	СЕТЕВОЕ ИМЯ НЕ НАЙДЕНО	Указанное сетевое имя не обнаружено на удаленном хосте.
MEDIA WRITE PROTECTED	НОСИТЕЛЬ ЗАЩИЩЕН ОТ ЗАПИСИ	Запись на носитель не может быть произведена. Носитель защищен от записи.
KEY DELETED	РАЗДЕЛ УДАЛЕН	Попытка операции с разделом реестра, который был помечен для удаления.
NOT IMPLEMENTED	НЕ РЕАЛИЗОВАНО	Запрашиваемая операция не выполнена, так как не реализована в целевом объекте.
NO EAS ON FILE	НЕТ РАСШИРЕННЫХ АТРИБУТОВ	Больше расширенных атрибутов не найдено. Ошибка возникает в случае, когда пытаются запросить расширенные атрибуты у объекта, которых их не имеет.
OPLOCK NOT GRANTED	УСТУПАЮЩАЯ БЛОКИРОВКА НЕ ПРЕДОСТАВЛЕНА	Отказ в предоставлении уступающей блокировки. Уступающая блокировка (oplock, opportunistic lock) это блокировка, которая позволяет (сетевому) клиенту блокировать файл, расположенный на сервере, и локально (на стороне клиента) кешировать данные из файла, при этом исключая изменение файла другими клиентами. Уступающая блокировка связана с механизмом автономных файлов, позволяет снизить сетевой трафик и улучшить время ответа от сервера. Статус OPLOCK NOT GRANTED является ответом на передачу управляющего кода FSCTL_REQUEST_OPLOCK к драйверу файловой системы. Используется для диагностики проблемных объектов, криво работающих с сетевыми ресурсами.

* - цветом я попытался отметить те результаты, которые могут являться значимыми для поиска проблем, но всё достаточно условно и присутствие некоторых результатов может не указывать на ошибку, все требуется рассматривать в контексте происходящего и окружающих событий.
Вновь фиксируемые события добавляются в конец списка событий в хронологическом порядке, и, соответственно, если событий много, то они мгновенно выходят за границы активного окна. Таким образом, при базовых настройках интерфейса информация в окне остается статической и отражает только события, захваченные первыми, последние события пишутся в конец списка и об изменении общей его длины говорит лишь изменяющийся размер бокового курсора прокрутки. Однако подобное поведение программы можно изменить, включив автопрокрутку (Autoscroll) списка событий через включение соответствующей опции, либо посредством нажатия сочетания клавиш Ctrl + A . В этом случае список событий будет непрерывно скроллироваться вверх, показывая поступающие последними системные события в реальном режиме времени.

Панель инструментов

Поясним назначение кнопок, размещенных на панели инструментов интерфейса утилиты Process Monitor:

Слева направо:

Open - Загрузка сохраненных ранее событий (трассировок);
Save - Сохранение всех захваченных событий (трассировок);
Capture - Включение/Отключение захвата событий;
Autoscroll - Автопрокрутка событий в главном экране;
Clear - Очистка главного окна и всех захваченных событий;
Filter - Настройка фильтрации и подсветки событий;
Highlight - Настройка подсветки событий;
Include Process From Window - Настройка фильтрации событий по определенному окну на рабочем столе. Позволяет навести мишень на выбранное окно, Process Monitor сам определит принадлежность окна процессу и включить фильтрацию по данному процессу;
Show Process Tree - Дерево процессов;
Find - Поиск событий по заданным критериям;
Jump To Object - Переход к разделу реестра или файлу. Process Monitor анализирует содержимое столбца Path выделенной строки, запускает проводник/редактор реестра и открывает соответствующий элемент дерева;
Show Registry Activity - Переключатель состояния отображения событий активности реестра среди всех событий системы;
Show File System Activity - Переключатель состояния отображения событий активности файловой системы среди всех событий системы;
Show Network Activity - Переключатель состояния отображения событий активности сети среди всех событий системы;
Show Process and Thread Activity - Переключатель состояния отображения событий активности процессов/потоков среди всех событий системы;
Show Profiling Events - Переключатель состояния отображения событий профилирования среди всех событий системы. Профайлинг – события, записываемые утилитой Process Monitor для вычисления количества процессорного времени и объема памяти, используемого каждым процессом.

Горячие клавиши

Комбинация	Описание
Ctrl + E	активация/останов записи событий.
Ctrl + X	очистка журнала захваченных событий.
Ctrl + A	включение/отключение автопрокрутки событий.
Ctrl + F	поиск события среди всех захваченных событий.
Ctrl + C	копирование выделенного события в виде строки текста с разделителями.
Ctrl + J	перейти к выделенному объекту.
Ctrl + L	открытие окна настройки фильтров.
Ctrl + R	сброс фильтра в настройки по умолчанию.
Ctrl + H	открытие окна подсветки.
Ctrl + T	открытие дерева процессов.

Фильтрация событий

Как уже отмечалось, количество событий, происходящих (генерируемых различными компонентами) в системе, довольно велико. Число событий, которые "видит" Process Monitor меньше, но не намного. Возникает резонный вопрос, а все ли события нам необходимы? Ответ очевиден. Большинство событий, которые отображаются в главном окне программы совершенно излишни в контексте тех или иных узкоспециализированных пользовательских задач. Ну не нужно пользователю видеть события загрузки образа внезапно стартовавшей программы обновления, в то время как он занят изучением ключей реестра, хранящих конфигурацию интересующей его программы. Именно с целью скрыть ненужные события, у Process Monitor имеются гибкие и мощные средства фильтрации. Фильтр позволяет скрывать лишние события, тем самым ограничивая количество отображаемых элементов и сужая область поиска проблемы.

Фильтрацией можно скрыть событие, то есть выключить его отображение. Однако записываться будут все события, и Вы можете в любой момент посмотреть отфильтрованные (скрытые) события отключением (сбросом) фильтра.

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

Фильтрация по классу

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

Соответственно, в тот момент, когда какая-либо из перечисленных кнопок класса деактивируется (отжимается) пользователем на панели команд, в общий набор фильтров добавляется соответствующий фильтр с предписанием Exclude (Исключить), скрывающий из вывода все события данного класса.

Меню Filter

Какие бы из типов фильтров не применялись в Process Monitor, все они доступны через меню Filter и подпункт Filter. Это полный (общий) набор параметров фильтрации и представлен он в следующем виде:

Это же окно настроек фильтров может быть быстро вызвано и другими способами: нажатием комбинации клавиш Ctrl + L либо кликом по кнопке Filter на панели инструментов. Окно настроек фильтра предоставляет пользователю достаточно богатые возможности по маскированию событий системы. Окно Process Monitor Filter разделено условно на две части: в верхней представлены элементы интерфейса для добавления фильтра, в нижней присутствует список уже примененных к стандартному выводу фильтров. Фильтр добавляется методом прохода слева направо по всем атрибутам, которые, в свою очередь, представлены ниспадающими списками. Некоторые атрибуты между собой связаны, то есть выбор атрибута из одного списка может повлечь за собой автоматическое выставление значения в других списках. В некоторых полях можно производить редактирование значения. После завершения формирования, для добавления фильтра необходимо нажать кнопку Add , она производит добавление новых параметров фильтрации к фильтрам, представленным в нижней области окна.
Для редактирования правил выбранного фильтра, просто щелкните дважды по соответствующей строке, описывающей фильтр, в нижней части окна. Тем самым Вы переместите параметры в верхнюю часть (заполнятся соответствующие условия), где сможете их отредактировать и повторным нажатием кнопки Add завершить редактирование фильтра, вновь переместив его в нижнюю часть окна, к списку активных фильтров. Удалить фильтр можно кнопкой Remove . После окончания редактирования фильтров их можно ввести в действие (активировать) нажатием кнопки OK или Apply . Для восстановления настроек фильтров по умолчанию, в начальное состояние, которое присутствовало при первом запуске программы, нажмите кнопку Reset .
Как Вы могли заметить, по умолчанию в списке предопределенных фильтров имеется набор правил типа Exclude (Исключить). Эти правила служат для маскирования событий, которые, по мнению авторов, являются событиями активности тех компонентов операционной системы, которые, в большинстве сценариев, не несут полезной информации для устранения неполадок приложений. Здесь можно встретить исключения для: процессов утилит Procmon (Process Monitor), Procexp (Process Explorer), Autoruns, системных процессов, низкоуровневых запросов ввода-вывода драйверов Windows IRP_MJ, низкоуровневых операций FAST_IO, событий трассировки, событий файла подкачки pagefile.sys , событий работы диспетчера NTFS с метаданными.

Быстрый фильтр

Можно применить так называемый "быстрый фильтр" для некоторых параметров событий, отображаемых в главном окне. Активируется он нажатием правой кнопки мыши на событии в главном окне программы:

В открывшемся контекстном меню Вы можете видеть сразу несколько различных способов фильтрации. В зависимости от того, на значение какого столбца в строке была нажата правая клавиша мыши, мы можем исключать или включать из всего массива вывода события, у которых имеется совпадение по значению столбца. Выполняется это выбором соответствующего пункта, начинающегося с Include ... (Включить) и Exclude ... (Исключить). В контекстном меню присутствуют так же пункты Edit Filter ... , Exclude Events Before , Exclude Events After .

Фильтрация по владельцу окна

В дополнение к основным вариантам фильтрации, в утилите Procmon имеется возможность отфильтровать события по описателю (идентификатору) окна приложения. Это достаточно удобная функциональная особенность, поскольку она предоставляет пользователю возможность посмотреть события процесса, окно которого появляется на рабочем столе. Для задействования данного функционала на панели инструментов найдите значок прицела:

Перетащите его на интересующее Вас окно и Procmon создаст соответствующий фильтр на процесс, являющееся владельцем выбранного окна, соответственно изменив вывод в главном окне.

Подсветка событий

В дополнение к фильтрам, в Procmon присутствует возможность маркировать события, выделяя их цветом. Тогда как фильтрация скрывает лишние события из вывода, то подсветка просто-напросто выделяет необходимые события в списке. Напрямую, вроде как, не относится к фильтрам, поскольку не скрывает события, а всего-лишь маркирует их другим цветом в списке. Вызвать окно настройки подсветки Process Monitor можно либо нажатием комбинации клавиш Ctrl + H или щелчком по соответствующему значку на панели задач. Выглядит оно следующим образом:

Как Вы видите, оно идентично окну настройки фильтров, за исключением того, что по умолчанию не имеет никаких установок, то есть подсветка полностью отключена. Алгоритм настройки параметров подсветки и выборки результатов окна Highlighting во многом схожи с аналогичными в окне Filter.

Поиск по событиям

Фильтрация результатов это превосходно! Фильтр позволяет нам гибко манипулировать выборкой из общего потока событий, однако, в большинстве случаев достаточно сложно сформировать условия, при которых диапазон отфильтровываемых событий сужался бы до какого-то приемлемого минимума. Результатов все-равно бывает много, да и в области отфильтрованных строк иногда требуется найти внезапно обнаруженную константу. Иногда бывает полезным найти какое-либо ключевое слово во всем объеме захваченной информации без понимания, в каком именно столбце оно может располагаться, поэтому создание фильтра оказывается проблематичным. Эти и многие другие рабочие моменты говорят в пользу использования традиционного, хорошо знакомого всем с детства поиска. Вызывается окно поиска комбинацией клавиш Ctrl + F или проходом по меню Edit - Find:

Будет отображено уже знакомое по другим продуктам Microsoft окно поиска. Поиск осуществляется по значениям всех без исключения полей вывода главного окна Process Monitor и при обнаружении первого попавшегося совпадения, утилита пролистывает экран до найденного значения и маркирует целиком всю строку с обнаруженным ключевым фрагментом синим цветом.

Детали событий

Process Monitor получает от различных компонентов операционной системы достаточно большое количество дополнительной информации. Все они отображаются в столбце Detail. Большинство из них чисто информативные, поэтому обычно пропускаются при анализе. Тут можно встретить запрашиваемый уровень доступа для операции, подробности запросов функций, дополнительные параметры некоторых функций, имена пакетов драйверов и прочее

Изучение события

Вся информация, коллекционируемая утилитой Process Monitor в процессе записи событий, представляется в виде огромной таблицы, каждая строка которой отражает лишь обобщенное описание определенного произошедшего события. Ну и что, как Вы думаете, достаточно ли этой информации, представленной в главном экране утилиты в виде ограниченных сведений, разнесенных на несколько колонок? Иногда да, но зачастую и нет! Надо отдать должное авторам Process Monitor"a за то, что они предусмотрели логику более детального исследования записываемых событий. Давайте выполним двойной щелчок на строке события, и посмотрим что же произойдет? После выполнения двойного щелчка открывается отдельное окно, имеющее следующий вид:

Во вкладке Event (Событие), мы видим общую информацию об интересующем нас событии. В общем то, именно эта вкладка не представляет для исследователя большой ценности, поскольку содержит информацию, которую можно получить в интерфейсе утилиты другими способами. Но вот две оставшиеся вкладки окна определенно могут нас заинтересовать. Средняя вкладка называется Process (Процесс) и выглядит следующим образом:

Тут мы видим путь к модулю (Path), командную строку, с использованием которой был запущен модуль (Command Line), пользователя, с привилегиями которого процесс был запущен (User), идентификатор сессии входа в систему (Auth ID), в которой процесс, хозяин операции, выполняется, и уровень целостности (Integrity), присвоенный процессу, хозяину операции, при запуске. Отдельного внимания удостаивается информационное окно со списком библиотек, загруженных в (Modules), которое сильно способствует выявлять непрошенных гостей в виде различного рода вредоносов. Но для продвинутых исследователей настоящей ценностью является последняя, самая правая вкладка Stack (Стек), которая позволяет увидеть стек вызовов основного потока процесса:

Как мы видим, в этой вкладке можно обнаружить хорошо знакомую нам по отладчику WinDbg, классическую цепочку вызовов функций, называемую стеком вызовов. Во-первых, она позволяет отследить последовательность вызовов функций с момента начала выполнения стартовой функции потока. Во-вторых, по последовательности вызовов функций можно определить к каким модулям (библиотекам) эти функции принадлежат, тем самым выявив и системные компоненты, которые либо требуют обновления, либо вообще не должны применяться в данном модуле (например: вирусы).

Сценарии использования

Некоторые замечания по статусам программы Process Monitor:

Событие, в поле операции которого стоит Load Image (Загрузка образа) помогает при диагностике проблем запуска программы. Если программа по каким то причинам не запускается, то ищем в общем списке событие с операцией Load Image и смотрим списки DLL, которые загружаются (описаны своими событиями) непосредственно за событием загрузки образа. Если вспомнить алгоритм загрузки образа, то мы поймем, что обычно за операцией Load Image следуют события поиска необходимых DLL библиотек. Дело в том, что загрузчик Windows готовит адресное пространство процесса, проецируя в него все необходимые программе библиотеки и производя неявное связывание на начальном этапе. Если в какой то из необходимых основной программе библиотек DLL произошла ошибка загрузки её образа, то очевидно, что загрузчик Windows не сможет запустить и основную программу. Событие загрузки образа фиксируется со статусом "отказано в доступе" (ACCESS DENIED);
Статусы, на которые стоит обращать внимание в первую очередь: ACCESS DENIED, SHARING VIOLATION, NAME NOT FOUND (с последним имеются исключения). Статус NAME NOT FOUND в большинстве случаев достаточно типовой статус завершения, не стоит так уж прям преувеличивать его значимость и считать виновником всех бед. Зачастую статус высвечивается в случае, когда приложение проверяет наличие файла или ключа реестра (содержащих конфигурацию программы), и по результатам этой проверки выполняет тот или иной код, то есть производит логическое ветвление в зависимости от результата запроса. Программа может и не найти ключ реестра, содержащий собственную конфигурации, и в таких случаях мы увидим все тот же статус NAME NOT FOUND. Одним словом, статус NAME NOT FOUND должен рассматриваться в контексте приведшего к нему события.
Для определения виновника чрезмерной нагрузки на дисковую подсистему: запускаем Procmon, создаем фильтр с настройками Path - begin with - C:\ (хотя тут может быть указан любой интересующий логический диск) и нажимаем OK . Затем, после непродолжительного сбора данных (~одна минута) идем в меню Tools и выбираем пункт Process Activity Summary . В открывшемся окне сортируем по колонке File Events и получаем в вверху списка имена процессов, активно работающих с файловой системой. Затем, чтобы узнать какие именно файлы участвуют в интенсивном обмене данными, можно выбрать меню Tools и пункт File Summary , и в открывшемся окне наблюдать список файлов, задействованных в дисковых операциях. Вывод автоматически сортируется по колонке Total Events , поэтому в верхней части списка мы наблюдаем наиболее интенсивно используемые в операциях дискового ввода-вывода файлы.

Диагностика этапа загрузки

Довольно часто встречаются ситуации, когда проблемы у операционной системы начинаются задолго до прорисовки интерфейса пользователя, уже на этапах загрузки. Для диагностирования подобных сбоев в сети имеется некоторое количество специализированного инструментария, такого например, как . Удачно вписывается в этот ряд и утилита Process Monitor. Procmon записывает события всех исполняющихся на стадиях загрузки процессов, с помощью драйвера этапа загрузки под названием procmon23.sys (имя может меняться от версии к версии), который был описан в начале статьи. К сожалению, драйвер стартует на этапе работы модуля Winload.exe, что препятствует фиксированию более раннего этапа Bootmgr, однако, в большинстве случаев, на эту мелочь можно закрыть глаза. Включение логирования процесса загрузки активируется через опцию Enable Boot Logging меню Options .

В дополнение к активации механизма, Procmon предлагает включить профилирование потоков через равные промежутки времени. Это немаловажно, потому что в большинстве случаев проблемы загрузки связаны с медленной работой определенных процессов. Именно с целью отследить подобные "тормозящие" процессы включается профилирование, которое позволяет создавать эдакие снимки активности потоков внутри процесса (стек вызовов и прочие данные) через равные промежутки времени. В итоге, записываемая информация помогает понять на какие именно операции поток тратит процессорное время.
После включения опции Enable Boot Logging можно перезагружать операционную систему. После завершения загрузки запускаем утилиту Process Monitor для сохранения лог-файлов процесса загрузки и видим следующее диалоговое окно:

В котором нам предлагается сохранить события процесса загрузки в отдельный лог-файл с расширением .pml . В зависимости от объема информации, лог-файл может быть сохранен как в едином файле, так и разбит на серию файлов примерно равного размера.

Объем информации, записываемой драйвером Process Monitor на стадиях загрузки, для "средненабитой" :) операционной системы Windows 7 SP1 x64, достаточно велик. Типичный размер со включенным профилированием потоков может превышать 1500 мегабайт.

После сохранения лог-файлов активности этапа загрузки, впоследствии можно будет проанализировать их, открыв в программе Process Monitor либо двойным щелчком по.pml-файлу, либо открыв его непосредственно через меню File - Open . Тем не менее тут есть один нюанс, если файл или набор файлов журнала процесса загрузки слишком большой, и утилита не может найти достаточного пространства в файле подкачки либо виртуальном пространстве процесса для создания буфера, то выдается ошибка "Unable to open Bootlog.pml for reading .. ". Я лично решил её временным включением файла подкачки, который у меня, традиционно, отключен вообще.

Process Explorer и Process Monitor - два из трёх очень полезных инструментов для тонкой настройки операционных систем Windows.

Если вы хотите знать, что прямо сейчас происходит на вашем компьютере, попробуйте Process Explorer. В своей основе Process Explorer - более сложная версия диспетчера задач Windows 10.

В нем, в реальном времени, отображается информация о запущенных процессах, включая какая учётная запись является владельцем определённого процесса. Какие файлы, ключи реестра и другие объекты этот процесс открыли. И какие библиотеки DLL этим процессом были загружены. А также, программа Process Explorer, обеспечивает моментальный снимок производительности системы и использования её ресурсов.

Вы предпочитаете загруженный, но информативный дисплей Process Explorer, более чистому, но почти пустому диспетчеру задач? Пожалуйста, для этого имеется свой параметр. А именно, в программе Process Explorer, выберите меню "Параметры" и затем "Заменить диспетчер задач" (для внесения этого изменения вам потребуются учётные данные администратора). После этого, нажатие клавиш Ctrl+Shift+Esc, вместо , откроет инструмент Sysinternals.

На примере ниже чётко видно, что Process Explorer очень активен. Для идентификации каждого процесса по типу, он использует цветовое кодирование, а для привлечения внимания к начинающимся и заканчивающимся процессам - анимацию.

Вид группировки по умолчанию в Process Explorer обрабатывает процессы родитель-потомок и использует цветовое кодирование для выявления различных типов процессов.

Цветовое кодирование, вы можете настроить самостоятельно. Для этого, нажмите "Опции" и выберите "Настройка цветов".

Параметры по умолчанию следующие:

 Зелёный цвет указывает на новые объекты, а насыщенный красный - момент удаления объектов. Оба этих цвета появляются на короткое время, в момент начала и окончания процесса.

 Светло-голубой - определяет «собственные процессы», те, что работают под той же учётной записью, что и Process Explorer. Обратите внимание, что эти процессы могут выполняться в другом контексте безопасности чем учётная запись пользователя, под которой они были запущены.

 Розовый цвет - выделяет процессы, которые содержат одну или более служб Windows. Когда вы наводите курсор на одну из этих строк, появляется подсказка, отображающая имена работающих в этом процессе отдельных служб. Что может быть полезным для определения какой экземпляр Svchost.exe за это отвечает.

 Фиолетовый (или тёмно-фиолетовый) - означает «Упакованные» (зашифрованные или сжатые) исполняемые программы. Это может означать потенциально вредоносные программы, особенно, если они связаны с неизвестным процессом.

 Бирюзовый - показывает иммерсивные процессы, которые связаны с приложениями Магазина Windows.

 Тёмно-серый - идентифицирует приостановленный процесс. Обычно это приложения Windows Store, которые вы ранее открыли, но уже не используете. Некоторые приложения Магазина Windows специально написаны так, что могут продолжать выполняться в фоновом режиме. Например, Groove Music будет продолжать проигрывать мелодии даже при переключении фокуса в другую программу.

Вы можете идентифицировать работу Windows и.NET процессов по их цветовому кодированию, хотя эти атрибуты, по умолчанию, параметры не отображают.

Маленькие графики, в верхней части окна Process Explorer, отображают системную информацию в режиме реального времени. Чтобы увидеть все графики в одном окне, нажмите Ctrl+I (как в информации) или, в строке меню, щёлкните "Вид" и выберите пункт "Сведения о системе". Ниже этот дисплей в действии.

Окно сведений о системе показывает графики производительности для текущей системы в режиме реального времени. А также, при наведении курсора на определённое место, детальные подсказки.

Внимание . Если вы не видите все графики, перезапустите Process Explorer от имени администратора.

Каждая из отдельных вкладок - CPU, Memory, I/O и GPU - содержит дополнительные сведения об этой конкретной группе ресурсов. В частности, на вкладке GPU, добавлены детали, которые вы не найдёте на вкладке "Производительность" диспетчера задач.

Реальная сила Process Explorer становится очевидной, когда вы, чтобы раскрыть меню доступных параметров, щёлкните правой кнопкой мыши на отдельном процессе.

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

Детали для запущенного процесса включают информацию о версии и запускается ли он автоматически.

Из этого диалогового окна "Свойства" или из списка процессов, вы можете отправить хэш-код этого файла в службу VirusTotal. Где на любом из отслеживаемых VirusTotal 50 с лишним антивирусов выяснить, не является ли он возможной вредоносной программой.

Нижняя панель окна Process Explorer обычно скрыта. С помощью сочетания клавиш Ctrl+L, вы можете сделать её видимой (или, в меню "Вид" выберите "Показать нижнюю панель"). Эта панель показывает одно из двух представлений для текущего процесса: или дескрипторы. Вы можете переключаться между двумя представлениями с помощью сочетаний клавиш Ctrl+D и соответственно Ctrl+H На рисунке ниже нижняя панель в представлении библиотеки DLL.

Нижняя панель может отображать связанный с выбранным процессом список библиотек DLL или список дескрипторов.

Process Monitor

Последний из трёх суперзвезд Sysinternals это монитор процессов, также известный как Procmon. При запуске, он в режиме реального времени отслеживает все, связанные с файловой системой, реестром, сетью, процессами, потоками и библиотеками DLL, действия.

Procmon, в считанные секунды, трассирует миллионы различных операций. Которые, для устранения помех, затем можно отфильтровать и сосредоточиться на потенциальной причине проблемы. Вы можете сравнительно легко захватить следы повышенной активности системы и сохранить их в файлах журнала Procmon. А затем проанализировать захваченные данные на другой системе.
Чтобы получить представление о степени захваченной Procmon детализации, смотрите листинг на рисунке ниже, который представляет активность системы за период, измеряемый в небольших долях секунды.

Во время трассировки, Process Monitor записывает все события каждого процесса, что, как показано в строке состояния, может привести к миллионам дискретных событий.

Хотя Procmon собирает все, что он отслеживает, параметры по умолчанию включают фильтр, который скрывает необработанные детали из файловой системы и самого Procmon. Можно настроить фильтр на лету. Просто щёлкните правой кнопкой на конкретной записи в определённом столбце, а затем в контекстном меню, выберите один из вариантов.

К примеру, на рисунке показан щелчок правой кнопкой мыши на строке Runtimebroker.exe в столбце имя процесса. Теперь можно выбрать, включить этот процесс в текущий фильтр, эффективно отображающий записи из этого процесса или исключить его, так чтобы скрыть результаты сопоставления. А также можно выбрать для выделения совпадающие записи, не скрывая те, которые не совпадают.

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

Посмотрите на строку состояния в нижней части окна Procmon, чтобы увидеть был ли к записанным данным применён фильтр и, если да, какое влияние он имел. Например на рисунке, отфильтрованный список показывает меньше, чем 1 из 1000 событий, что позволяет прокрутку данных или дальнейшее фильтрование в поисках паттернов или .

Посмотрите в строке состояния, нижней части окна Process Monitor насколько эффективен ваш фильтр.

А также можно создать или изменить фильтр, используя диалоговое окно Process Monitor "Фильтр", которое предлагает удобное его использование. Для доступа к диалоговому окну "Фильтр", на панели меню монитора процессов, нажмите соответствующую кнопку. Вы можете задать условия, которые определяют какие события будут включены или исключены. Потом нажмите кнопку "Добавить" или выберите существующий фильтр и нажмите кнопку "Удалить". Чтобы немедленно увидеть эффект от нового фильтра, нажмите кнопку "Применить".

Нажатие кнопки «Фильтр» открывает диалоговое окно фильтра Process Monitor, где, с помощью раскрывающихся списков, вы можете добавить критерии. Перед выходом не забудьте нажать кнопку "Применить".

(ProcMon) от Sysinternals.

Недавно рассказывал одному юному падавану как пользоваться этим замечательным, а в некоторых случаях незаменимым инструментом. И пока рассказывал пришла в голову мысль написать такую вводную инструкцию для тех, кто только начинает свой тернистый путь админа.

Вообще, по моему мнению всё, что касается ProcMon лучше всего описано в книге от разработчиков, которая так и называется “Утилиты Sysinternals. Справочник администратора ”.

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

Запуск ProcMon

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

Ну как? Понятно? 🙂

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

Чаще всего ProcMon запускается с конкретной целью, например, определить, что делает та, или иная программа, какой процесс пишет файлы в определённый каталог или ветвь реестра, куда девается место на диске, и т.д. Поэтому, если просто запусить ProcMon то придётся остановить сбор событий (Ctrl+E ), очистить уже собранные события (Ctrl+X ), настроить фильтры (Ctrl+L ), и снова запустить наблюдение. Для того, чтобы не делать столько лишний движений предусмотрен параметр командной строки /noconnect :

procmon /noconnect

Запуск с этим параметром запускает Procmon, но не начинает наблюдение, вместо этого сразу же открывается окно фильтров.

Вообще для упрощения запуска, я делаю (и всем советую делать так) как описывается всё в той же книге:

Мой соавтор Аарон обычно создает папку C:\Program Files\Sysinternals и распаковывает в нее содержимое пакета Sysinternals Suite. Там утилиты невозможно изменить без прав администратора. Затем он добавляет этот каталог в системную переменную окружения Path, что позволяет легко запускать утилиты откуда угодно, в том числе через меню Start | Run (Пуск | Выполнить ).

Фильтры в ProcMon

Как было сказано выше окно фильтров открывается при запуске с параметром /noconnect . Если вы его нечаянно закрыли, или нужно подправить уже настроенные фильтры, открыть окно фильтров можно сочетанием клавиш Ctrl+L , или через меню Filter | Filter… .

Вот мы и добрались до практики 🙂

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

Итак, у нас открыто окно фильтров.

Фильтры в ProcMon

На всякий случай нажимаем кнопку сброса фильтров в состояние по умолчанию – Reset (по умолчанию в ProcMon настроено до фига фильтров, не рекомендуется их удалять) и добавляем фильтр

Process Name is notepad.exe include .

Нажимаем кнопку Add . Как можно понять из названия захватываться будут только события, связанные с процессом notepad.exe, т.е. те события, которые генерирует блокнот.

Важный момент: имя процесса должно быть указано полностью – с расширением, иначе ProcMon ничего не захватит. Как вариант можно использовать фильтр

Process Name begins with notepad include

В таком случае будут захвачены события, связанные с процессами, начинающимися на notepad, это может быть как стандартный блокнот, так и Notepad++ , или какой-нибудь ещё блокнот. Таким же образом добавляем фильтр на запись файлов:

Operation is WriteFile include

Нажимаем Add иOK (вообще можно просто нажать OK , в таком случае ProcMon скажет, что такого фильтра ещё нет, и спросит хотим-ли мы его добавить. Дело в том, что нажатие кнопки закрывает OK окно фильтров, если это не единственный фильтр, то лучше нажать кнопку Add , это позволит добавить фильтр, и оставить окно фильтров открытым для последующих фильтров).

Так как нас интересует только файловая активность, в главном окне ProcMon отключаем значки наблюдения за реестром, сетью и процессами – оставляем только наблюдение за файловой системой (выделены на скриншоте ниже).

Ещё один важный момент.

По умолчанию ProcMon регистрирует всю активность системы, даже те события, которые не попадают под фильтры, что в некоторых случаях может приводить к подтормаживанию работы. Если вы уверены в том, что фильтры настроены правильно (в данном примере мы уверены), и вам не нужны события, скрытые ими – их можно отбросить при помощи опции Filter | Drop Filtered Events (Удаление отфильтрованных событий) в меню Filter . Данный параметр действует только на регистрацию текущих событий, ранее записанные события из журнала не удаляются.

После того как фильтры настроены запускаем сбор событий (кнопка с изображением лупы, или Ctrl+E ). Запускаем блокнот, пишем какой-то текст и сохраняем файл. Смотрим, что получилось:

Файловая активность в ProcMon

Как видно из скриношота ProcMon зафиксировал событие записи файла процессом notepad.exe по пути C:\temp\test.txt .

Проведём ещё один эксперимент.

Остановим захват событий (Ctrl+E ), закроем блокнот и очистим собранные события (Ctrl+X ). Вызовем окно фильтов (Ctrl+L ), сбросим фильтры (кнопкой Reset ) и добавим следующий фильтр:

Path begins with c:\temp\

Этим самым мы указываем, что нас интересует любая активность по пути C:\temp . А так как значение указано не точно (не is , а begins with ), то захватываться будут события не только из этого каталога, но и из всех его подкаталогов.

Проверьте, чтобы было включено наблюдение только за файловой системой (при сбросе фильтров всё сбрасывается в состояние по умолчанию)

Фильтры в ProcMon

Запустим наблюдение. Откроем проводник и перейдём по нашему пути. Заглянем в ProcMon.

Так выглядит открытие каталога в ProcMon

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

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

Для того, чтобы увидеть сами события чтения файла, остановите сбор событий, очистите окно результатов, добавьте фильтр