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