Overview Process Monitor is a free tool from Windows Sysinternals, which is part of the Microsoft TechNet website. The tool monitors and displays in real-time all file system activity on a Microsoft Windows operating system. Monitoring charts¶. We use monitoring charts, also called control charts, to display and detect this unusual variability. A monitoring chart is a display of one value (variable), against time, or in sequence order. These time-based plots also show some additional information: usually a target value, and one or more limits lines are superimposed on the plot. Sometimes, if a process has a hard time running smoothly, it might not have the necessary permissions to do it. Check the process’s Security Properties to see the existing permissions and assign new ones if necessary. Wrapping Up Windows Process Monitoring. Using Task Manager for Windows processes is quite straightforward.
Process Monitor is a monitoring tool for Windows that shows live file, Registry and process/thread activity. It is a combination of two older Sysinternals utilities, Filemon and Regmon.
Process Monitor is a part of Windows Sysinternals which is a set of utilities to manage, diagnose, troubleshoot, and monitor Windows. Sysinternals was originally created in 1996 by Winternals Software and was started by Bryce Cogswell and Mark Russinovich. Microsoft acquired Winternals on July 18, 2006, which included Sysinternals and the utilities within it.
The set of tools is now available on any Windows computer by opening live.sysinternals.comtools in file explorer. This UNC path is a service provided by Microsoft and is referred to as Sysinternals Live.
Starting Process Monitor
You must run ProcMon.exe from an elevated command prompt, so that it opens in administrative mode as it needs to install Filter Drivers. As soon as you start it, it will begin capturing, and quite quickly will start taking space from your paging file. Therefore, only run it for the necessary time as leaving it running will likely cause your computer to crash unless you run it to Drop Filtered Events against a certain filter. More on this under Filter Process Monitor
Filtering with Process Monitor
ProcMon can be run for days if you chose to have it filter for a certain type of event. Start by selecting Filter -> Drop Filtered Events.
Choosing this option means that only what is filtered will be saved to the log file, as opposed to only filtering will filter what you see, but will log all to the log file. Now, filter to only view processes where the result is Access Denied by opening Filter -> Filter:
You can also filter right from the main console by selecting a Process, right clickign and choosing one of the filtering options. For example, if we choose to Exclude Events After this event, we can also see that it automatically creates a filter for this choice which we can choose to remove later.
Once you have a specific filter set that might be useful for a certain troubleshooting task, you can choose to Save or Load the filters under the Filter menu:
Advanced Filtering with Process Monitor
In some instances, you may want to view all events, including those by default that are filtered out of ProcMon. You could opt to manually remove all of the built in filters, but an easier way to do this is to simply select Filter -> Enabled Advanced Output
How to Find Changed Values
Some people will use ProcMon to try and see what changes a process makes, but it can become daunting. An easier method is to try and utilize ProcMon in a way where you can filter for events happening. Let’s say for example we want to see what registry values are set when we disable Automatic Restart on system failure. To do this, first stop and clear the trace, then filter ProcMon to only show RegSetValue Operations:
Now, begin the capture and make the desired change:
Stop the capture once the change has been made. Now, we can easily see the registry value change that was required to make this change:
Enable Boot Logging
A very useful feature of process monitor is to trace events during logoff, shutdown, startup and login. There is a special feature to do this ProcMon to do this under the Options menu. Select Enable Boot Logging and then reboot your system. The next time you open ProcMon, you’ll be prompted to save the boot log events to a file.
ProcMon Tools: Process Tree
ProcMon has several tools available by selecting Tools from the menu. For example the Process Tree shows you the processes lifetime and how long they lived during the trace.
Running ProcMon against a Remote Machine
Utilizing psexec, 23 can run ProcMon against a remote machine if we do not or cannot be at a remote site for monitoring.
To start the trace on a remote computer run:
Now, to stop the trace on the remote computer run:
Finally, copy the log file to your remote machine for viewing:
You can then view the log file in ProcMon locally by running:
ProcMon Filter Drivers
If ProcMon has some issue connecting to the filter driver and gets stuck opening, you can run it to not connect to the filter driver:
To view the filter driver that is associated to Procmon, run
Process Monitor, by SysInternals under Microsoft, shows real-time file system, Registry and process/thread activity. To do this it registers itself with the Event Tracing for Windows to receive activity reports from both the file system and the windows registry.
It can be found here: Windows Sysinternals Process Monitor.
Display Overview
Some basics of what to expect to see, here is a resized window, giving all of the default information I want to go over:
Capture (Ctrl+E): Enables/Disables capturing activity.
Autoscroll (Ctrl+E): Enables/Disables scrolling of display as activity is shown. I find it best to disable Autoscroll until enough filters are in place, ymmv.
Clear (Ctrl+X): Clears/flushes captured activity.
Filter (Ctrl+L): Shortcut to the filter screen.
Highlight (Ctrl+H): Enable highlighting of particular captured activity.
Include Process From Window: You see a program you want to watch to see what it does, these cross-hairs will help you zero in on just it.
Registry Activity: I use this secondarily and have sparse experience with it, I tend to disable it on startup. Results include SUCCESS, NAME NOT FOUND, BUFFER OVERFLOW, REPARSE, NO MORE ENTRIES, ACCESS DENIED, and BUFFER TOO SMALL.
File System Activity: My bread and butter of this tool. Almost always will be using this. The seemingly more useful results include SUCCESS, ACCESS DENIED, NAME COLLISION, PATH NOT FOUND, END OF FILE, and BUFFER OVERFLOW, while the plethora of other results are NO MORE FILES, NAME NOT FOUND, FILE LOCKED WITH WRITERS, FILE LOCKED WITH ONLY READERS, NOT REPARSE POINT, PRIVILEGE NOT HELD, IS DIRECTORY, INVALID PARAMETER, NO SUCH FILE, RANGE NOT LOCKED, SHARING VIOLATION, OPLOCK NOT GRANTED, INVALID DEVICE REQUEST, and FAST IO DISALLOWED. This may not be the full list, but what I could generate.
Network Activity: This would be my 3rd most used, and last as I don’t use the next two. I like this to see if a connection was made out/in and to/from what host.
Process and Thread Activity
Profiling Events
*A note on Fast IO
“Fast IO indicators in a trace have to do with how the windows file cache works. Process Monitor provides a default filter that removes most of the Fast IO events, by doing an exclude on events that have an Operation starting with the string “FASTIO_”. This leaves “FAST IO DISALLOWED” events captured and displayed. You often see a “FAST IO DISALLOWED” entry on a file followed by the normal path attempt to open the file which succeeds. Adding a filter to exclude Operations start with “FAST IO” eliminates these red herrings.
Starting up Process Monitor
When starting up the application, the output is overwhelming. Expect it, much like running Wireshark and showing all traffic on an interface, you are going to see more than you really need.
Filters
The default filter:
This strips out actions by the Process Monitor application itself. I use this as a base, and once the program starts showing results, exclude the imports I am not looking for. I rarely use the registry watch, and I typically stick to just the file monitor.
Procman
So for the default that loaded on the last version I downloaded, I would start the application, to stop the capture, disable , , and . I am then left with just enabled. Now start the capture again, .
For the slew of what is left, we have two options.
Include only the process by name or PID as a filter.
Pros: It is much cleaner and more direct if you know exactly what to look for. If I am trying to watch a single IIS Application pool, I can find its PID in the task manager, and add an Include for the matching PID.
Cons: This can exclude an item you had not anticipated, leaving a surprise to find out later.
Exclude Noise by Process name
Pros: Easier to start with when learning. Can reveal conflicting applications.
Cons: Time cost, this can be a 30+ list in some cases. Excluding that number of applications can take numerous runs of Process Monitor, starting and stopping captures to catch as much noise as one can.
Process Monitor Api
Exclude Noise by Process name
I start excluding process’s by name for items I know I am not looking for.
Process Names’s I have been known to exclude:
In General:
System
Explorer.EXE
services.exe
scrnsave.scr
svchost.exe
mmc.exe
rundll32.exe
Desktop Environments:
trillian.exe
lync.exe
chrome.exe
firefox.exe
plugin-container.exe
FlashPlayerPlugin_11_5_502_135.exe
Nexus.exe
NOTEPAD.EXE
pn.exe
OUTLOOK.EXE
vmware-usbarbitrator.exe
FlashPlayerUpdateService.exe
GoogleUpdate.exe
putty.exe
Server Environments:
SSSvc.exe
Include only the process by name or PID as a filter.
Process Monitor Log
TBD, As I run into further examples, I will flesh this out better.
Tips Tricks Notes
- Don’t record/track when you don’t need to be. The application can lock up and/or run up resources. To be as clear as I can, I had to restart my machine after leaving it running overnight. I was gathering examples by running the software, and failed to follow my own directions. Windows literally told me to restart my applications.
- When troubleshooting when layers/applications, I find it helpful to keep the browser on the local server as being listed in my output so that I can use it as a marker for when I am testing. It helps to narrow down what’s going on in the underlying moments when a request goes awry.
- Even with good filters, there still is a lot of stuff to wade through in a trace. For example, when the application loads a dll, there may be several attempts to open the file (CreateFile) under different folders, until the file is found (keep in mind that you don’t necessarily want to go throwing a looked for file in the first place the application looks for. Saw this be very bad in a ColdFusion example).