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.
Background
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.
Conclusion
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.
-Frog Out
The Frog Pond of Technology 
Originally posted on: https://briantjackett.com/archive/2015/07/29/getting-started-with-procmon-for-troubleshooting-long-running-processes.aspx#645563Hola Brian, buenas noches.En principio le envío un cordial saludo, por otro lado me encuentro en un escenario de preparación para la ejecución de un RAP de SharePoint Server 2010 con un cliente, sin embargo, validé los prerrequisitos y cuando ejecuto el cliente me indica un error que dice: “PowerShell Check”, el servidor “Tools Machine” y el conjunto de servidores de SharePoint Server 2010 se encuentra con Windows Server 2012 R2 (WFE,APP y SQL), el servidor “Target Server” tiene el rol Front-End, los servidores tienen .NET Framework 4.5 y Windows PowerShell 4.0, entiendo que se requiere de Windows PowerShell 2.0 para ejecutar el RAP para SharePoint Server 2010 en el equipo “Tools Machine”, después de varios intentos y la configuración de la iniciación de Windows PowerShell 2.0 en el servidor “Tools Machine” (https://technet.microsoft.com/en-us/%5Clibrary/Hh847899.aspx) me sigue presentando el error en el cliente del RAP “PowerShell Check”; Como detalle le comento que al ejecutar las pruebas de conexión que se describen en el documento de Prerrequisitos en el capítulo “Testing Remote PowerShell” he logrado extraer la información de la granja y las bases de datos de contenido de forma satisfactoria, pero al ejecutar el cliente del RAP para SharePoint no puedo pasar del error antes descrito, por favor si usted me puede apoyar con alguna experiencia que haya tenido al respecto, se lo agradecería.Gracias y reciba un cordial saludo.Carlos
LikeLike
Originally posted on: https://briantjackett.com/archive/2015/07/29/getting-started-with-procmon-for-troubleshooting-long-running-processes.aspx#645600Nice writeup. The backing file option was new to me. Normally I just go with Drop Filtered Events to reduce the amount of logged data by magnitudes.
LikeLike