Process Monitor: what it does and who it is for
What Process Monitor records
Process Monitor records what a Windows system is actually doing. It captures file system activity, registry reads and writes, process and thread creation and exit, image loads, and network operations in a single stream, each event stamped with a timestamp, the process that caused it, the path involved, the operation, and the result code. That last column is the one that solves cases nothing else can: an access-denied, a not-found, or a sharing violation tells you why a program failed, which is a different question from what it was doing. The tool is equally useful after the fact, because a trace can be captured to a file, searched, filtered and exported for someone else to read.
How the workflow fits together
The archive is small and portable. Run it as administrator for full coverage, and set a filter before you reproduce the problem; a few seconds of unfiltered activity on a busy machine produces hundreds of thousands of events. Filters compose on process name, process ID, path, operation, result and more, and they can be included or excluded, which matters because the correct first move is usually to exclude the noise sources rather than to look for the needle. A boot-time trace can be enabled so that events are captured from the earliest start of the session, which is the only way to see a failure that occurs before any interactive tool could be launched. The captured log can then be saved as a native file, a CSV, or an XML document.
Configuration, limits and trade-offs
Columns can be chosen and reordered, the display can be limited to a rolling window so memory does not grow without bound, and symbol resolution turns module addresses into function names. The two honest limits are volume and overhead. A full-capture session slows a busy machine measurably, and the logged data can run to many gigabytes if the filter is too broad or a long boot trace is enabled. Storage for the backing file must be planned, and the backing file should live on a different volume from the one being traced to avoid feedback. As always with a trace tool, the output records what happened; interpreting it still requires knowing what the program expected to happen.
Who should choose something else
A user troubleshooting an application that ships its own diagnostic log should read that log first, because the vendor will understand its own error codes better than a generic event stream. For a simple locked-file question, a process viewer is faster and less noisy. And on production systems where tracing overhead is unacceptable, the answer is usually the operating system's built-in event tracing and a targeted provider rather than a general-purpose capture, which is designed for investigation on a machine where a temporary slowdown is an acceptable price.
- Best for
- Support engineers and administrators diagnosing application failures, permission problems and startup errors that produce no useful log of their own.
- Good to know
- An unfiltered capture is enormous and slows the machine, boot tracing needs disk space planned in advance, and the trace shows what happened rather than why the program wanted it.
Process Monitor captures file, registry, process and network activity as it happens. Set the filter before you reproduce the fault, because an unfiltered capture grows faster than you can read it.
How to get started
- Download ProcessMonitor.zip and extract it.
- Run it elevated for complete coverage.
- Set a filter on the process name before reproducing the issue.
- Exclude known noisy paths such as the page file.
- Reproduce the failure and read the result codes.
- Save the log to a file for later analysis or to share.
Questions & answers
How do I avoid an enormous log?
Filter before you capture, exclude noisy paths, and limit the backing file size in the options.
Can I capture what happens during boot?
Yes. Boot logging starts recording before the session is interactive, and it needs space for the trace file.
Why is a result code useful?
It distinguishes access denied from not found from sharing violation, which usually names the actual cause of a failure.
