In this post I will cover a few tips for getting started with using ProcMon (Process Monitor in the Sysinternals Suite) for troubleshooting long running processes. Note that I am not an expert in ProcMon by a long shot, so this is more of a selfish post to remind myself of some key settings to be sure to configure.
Side note. You can run the Sysinternals tools from the web at Sysinternals Live without needing to download the tools to your local machine. This is useful if your customer / organization doesn’t allow installing / running 3rd party tools or has concerns about running them directly on a machine.
Skip down to the Tips section if you don’t want to read the back story.
At least once a month I have a customer scenario where two or more applications are not playing nice with each other. A .Net website and anti-virus software, SharePoint and server backup software, etc. Usually the problem involves one piece of software placing a write-lock or exclusive hold on a file / registry entry while the other software expects the same. In such a scenario we need to monitor a file / registry entry from a fresh start (restart application pool, process, etc.) until the file / registry access error happens which could be hours or days. Since we are monitoring for such a long time we want to make sure that ProcMon only captures the data that we need as well as be mindful of memory / disk space usage.
1) Start ProcMon with no tracing
If you start up ProcMon by double clicking the executable ProcMon will start capturing data immediately. Instead launch it from the command line with the /noconnect parameter.
c:sysinternals> procmon /noconnect
2) Specify a backing file
By default ProcMon will store event data in virtual memory. Since we could capturing hours or days worth of data it might be preferred to store that to a disk with lots of free space (multiple GBs or more depending on expected duration and number of events).
Navigate to File –> Backing Files… for these settings.
Change the radio button from “Use virtual memory” to “Use file named:” and then specify the filename you would like to use as a backing file. .PML is the default extension used so I followed that convention.
3) Apply filters
By default all processes accessing any files and / or registry locations will be monitored. Instead we want to filter events based on our criteria. The most common scenarios that I run into (in order that I see them) are 1) filtering for location when we don’t know the process that is locking it or 2) filtering for a specific process when we know the process but not the location that is being locked.
Click on the filter icon in the top menu or click Filter –> Filter… to access these settings.
In the example below we filter for any path that begins with “c:MyAppFolder”. By doing this we include any subfolders of our application folder.
4) Drop filtered events
By default ProcMon will capture all events whether they are filtered or not. To save on memory (or file space if you use a backing file) you can drop filtered events. There is a chance that if you created your filter incorrectly you may miss the events needed for troubleshooting but by keeping your filter broad enough that shouldn’t be an issue.
Click on Filter and select the Drop Filtered Events menu item. If there is a check mark next to the menu item then you have correctly configured ProcMon to drop filtered events.
In this post I walked through a few quick tips for configuring ProcMon when you need to troubleshoot a long running process. Hopefully these tips will help you avoid out of memory issues or having to parse through hundreds of thousands of events.
Special thanks to my peer and teammate Ken Kilty for providing the research and background info for this blog post.