What is Process Monitor (ProcMon) and why should you care?
If you have ever been in the position of needing to know how and what an application is doing, without yourself having any knowledge of said application, then ProcMon is the discovery tool for you.
ProcMon is (oddly enough) a Process Monitor. That is, it monitors and records virtually every action taken by every process on a system. While extremely detailed, the results are often more overwhelming than they are helpful. Anybody who has run the process monitor tool has seen the tens-of-thousands of results it will produce – without you even attempting to CAUSE any results.
It can be downloaded directly from Microsoft, and is regularly updated: https://docs.microsoft.com/en-us/sysinternals/downloads/ProcMon
In order to make process monitor useful, the filters need to be leveraged.
Let’s say you have been handed an application by your Apps team for integration into a Citrix or Horizon environment. As the owner of the platform, you need to be sure that the settings for this new application are captured and persisted across user sessions. The problem is, most application teams strangely don’t have a lot of “under the hood” knowledge of an application’s inner workings. In the case of application settings retention or personalization, we need to know WHERE an application is storing all it’s user-relevant settings.
There exist many methods and tools for this task, but leveraging Process Monitor is by far the most complete and thorough. We’ll use my favorite application, PuTTY (a simple ssh/terminal client) as an example.
But where does it store data!? A quick look through AppData and the Registry show nothing obviously “PuTTY” related:
ProcMon to the rescue! Starting up ProcMon it immediately bogs the machine down, capturing everything happening, with little regard for man nor beast. As soon as you can, stop the capture and clear the existing results:
Once capture has been halted and the existing results cleared, open up the filters dialog:
There exist here many pre-populated filters, largely geared around excluding the actions of ProcMon itself. However for our purposes we will not need any of these existing filters; select them all one by one and click “Remove” until there are none left.
Now that we have a completely blank slate, we can work on adding new filters to specifically target our application of interest (PuTTY)
From looking at the task manager, we can see that PuTTY is a single process called “putty.exe”, so we will start with a filter to only include operations from that process.
With that filter in place, if you run a capture and run PuTTY, we will only see operations from that process, but you’ll notice those operations still number around 3,000 – and that’s just for the application launch!
This is because it’s including ALL operations from that process, including things we don’t particularly care about like DLL loads and system queries. To get to the meat of what the application does when it saves a session, we’re going to add three more filters, shown here:
The first two Event Class filters include all File System and Registry operations. The vast majority of applications that store settings locally, store them in the registry or in the file system.
The last Category filter limits what is shown to Write operations – changes that the application is actively making. This is useful for clearing out the noise of all the system registry and filesystem Reads that most applications do as part of initialization.
With our final set of filters, Click Apply and OK, restart the ProcMon capture and launch putty.
But wait! There’s nothing here! Ah yes, because we are only capturing on WRITE we have filtered out all the READS of the existing PuTTY sessions. At this point, we could either turn off Write filtering (which would bring in lots of noise), or trigger a write by changing a session in the program. Let’s do the latter;
Ah-ha! By adding a new connection and clicking Save, PuTTY makes a write of the session’s data to the Registry. Specifically, under HKEY_Current_User\Software\SimonTatham …. Whoever that is.
A quick look in the Registry confirms what ProcMon has shown – that all the stored sessions for PuTTY are stored in this Registry Key:
Now, obviously PuTTY is not the worlds most complex application. It is well behaved and stores it’s settings in a single, simple location. However it is still a good example that a manual inspection of the FileSystem and Registry won’t always turn up answers – as who would have known to look under this gentlemen’s name?