Before we go any further with procmon, we need to understand a few concepts.
A process comprises;
a virtual memory container that holds executable code, memory mapped files and data structures,
resources that are attached via handles,
a collection of threads that represent paths through the executable code and run on a CPU, and
a security context (the userid under which all of the process threads are running).
In this video blog we look at how we can use procmon to find information about processes and threads. Most importantly we introduce the concept of thread stack traces that can be used to track the code path of a thread.
It's worth expanding a little on the subject of virtual memory.
As I'm sure you know, code must reside in physical memory before it can executed. If the code is missing a page fault occurs and the memory manager pulls the missing page of code into a free physical page frame. The pages are loaded from the paging file, the executable, the DLLs or the memory mapped files.
Depending on how we set the filtering, in particular the Drop Filtered Events setting, the rate of trace records (and hence disk writes) can be quite high. Obviously we don't want procmon to cause performance problems, and so allowing procmon to write into virtual memory (and hence eventually the page file) or to any location on the C: drive is not ideal. Preferably we want to write the procmon output to a dedicated or "quiet" volume - a dedicated USB drive works well.
Best regards...Paul
PS: I've simplified things a bit in this blog. For more a more detailed explanation of processes, threads and virtual memory I recommend the Windows Internals books from Microsoft Press.