by Wojciech Sura

Monitoring process events

Some time ago my friend had a problem with PHP for IIS. Regardless of how did he modified contents of the php.ini file, the PHP failed to load required extension. We damaged that file on purpose to see no effect at all – PHP seemed not even to try opening it. Apparently, it was using a configuration file placed in a different folder (or at least searched for it elsewhere).

But where?

Let’s try to recreate that situation; though because I don’t have a copy of IIS with PHP for my disposal, my own small application, ProCalc volunteered to be an example. Last time we used DbgView – a nice tool being a part of great diagnostic package, SysInternals; this time we’ll use another handy tool – ProcMon – to monitor application’s activity in a great detail.

After starting ProcMon, we’ll be flooded with thousands of notifications – that’s because ProcMon attempts to inspect every possible process. We have to set up a filter to monitor a specific application.

ProcMon-filter

 

ProcMon will now display all low-level thread, file and registry events (regardless of their outcome), which are dispatched by the process. Let’s have a look.

ProcMon-events

Ok, that’s still too much. Let’s narrow our search only to those (changed) files, which have “xml” in their names.

ProcMon-found

And we’ve got it: ProCalc first tries to open a configuration file in its own folder and then searches for it in user’s home directory.

Note, that ProcMon also helps finding out, which dynamic libraries are missing (if any) and which version of .NET assemblies application is using.