Trace a Windows app that cannot find a file with Process Monitor

When an app fails with a vague file-not-found error, guessing which DLL or configuration file it wanted often wastes time. Microsoft's Sysinternals Process Monitor records real-time file system, Registry and process activity, including paths and results. The useful method is a short capture around one reproduction, filtered to the exact process, then examining the sequence that precedes the failure. A NAME NOT FOUND entry is not automatically the bug; many apps probe optional locations normally.

Before you start​

Download Process Monitor only from Microsoft's Sysinternals site. Keep a copy of the error and know the app executable name. Capture on a test or personal PC with enough free disk space; traces can grow and may include usernames, paths and sensitive document names. On a work PC, follow support policy before sharing a trace.

Do it step by step​

1. Start Process Monitor and stop live capture immediately while setting up filters. Filter Process Name to the affected executable and optionally limit Operation to relevant file events.
2. Clear previous events, start capture and reproduce the error once. Stop capture as soon as the message appears to keep the data small and relevant.
3. Find the last events from the affected process and inspect path, result and detail. Compare a failed lookup with nearby successful paths; a missing optional file may be expected.
4. If a particular path appears causal, confirm whether the file should exist by checking the vendor's installer, configuration and permissions. Do not copy a random DLL from the Internet.
5. Test a supported repair or reinstall of that app and repeat the capture. Compare whether the same path failure disappears and the app now works.
6. Save a filtered trace only when needed for vendor support, review it for sensitive data and remove local copies after the case is resolved.

Check the result​

A specific missing or denied path is linked to the reproducible failure, and a supported repair changes both the trace and application outcome.

If something goes wrong​

If the trace is huge, filter before the next capture and shorten the window. If no file error is causal, look at Registry or process events or ask the vendor for debug logs. Do not treat every Access Denied or NAME NOT FOUND as an attack.

Know the limit​

Process Monitor observes behavior; it does not fix the root cause automatically. Captures can contain sensitive information, and changing permissions on system folders to silence an event can weaken Windows. Microsoft Process Monitor

Decision checkpoint​

A trace is strongest when you can reproduce the problem in seconds. Stop capture before opening unrelated files, and compare a failing run with a known-good run if possible. For permission errors, determine whether the process is supposed to write that location; broad ACL changes can expose private files. If support requests a trace, share the filtered capture through its private portal and explain the exact reproduction time so the analyst can find the relevant events.

Aftercare​

Keep the app's repaired version and the failure path in the support note. Delete unneeded traces securely because captured paths and process details can reveal private work.