How to identify reasons for slow Windows startup using Process Monitor.

Someone may have already read it and been using it for a long time, and someone may not even have heard of it, so I want to tell you about it again, especially since I haven’t been sitting idle for a year and a half. This is an automatic torrent tracker tracking system that automates the process of downloading torrent files.

The most important thing for such a system is to expand the number of supported trackers, not at the expense of quality, of course. During this time, the number of supported trackers has doubled. In fact, it takes several hours to add support for the next tracker, unless it uses some kind of very abstruse engine or is too inconvenient for parsing (this mainly relates to the naming of distribution topics, for example, it was not possible to add animereactor.ru, due to lack of a standard for naming distributions). Now the list of supported trackers looks like this:

• anidub.com
• baibako.tv
• casstudio.tv
• cinemazal.tv
• lostfilm.tv
• newstudio.tv
• nnm-club.me
• novafilm.tv
• rutor.org
• rutracker.org
• tfile.me

Here I will tell you a little more about how it works, because it is a common question. Many people add a series to monitoring on lostfilm.tv and expect that something should happen right away, but this is not the case. The monitor will react to this series only when it appears in the RSS feed, but if you add a topic from rutracker.org, the torrrent file will be downloaded immediately after the first start of the system, and the next time, only when the torrrent file is re-uploaded on the tracker .

Form trackers also have the ability to monitor releasers


In my opinion, this is also convenient and useful when the tracker has a releaser that uploads music in your favorite style, for example.

The second main innovation was, finally, support for torrent clients, which allows you to transfer a torrent file directly to the client that downloads it, and at the same time can delete the previous distribution from the client (no matter what type of distribution, “formula” or “single” ). TM is “friendly” with Transmission and Deluge, because These are the most popular clients among my users and they were asked to “screw them up.” This was perhaps the biggest expansion of functionality during this time. But, unfortunately, there are limitations here - this only works on *nix, because the work is done through the console of these clients.


Also, due to the blocking of some trackers by home providers, there was a strong request to add the ability to work through a proxy, which was also implemented and now the system can be wrapped in tor (it will have to be installed and configured, of course, separately). And the class that works with the database has become universal and supports: MySQL, SQLite, PostgreSQL.

Surprisingly, TM has become quite popular, I see that it is installed not only on machines with Windows/Linux/Mac OS on which it naturally works fine, but also on various “boxed” Linux-based devices: zyxel keenetic, various NASs, as well as on nas4free.

I hope this post and my small development will seem useful to someone, and even if only one person starts using it after reading it, that will be enough for me.

In general, I am extremely interested in developing the project further, I will be extremely interested in working with programmers to improve the system or add new functionality to it, add new torrent trackers for work and learn something new for myself. For this reason, I invite everyone to github.

And most importantly, a link to latest version 0.9.2 Well, how to deploy and test the system is described in the readme file in the archive.

And here I will hide the remaining screenshots :)

Expand:

• download the archive
• import a database dump from the db_schema directory depending on the database used - *.sql
• transfer all files to a folder on your server (for example /var/www/htdocs/torrentmonitor/)
• edit config.php and specify data for accessing the database
• go to the web interface (the default password is torrentmonitor, change(!) it after the first login).
• specify credentials from trackers
• specify in the settings the path for saving torrents (the folder that is monitored by your torrent client), e-mail and enable/disable sending notifications
• adding torrents for monitoring
• go to the “test” tab and check if everything is working correctly
• add to cron engine.php

And a few words for the paranoid: Passwords for your accounts are stored in your database, nothing is sent to me. For own peace of mind you can close any activity on my domain, except for the file korphome.ru/torrent_monitor/version.xml, it is needed to check for updates (but if you’re really paranoid, you don’t have to check for updates).

I'd love to hear your thoughts on the topic further development project and interesting functionality.

By Process program Monitor has already been given quite a lot of material, and learning the basics of the utility’s functioning has always been accessible even to an untrained user. But still, I personally didn’t quite understand many aspects of the work (and I still don’t understand some :), so I decided to write another note about this very useful utility, so that you can later use the article as a kind of hint. If we consider any operating system from the point of view of generalization, then we can conditionally differentiate it into blocks of code/data that interact with each other based on certain patterns. To get closer to the terms we are familiar with, we will consider the mentioned block a process that combines both code and data, intended to solve a specific problem. Thus, the interaction between such processes constitutes (with some exceptions) the concept of the functioning of the operating system. While the operating system is running, it runs large number processes and the purpose of any of these processes can vary over a fairly wide range.

Each process in the operating system, by the totality of its own operations and the results of their execution, actually determines the fingerprint of the system’s activity at one time or another. But, as we know from theory, the processes themselves are just containers for threads (threads), which directly do all the computational work. It is clear that threads are code, a set of machine instructions executed by the processor, but this is at a fairly low level of perception. If we operate with Windows structures, then threads still contain machine code, but all the functionality of the operating system is available through access to functions of various system libraries and driver calls, so threads, in addition to simple arithmetic and logical operations, interact with various Windows subsystems: virtual memory , file system, registry, hardware components and many others. Interprocess communication is so intensive that at any given time thousands of such operations are performed in the system. Accordingly, in the realities of Windows, it would be interesting for us to observe the interaction of processes with certain components of the operating system at the level of functions and the results of their execution, since this level of activity is quite sufficient to solve most problems. Such information would be extremely useful to us both from the point of view of purely research interest in the study of algorithms, and from the point of view of finding solutions to certain problems that arise in the process of work. But we will need a tool that can provide such detailed information, because we need to dive into interprocess communication much deeper than the level of built-in tools, to understand what exactly the processes are doing. Something similar is provided to us by a tool called Process Monitor, which belongs to the class of tools with extended functionality, will be the topic of our today's article.
Process Monitor- a program for monitoring process activity in the operating system, which, in operation logging mode, allows you to monitor the activity of processes in relation to such OS subsystems as the file system, registry, and network. Allows you to estimate the amount of CPU time spent executing threads within processes.
Process Monitor provides real-time monitoring for the following classes of events:

• File system: creating (opening)/closing/reading/writing/deleting file system elements: files, directories, attributes, content.
• Registry: creating/reading/writing/enumerating/deleting registry elements: branches, keys, values.
• Network: establishing a connection, transferring data, closing a connection. Information about the source/receiver of TCP/UDP traffic. General information about protocols and packages. The transmitted data itself is not recorded.
• Process/thread: Create a process, create a thread within a process, terminate a thread/process. detailed information about the process (path, command line, user/session ID), startup/termination, loading images (libraries/drivers), execution stack.
• Profiling: A special class of events recorded for the purpose of tracking the amount of CPU time spent by each process. Process memory usage.

The main, most likely scenarios for using Process Monitor immediately come to mind:

• In which registry keys does this or that program store its settings?
• What operations does the process perform at startup, during operation, and at the closing stage?
• Who owns these or those files? How often does the owner contact them?
• Which process accesses external network nodes?
• What process slows down the loading of the operating system?

Process Monitor allows you to get an answer to the question: what actions are performed by a particular process in the system.

But, unlike tools like Process Exploer, this is not a real-time utility that allows you to interact with processes on the fly, close handles, kill processes and perform other similar actions; it is rather a global log consisting of events occurring in the operating system. The key word in the previous sentence was “detailed”, because this does not mean the events that we are used to seeing, for example, in the Event Log, but lower-level ones that occur on a given set of API functions of some OS components. These, as well as some other, unique functional features make the Process Monitor program practically an indispensable tool to troubleshoot problems and determine the causes of suspicious activity in the system.
But don’t rush to be enchanted, because for every barrel of honey there is always its own fly in the ointment. So in the case of Process Monitor, there are some “nuances”. You should not consider Process Monitor as a kind of magic wand for all occasions, since it does not “see” everything. For example, it will not track the movement of the mouse pointer, dragging of windows, will not show the contents of network traffic packets, will not show the whole variety of functions called by the program, and this is far from full list those things that Process Monitor cannot do. As in any case of diagnosing operating system problems, such tools provide, roughly speaking, limited set functions and operations of the flow, leaving a field for activity and requiring the specialist to make independent conclusions and sometimes quite deep knowledge, which form the basis of any analysis. I don’t presume to say that absolutely all problems diagnosed using Process Monitor require a high level of knowledge of the OS architecture, but this is not such a rare occurrence. An example from the wild: I once encountered a bug with Outlook 2010, when compatibility options were set in the properties of the outlook.exe program, which prevented the program from starting with the starting error “It is impossible to open the default mail folders. The message bank cannot be opened.” . You can track this problem using the Process Monitor utility, but you need to know what exactly to look for in the huge stack of messages from the Outlook process. For that case, we had to look for the WINSRV08SP1 and RUNASADMIN flags when reading the AppCompatFlags key, which in itself suggests that sometimes we need to imagine what we want to find. Ideally (and the ideal is unattainable), it would be nice to imagine exactly how the profile of a program loaded in compatibility mode changes at the level of generated events in relation to a typical application load. Ultimately, it was necessary to understand why exactly mail client Failed to load user configuration. Of course, perhaps this particular example is not so indicative, because it is quite complicated, and it would be more reasonable to use other means, I just want to draw your attention to the fact that Process Monitor is not a debugger, and it cannot catch the place where the window display function is called with an error, will not be able to penetrate the logic of the operation of one or another internal function, will not show the state of registers, memory areas and other structures important for the process. Sometimes there is no visible result about the lack of access, so sometimes the collected information implicitly contains a description of the problem and you need to think more about the results obtained by Process Monitor. Occasionally, there are cases where the functionality of Process Monitor is simply not enough to get to the bottom of the problem, but this does not in any way detract from the merits of this instrument, because in most cases it allows you to get to the cause of the bug quite quickly. Well, you won’t immediately take to the debugger for every error and spend hours flying around trying to study the algorithm of the faulty module? .. Although:)
The Process Monitor utility includes the capabilities of earlier Sysinternals programs: the registry monitoring program Regmon and the file system monitoring program Filemon, which have long since disappeared. In addition, Process Monitor can save the entire event log to a file weighing up to 1 gigabyte.

How does this work

While monitoring the activity of Process Monitor, an interesting feature was identified: it turns out that the program uses its own kernel mode driver (what about the signature? But the signature is from Symantec). On a 32-bit system, Process Monitor uses a 32-bit filter driver called procmon23.sys both during the execution of the directly executable image and at the operating system boot stage (when the Enable Boot Logging option is enabled). But besides the executable image procmon.exe itself, there are no other images in the application’s working directory. binary files? The fact is that the driver is packaged in the body of the main executable module procmon.exe. Using any tool for working with PE file resources, you can verify that the procmon23.sys driver is contained inside the executable file in the RCDRIVERNT resource of the BINRES directory of the resource section, that is, it is part of the main file:

On a 64-bit system, Process Monitor unpacks %TEMP% into a temporary directory when launched. hidden file named Procmon64.exe. The procmon64.exe image is contained in resource 1308 of the BINRES directory inside the resource section of the main procmon.exe file. But in Procmon64.exe itself, the BINRES section of the resource section contains a 64-bit driver that is used during operation.

The procmon23.sys driver can also work as a boot mode driver. When the user activates the Enable Boot Logging option, Process Monitor copies the driver to the %SystemRoot%\System32\Drivers folder and writes it to the registry key HKLM\SYSTEM\CurrentControlSet\Services with the Start parameter value = 0, which indicates that the driver will be loaded at the Winload.exe execution stage when the operating system boots.

It appears that all events monitored by Process Monitor pass through this filter driver. In addition to this, Process Monitor uses technology Event traces(ETW, Event Tracing for Windows), at least for monitoring events network activity. It is not entirely clear yet whether the same driver is used as a controller and receiver for ETW or the executable module itself? Let me remind you that ETW is a kind of extensible logging system built into the Windows system, implemented at the kernel level and allowing (on request) to collect events from user-mode applications and kernel-mode modules. And as we know, almost all components of the operating system include the ability to track ongoing operations. It is clear that the ETW functionality is much broader; it provides extensive information on operation: context switching, interrupt statistics, deferred procedure calls (DPC), interrupt service routines (ISR), creation and destruction of processes and threads, disk I/O, errors pages, processor transitions between p-state modes, registry operations, and much more.

Interface

Before starting, it would be a good idea to obtain the executable module of the utility. You can download Process Monitor from here. The utility is distributed as a portable application and does not require installation, but can simply be extracted from archive file to an arbitrary directory, which is extremely useful when diagnosing from portable media and when integrating into a preinstallation environment (WinPE).

Because Process Monitor uses its own driver, it requires local administrator rights to run.

If Process Monitor is launched with filters installed in previous work sessions, the program opens the filter settings window (Filter). This is done so that the user can, if desired, modify the filters before starting the data collection procedure.
The Process Monitor interface is extremely simple and looks like this by default:

Agree, everything ingenious is really simple. The simplicity of the interface makes it intuitive to perceive what is happening in the system. Immediately after launching Process Monitor, it immediately begins to capture events occurring in the operating system, monitoring key components such as: file system, registry, network, process/thread activity. After capture, events that do not fall under the filter are displayed in chronological order to the main application window. Moreover, the user observes such a huge amount of data, which can easily be discouraged at first; all this ton of data instantly fills the main program window and rushes beyond its limits, as eloquently evidenced by the rapidly decreasing side scroll slider. Each line output in this way represents an event that occurred in the system, was visible and captured by the Process Monitor driver, and was not subject to filtering rules. The main body of information is formatted in the form of a table; accordingly, each row is divided into a number of columns, the composition and arrangement of which can be changed through the program settings. The default configuration uses the following columns:

The operation result field (Result) is one of the key ones and requires additional explanation:

* - I tried to use color to mark those results that may be significant for finding problems, but everything is quite arbitrary and the presence of some results may not indicate an error; everything needs to be considered in the context of what is happening and surrounding events.
Newly recorded events are added to the end of the list of events in chronological order, and, accordingly, if there are many events, they instantly go beyond the boundaries of the active window. Thus, when basic settings interface, the information in the window remains static and reflects only the events captured first; the latest events are written to the end of the list and the change in its total length is indicated only by the changing size of the side scroll cursor. However, this behavior of the program can be changed by enabling Autoscroll of the list of events by enabling the corresponding option, or by pressing the combination Ctrl keys+A. In this case, the list of events will continuously scroll upward, showing the latest system events to arrive in real mode time.

Toolbar

Let us explain the purpose of the buttons located on the toolbar of the Process Monitor utility interface:

From left to right:

• Open - Loading previously saved events (traces);
• Save - Saves all captured events (traces);
• Capture - Enable/Disable event capture;
• Autoscroll - Autoscroll events in the main screen;
• Clear - Clears the main window and all captured events;
• Filter - Setting up event filtering and highlighting;
• Highlight - Setting up event highlighting;
• Include Process From Window - Configure event filtering for a specific window on the desktop. Allows you to point the target at the selected window, Process Monitor itself will determine whether the window belongs to a process and enable filtering by this process;
• Show Process Tree - Process tree;
• Find - Search for events based on specified criteria;
• Jump To Object - Jump to a registry key or file. Process Monitor analyzes the contents of the Path column of the selected row, launches the registry explorer/editor and opens the corresponding tree element;
• Show Registry Activity - Switch the display state of registry activity events among all system events;
• Show File System Activity - Switch the state of displaying file system activity events among all system events;
• Show Network Activity - Switch the state of displaying network activity events among all system events;
• Show Process and Thread Activity - Switch the state of displaying process/thread activity events among all system events;
• Show Profiling Events - Switch the state of display of profiling events among all system events. Profiling – Events recorded by the Process Monitor utility to calculate the amount of CPU time and memory used by each process.

Hotkeys

Event filtering

As already noted, the number of events occurring (generated by various components) in the system is quite large. The number of events that Process Monitor “sees” is smaller, but not by much. A reasonable question arises: do we need all events? The answer is obvious. Most of the events that are displayed in the main program window are completely unnecessary in the context of certain highly specialized user tasks. Well, the user does not need to see the loading events of the image of a suddenly launched update program, while he is busy studying the registry keys that store the configuration of the program he is interested in. It is with the goal of hiding unnecessary events that Process Monitor has flexible and powerful filtering tools. The filter allows you to hide unnecessary events, thereby limiting the number of displayed elements and narrowing the search area for the problem.

By filtering, you can hide an event, that is, turn off its display. However, all events will be recorded, and you can view filtered (hidden) events at any time by disabling (resetting) the filter.

Since filtering is one of the key elements of Procmon, its capabilities are very well developed in this program. You can filter events using any event attributes available to the program. There are several ways to filter events in Process Monitor:

Filter by class

This is the most general, one might say coarse event filtering, which allows you to exclude an entire class of events from the output at once: registry, file system, network, process/thread activity, profiling events. Setting up filtering by event class is represented by five buttons on the right side of the toolbar:

Accordingly, at the moment when any of the listed class buttons is deactivated (pressed) by the user on the command bar, a corresponding filter with the Exclude instruction is added to the general set of filters, hiding all events of this class from the output.

Filter menu

Whatever types of filters are used in Process Monitor, they are all available through the Filter menu and the Filter sub-item. This is a complete (general) set of filtering parameters and is presented in the following form:

The same filter settings window can be quickly called up in other ways: by pressing the Ctrl + L key combination or by clicking on the Filter button on the toolbar. The filter settings window provides the user with quite rich options for masking system events. The Process Monitor Filter window is divided into two parts: the top contains interface elements for adding a filter, the bottom contains a list of those already applied to to standard output filters. The filter is added by passing from left to right through all attributes, which, in turn, are represented by drop-down lists. Some attributes are related to each other, that is, selecting an attribute from one list may lead to automatic setting of the value in other lists. In some fields you can edit the value. After completing the formation, to add a filter, you must click the Add button; it adds new filtering parameters to the filters presented in the lower area of ​​the window.
To edit the rules of the selected filter, simply double-click on the corresponding line describing the filter at the bottom of the window. This will move the parameters to top part(the corresponding conditions will be filled in), where you can edit them and by pressing the Add button again, complete editing the filter, again moving it to the bottom of the window, to the list of active filters. You can remove a filter using the Remove button. After editing the filters, they can be put into effect (activated) by clicking the OK or Apply button. To restore the default filter settings, initial state, which was present when the program was first launched, click the Reset button.
As you may have noticed, by default the list of predefined filters contains a set of rules of the Exclude type. These rules serve to mask events that, according to the authors, are activity events of those operating system components that, in most scenarios, do not useful information to troubleshoot application problems. Here you can find exceptions for: processes of the Procmon (Process Monitor), Procexp ( Process Explorer), Autoruns, system processes, low-level I/O requests Windows drivers IRP_MJ, low-level FAST_IO operations, trace events, pagefile.sys events, NTFS manager metadata events.

Quick filter

You can apply a so-called "quick filter" to some of the event parameters displayed in the main window. It is activated by right-clicking on an event in the main program window:

In the context menu that opens, you can see several different filtering methods at once. Depending on the value of which column in the row the right mouse button was pressed, we can exclude or include from the entire output array events that have a match in the column value. This is done by selecting the appropriate item starting with Include ... (Include) and Exclude ... (Exclude). The context menu also contains the following items: Edit Filter..., Exclude Events Before, Exclude Events After.

Filtering by window owner

In addition to the basic filtering options, the Procmon utility has the ability to filter events by the application window handle (identifier). It's quite comfortable functional feature, since it provides the user with the opportunity to view the events of the process whose window appears on the desktop. To enable this functionality, find the crosshair icon on the toolbar:

Drag it onto the window you're interested in and Procmon will create a corresponding filter for the process that owns the selected window, changing the output in the main window accordingly.

Event highlighting

In addition to filters, Procmon has the ability to mark events by highlighting them with color. While filtering hides unnecessary events from the output, highlighting simply highlights the necessary events in the list. Directly, it seems, it does not apply to filters, since it does not hide events, but only marks them with a different color in the list. You can open the Process Monitor backlight settings window either by pressing the Ctrl + H key combination or by clicking on the corresponding icon on the taskbar. It looks like this:

As you can see, it is identical to the filter settings window, except that by default it has no settings, that is, the backlight is completely disabled. The algorithm for setting the backlight parameters and sampling the results of the Highlighting window is in many ways similar to those in the Filter window.

Search by events

Filtering results is excellent! The filter allows us to flexibly manipulate a sample from the general flow of events, however, in most cases it is quite difficult to create conditions under which the range of filtered events would be narrowed to some acceptable minimum. There are still a lot of results, and sometimes in the area of ​​filtered rows you need to find a suddenly discovered constant. Sometimes it is useful to find some keyword in the entire volume of captured information without understanding which column it may be located in, so creating a filter turns out to be problematic. These and many other operational points speak in favor of using a traditional search, familiar to everyone from childhood. The search window is called up by pressing the key combination Ctrl + F or by going through the Edit - Find menu:

Already familiar from others will be displayed Microsoft products search window. The search is carried out using the values ​​of all output fields of the Process Monitor main window without exception, and when the first match is found, the utility scrolls the screen to the found value and marks the entire line with the detected key fragment in blue.

Event details

Process Monitor receives from various components There are quite a large number of operating systems additional information. All of them are displayed in the Detail column. Most of them are purely informational, so they are usually skipped during analysis. Here you can find the requested access level for the operation, details of function requests, additional options some functions, driver package names, etc.

Exploring the event

All information collected by the Process Monitor utility in the process of recording events is presented in the form of a huge table, each row of which reflects only a generalized description of a specific event that occurred. So what, do you think this information presented in the main screen of the utility in the form of limited information divided into several columns is enough? Sometimes yes, but often not! We must pay tribute to the authors of Process Monitor for the fact that they provided the logic for a more detailed study of recorded events. Let's double-click on the event line and see what happens? After double-clicking, it opens separate window, having the following form:

In the Event tab, we see general information about the event that interests us. In general, this particular tab is not of great value to the researcher, since it contains information that can be obtained in the utility interface in other ways. But the two remaining tabs of the window may definitely interest us. The middle tab is called Process and looks like this:

Here we see the path to the module (Path), the command line with which the module was launched (Command Line), the user with whose privileges the process was launched (User), the login session identifier (Auth ID) in which the process, the owner of the operation is running, and the integrity level assigned to the process, the owner of the operation, at startup. Receives special attention information window with a list of libraries loaded into (Modules), which greatly helps to identify uninvited guests in the form of various types of malware. But for advanced researchers, the real value is the last, rightmost Stack tab, which allows you to see the call stack of the main thread of a process:

As we can see, in this tab you can find the classic chain of function calls, well known to us from the WinDbg debugger, called the call stack. First, it allows you to track the sequence of function calls from the moment the thread's start function begins executing. Secondly, by the sequence of function calls, you can determine which modules (libraries) these functions belong to, thereby identifying system components that either require updating or should not be used in a given module at all (for example: viruses).

Use cases

Some notes on Process Monitor program statuses:

• An event whose operation field is Load Image helps in diagnosing program startup problems. If the program does not start for some reason, then look for an event with the Load Image operation in the general list and look DLLs, which are loaded (described by their events) immediately after the image loading event. If we recall the algorithm for loading an image, we will understand that usually the Load Image operation is followed by search events for the necessary DLL libraries. The point is that Windows boot loader prepares the address space of the process, projecting into it all the libraries necessary for the program and performing implicit linking at the initial stage. If one of the DLLs required by the main program has an error loading its image, then it is obvious that the Windows loader will not be able to launch the main program. The image loading event is recorded with the status "access denied" (ACCESS DENIED);
• Statuses that you should pay attention to first of all: ACCESS DENIED, SHARING VIOLATION, NAME NOT FOUND (there are exceptions to the latter). The NAME NOT FOUND status is in most cases a fairly typical completion status; you shouldn’t exaggerate its significance so much and consider it the culprit of all the troubles. Often, the status is displayed when the application checks the presence of a file or registry key (containing the program configuration), and based on the results of this check, it executes this or that code, that is, it makes logical branching depending on the result of the request. The program may not find the registry key containing its own configuration, and in such cases we will see the same status NAME NOT FOUND. In short, the NAME NOT FOUND status must be viewed in the context of the event that led to it.
• To determine the culprit of the excessive load on the disk subsystem: launch Procmon, create a filter with the settings Path - begin with - C:\ (although any interesting one can be specified here logical drive) and click OK. Then, after a short data collection (~one minute), go to the Tools menu and select the Process Activity Summary item. In the window that opens, sort by the File Events column and get at the top of the list the names of processes that are actively working with the file system. Then, to find out which files are involved in intensive data exchange, you can select the Tools menu and the File Summary item, and in the window that opens, observe the list of files involved in disk operations. The output is automatically sorted by the Total Events column, so at the top of the list we see the files most intensively used in disk I/O operations.

Boot phase diagnostics

Quite often there are situations when problems with the operating system begin long before the user interface is drawn, already at the boot stages. To diagnose such network failures, there are a number of specialized tools, such as, for example. The Process Monitor utility fits well into this range. Procmon records the events of all processes executing during the boot phases, using the boot phase driver called procmon23.sys (the name may vary from version to version), which was described at the beginning of the article. Unfortunately, the driver starts at the stage of the Winload.exe module, which prevents the earlier stage of Bootmgr from being fixed, however, in most cases, you can turn a blind eye to this little detail. Enabling logging of the boot process is activated through the Enable Boot Logging option in the Options menu.

In addition to enabling the mechanism, Procmon offers to enable thread profiling at regular intervals. This is important because in most cases, boot problems are related to the slow operation of certain processes. It is in order to track such “slowing down” processes that profiling is enabled, which allows you to create sort of snapshots of the activity of threads within a process (call stack and other data) at regular intervals. As a result, the recorded information helps to understand exactly what operations the thread is spending CPU time on.
After enabling the Enable Boot Logging option, you can reboot the operating system. After the download is complete, run the Process Monitor utility to save log files of the download process and see the following dialog box:

In which we are asked to save the events of the download process into a separate log file with the extension .pml. Depending on the amount of information, the log file can be saved as single file, and is divided into a series of files of approximately equal size.

The amount of information recorded by the Process Monitor driver at boot stages for the "medium-loaded" :) operating system Windows 7 SP1 x64 is quite large. A typical size with thread profiling enabled can exceed 1500 megabytes.

After saving the log files of the boot phase activity, you can later analyze them by opening them in Process Monitor, either by double-clicking on the .pml file, or by opening it directly through the File - Open menu. However, there is one caveat here: if the boot process log file or set of files is too large, and the utility cannot find enough space in the page file or process virtual space to create a buffer, then the error “Unable to open Bootlog.pml for reading” is displayed. ". I personally solved it by temporarily enabling the swap file, which I traditionally have disabled altogether.

Process Explorer and Process Monitor are two of three very useful tools for fine tuning Windows operating systems.

If you want to know what's going on on your computer right now, try Process Explorer. At its core, Process Explorer is a more sophisticated version of the Windows 10 task manager.

It displays real-time information about running processes, including which account is the owner of a particular process. What files, registry keys and other objects were opened by this process. And which DLLs were loaded by this process. And also, the Process Explorer program provides snapshot system performance and use of its resources.

Do you prefer the busy but informative display of Process Explorer to the cleaner but mostly empty Task Manager? Please, there is a parameter for this. Specifically, in Process Explorer, select the Options menu and then Replace Task Manager (you will need administrator credentials to make this change). After this, pressing Ctrl+Shift+Esc instead of will open the Sysinternals tool.

The example below clearly shows that Process Explorer is very active. It uses color coding to identify each process by type, and animation to draw attention to starting and ending processes.

The default grouping view in Process Explorer handles parent-child processes and uses color coding to identify various types processes.

Color coding, you can customize by yourself. To do this, click "Options" and select "Adjust Colors".

The default settings are as follows:

 Green indicates new objects, and deep red indicates the moment objects are removed. Both of these colors appear for a short time, at the beginning and end of the process.

 Light blue - identifies “native processes”, those running under the same account as Process Explorer. Please note that these processes may be running in a different security context than the user account under which they were run.

 Pink- highlights processes that contain one or more Windows services. When you hover over one of these lines, a tooltip appears showing the names of the individual services running in that process. Which can be useful for determining which instance of Svchost.exe is responsible for this.

 Purple (or dark purple) - means Packaged (encrypted or compressed) executable programs. This could indicate potential malware, especially if it is associated with an unknown process.

 Turquoise - shows immersive processes that are associated with applications Windows Store.

 Dark gray - identifies a suspended process. Usually this Windows applications Stores that you previously opened but no longer use. Some Windows Store apps are specifically written so that they can continue to run in the background. For example, Groove Music will continue to play tunes even when you switch focus to another program.

You can identify the running of Windows and .NET processes by their color coding, although these attributes are not displayed by default.

The small graphs at the top of the Process Explorer window display system information in real time. To see all the graphs in one window, press Ctrl+I (as in information) or, in the menu bar, click "View" and select "System Information". Below is this display in action.

The System Information window shows performance graphs for current system in real time. And also, when you hover the cursor over a certain place, detailed tips.

Attention. If you don't see all the graphs, restart Process Explorer as an administrator.

Each of the individual tabs—CPU, Memory, I/O, and GPU—contains additional information about that specific resource group. Specifically, the GPU tab adds details that you won't find in the Performance tab of Task Manager.

The real power of Process Explorer becomes apparent when you click to expand the menu of available options. right click mouse on a separate process.

The first place to look, especially if you want to find out what this process is, is the Properties dialog box, which displays significantly more information than its counterpart.

Details for running process include version information and whether it starts automatically.

From this Properties dialog box or from the list of processes, you can send the hash code of this file to the VirusTotal service. Where to find out on any of the 50+ antiviruses monitored by VirusTotal whether it is a possible malware.

The bottom panel of the Process Explorer window is usually hidden. Using the keyboard shortcut Ctrl+L, you can make it visible (or, in the "View" menu, select "Show Bottom Panel"). This panel shows one of two views for the current process: or handles. You can switch between the two views using the keyboard shortcuts Ctrl+D and Ctrl+H respectively. In the figure below bottom panel in the DLL view.

The bottom pane can display a list of DLLs or a list of handles associated with the selected process.

Process Monitor

The last of the three Sysinternals superstars is the process monitor, also known as Procmon. When launched, it monitors in real time everything related to the file system, registry, network, processes, threads and DLLs, actions.

Procmon traces millions in seconds various operations. Which, to eliminate the interference, can then be filtered and focused on the potential cause of the problem. You can capture traces relatively easily increased activity system and save them in Procmon log files. And then analyze the captured data on another system.
To get an idea of ​​the level of detail captured by Procmon, see the listing below, which represents system activity over a period measured in small fractions of a second.

During a trace, Process Monitor records all events of each process, which, as shown in the status bar, can result in millions of discrete events.

Although Procmon collects everything it tracks, the default options include a filter that hides raw details from the file system and Procmon itself. You can configure the filter on the fly. Simply right-click on a specific entry in a specific column, and then in the context menu, select one of the options.

For example, the figure shows a right-click on Runtimebroker.exe in the process name column. You can now choose whether to include this process in the current filter, which effectively displays records from that process, or exclude it, so that the matching results are hidden. You can also select matching records to highlight without hiding those that do not match.

Right-click an entry in any column to see a menu of options for filtering events containing matching entries.

Look at the status bar at the bottom of the Procmon window to see whether a filter was applied to the recorded data and, if so, what effect it had. For example, in the figure, the filtered list shows fewer than 1 in 1000 events, allowing you to scroll through the data or further filter for patterns or .

Check the status bar at the bottom of the Process Monitor window to see how effective your filter is.

You can also create or edit a filter using Process Monitor's Filter dialog, which makes it easy to use. To access dialog box"Filter", on the process monitor menu bar, click the corresponding button. You can set conditions that determine which events will be included or excluded. Then click the "Add" button or select an existing filter and click the "Delete" button. To immediately see the effect of the new filter, click the Apply button.

Clicking the Filter button opens the Process Monitor filter dialog where, using the drop-down lists, you can add criteria. Before exiting, do not forget to click the "Apply" button.

(ProcMon) by Sysinternals.

I recently told one young Padawan how to use this wonderful, and in some cases irreplaceable, tool. And while I was talking, the idea came to me to write such an introductory instruction for those who are just starting their thorny path as an administrator.

In general, in my opinion, everything related to ProcMon is best described in the book from the developers, which is called “ Sysinternals utilities. Administrator's Guide”.

I won’t get into the weeds, and I will try to present it with a minimum of theory and a maximum of practice using a specific example.

Launching ProcMon

Records activity of the file system, registry, network,processes, threads, and real-time image loading.

So how? It's clear? 🙂

If you just launch ProcMon, the program's working window instantly fills with various events, even if you do nothing. It is very difficult for even an experienced master to understand these events and find those of interest. Yes, and it’s not necessary, but first things first.

Most often, ProcMon is launched for a specific purpose, for example, to determine what a particular program is doing, which process is writing files to a certain directory or registry branch, where the disk space is going, etc. Therefore, if you just start ProcMon, you will have to stop collecting events ( Ctrl+E), clear already collected events (Ctrl+X), configure filters ( Ctrl+L), and start monitoring again. In order not to make so many unnecessary movements, a command line parameter is provided /noconnect:

procmon /noconnect

Running with this option starts Procmon but does not start monitoring, instead immediately opening the filters window.

In general, to simplify the launch, I do (and advise everyone to do so) as everything is described in the same book:

My co-author Aaron usually creates a folder called C:\Program Files\Sysinternals and extracts the contents of the Sysinternals Suite into it. There utilities cannot be changed without administrator rights. It then adds this directory to the system environment variable Path, which makes it easy to launch utilities from anywhere, including through the menu Start | Run (Start | Execute).

Filters in ProcMon

As mentioned above, the filter window opens when launched with the parameter /noconnect. If you accidentally closed it, or you need to correct already configured filters, you can open the filters window with a keyboard shortcut Ctrl+L, or through the menu Filter | Filter….

So we got to practice :)

I already know how to monitor the registry, so today we will learn how to monitor the file system. For example, we will track what changes it makes standard notepad.

So, we have the filters window open.

Filters in ProcMon

Just in case, click the button to reset the filters to the default state - Reset(by default, ProcMon has a lot of filters configured, it is not recommended to delete them) and add a filter

Process Name is notepad.exe include.

Press the button Add. As the name suggests, only events related to the notepad.exe process will be captured, i.e. those events that the notepad generates.

Important point: The process name must be specified in full - with an extension, otherwise ProcMon will not capture anything. Alternatively, you can use a filter

Process Name begins with notepad include

In this case, events associated with processes starting on notepad will be captured, this can be either a standard notepad orNotepad++, or some other notepad. In the same way, add a filter for writing files:

Operation is WriteFile include

Click Add And OK(in general, you can just press OK, in this case ProcMon will say that there is no such filter yet and will ask if we want to add it. The thing is that pressing the button closes OK filter window, if this is not the only filter, then it is better to click the button Add, this will allow you to add a filter, and leave the filter window open for subsequent filters).

Since we are only interested in file activity, in the main ProcMon window we disable the icons for monitoring the registry, network and processes - leaving only monitoring the file system (highlighted in the screenshot below).

Another important point.

By default, ProcMon logs all system activity, even those events that do not fall under filters, which in some cases can lead to slowdowns. If you are sure that the filters are configured correctly (in in this example we're sure), and you don't need the events hidden by them - they can be discarded using the option Filter | Drop Filtered Events(Delete filtered events) in the menu Filter. This parameter only affects the registration of current events; previously recorded events are not deleted from the log.

After the filters are configured, we start collecting events (a button with a magnifying glass, or Ctrl+E). Launch notepad, write some text and save the file. Let's see what happened:

File activity in ProcMon

As you can see from the screenshot, ProcMon recorded the event of the file being written by the notepad.exe process along the path C:\temp\test.txt.

Let's do one more experiment.

Stop event capture ( Ctrl+E), close notepad and clear the collected events ( Ctrl+X). Call up the filter window ( Ctrl+L), reset the filters (using the button Reset) and add the following filter:

Path begins with c:\temp\

By this we indicate that we are interested in any activity along the way C:\temp. And since the value is not specified exactly (not is, A begins with), then events will be captured not only from this directory, but also from all its subdirectories.

Make sure that only file system monitoring is enabled (resetting filters resets everything to its default state)

Filters in ProcMon

Let's start observation. Let's open Explorer and follow our path. Let's take a look at ProcMon.

This is what opening a directory looks like in ProcMon

There will be a bunch of events that we don’t understand, but we don’t need them, just look at how many events happen when you just enter the directory.

You can open the file and see what a mess ProcMon will be. This is why I never recommend running ProcMon just to see what's going on in the system.

In order to see the file reading events themselves, stop collecting events, clear the results window, add a filter

Operation is ReadFile

and open the file again.

It should look something like this (as you can see from the screenshot, I opened the file in two different processes):

Today I will try to understand the problem of correct operation of software under user rights using the example of software (Prima Expert Digital Microscope) for a digital microscope from JSC LOMO.

Like many enterprises, we have a strict security policy prescribed in the STP and ordinary employees do not have admin rights, so from time to time there are problems with the operation of the software under the user account account, because The software requires advanced rights.

So, what I have at the start is that the Quality Control Department (technical control department) requested the installation of the microscope-accompanying software “Expert Prima version 1.0” on a regular user machine with Windows XP.

The installation was completed but was detected next problem. The program does not see the camera and cuts off the interface after launching as a user; it works correctly under the software administrator.

The first thing I tried was to give the user permission to change the directory with the LOMO program.

This action did not produce positive results. Armed with the Process Monitor utility, I set up a filter in it for the Prima.exe process and launched the Prima Expert software.

The utility displays all affected system resources for Prima.exe to run

I sort by the Detail field and go look at the affected bushes, I’m interested in the Desired Access: Read/Write value.

I give the user full access to the registry folders:

HKLM\Software\Microsoft\VfWWDM Mapper
HKLM\System\CurrentControlSet\control\MediaResources\msvideo\MSVideo.VFWWDM

Why these folders? Because the user has full access to HKCU - this is his branch.

I run it to check, the program works as expected.

I hope the article will be useful to novice admins and enicers. I have been using this method for a very long time. It's versatile and has never let me down.