Process Monitor 4.12 — How to verify filtered event exclusion and detect lost events?

Process Monitor 4.12 cannot, from the publicly documented interfaces, provide conclusive evidence that every relevant event was captured without loss; use ProcMon for functional inspection, but use WPR/ETW when auditable lost-event counters are required.

Q4 — What filtering proves

ProcMon’s normal filters are documented as non-destructive: they hide nonmatching events rather than removing them from the underlying capture. Its native PML format preserves captured data, and the Process Tree shows relationships among processes referenced in the trace.^1^

However, Microsoft’s public documentation does not specify for ProcMon 4.12:

• At which pipeline stage Drop Filtered Events discards events.
• Whether rejected events ever enter kernel or user-mode buffers.
• A formal guarantee that rejected events cannot appear in the PML.
• A count or manifest of events rejected by that option.

Therefore, do not treat Drop Filtered Events enabled by itself as proof that unrelated activity was absent from the stored trace.

Practical PML verification

For a controlled test:

1. Run the platform-matching executable elevated.
2. Configure a file-backed capture: File → Backing Files → Use file named.
3. Start capture before launching the test parent process.
4. Run the workload, wait for all expected descendants to terminate, and stop capture.
5. Reopen the resulting PML.
6. Remove/reset display filters, then inspect Tools → Process Tree.
7. If saving a separate validation copy, select All events and Native Process Monitor Format (PML).

Microsoft specifically documents file-backed capture and warns that saving only displayed or highlighted events may omit data needed for analysis.^2^

A repeatable command-line capture is:

procmon64.exe -accepteula ^
  -backingfile C:\Trace\Test.pml ^
  -quiet -minimized

rem Launch and complete the controlled workload here.

procmon64.exe -terminate -quiet

Validate the reopened PML for:

• No events belonging to deliberately generated unrelated “noise” processes.
• The expected parent Process Create.
• Expected descendant process-create records.
• File-system operations from each expected PID.
• Thread Exit records followed by Process Exit where applicable.

This proves what the PML contains, not that ProcMon captured and accounted for every event generated by Windows.

Child-process coverage

Do not rely on one fixed parent PID filter as a general descendant selector. Each child has its own PID, and a process may create further descendants. ProcMon can display the process relationships that are present in the trace through Tools → Process Tree, but the documentation does not state that a parent include-filter dynamically and recursively includes every future descendant.^1^

For the validation run, the safer ProcMon method is:

• Start an unfiltered or minimally filtered capture before the parent starts.
• Keep Drop Filtered Events off.
• Stop immediately after the process tree finishes.
• Determine the actual tree afterward and apply PID/process filters during analysis.

Microsoft likewise recommends capturing first and applying filters afterward when avoiding missed ProcMon activity is important.^3^

Q5 — Lost and incomplete ProcMon events

No public ProcMon 4.12 documentation identifies supported PML fields or UI counters equivalent to:

• events lost;
• log buffers lost;
• real-time buffers lost;
• capture overflow; or
• trace-finalization status.

The event count in ProcMon’s status bar is a recorded-event count, not a documented loss counter. Successfully reopening a PML detects gross corruption, but it does not prove zero event loss.

Operational checks still useful for ProcMon are:

• Prefer a file-backed trace over virtual-memory storage.
• Ensure sufficient free disk space.
• Keep the reproduction short.
• Stop ProcMon normally with -terminate.
• Reopen the PML and check its ending timestamp and expected terminal markers.

These reduce risk but do not provide loss-free certification. Microsoft warns that virtual-memory backing can exhaust virtual memory and file backing can exhaust disk space.^2^

Documented ETW alternative

Use Windows Performance Recorder (WPR) with an appropriate built-in or custom ETW profile when loss accounting is a requirement. WPR reports Events dropped while recording and warns when saving if events were lost.^4^

From an elevated console:

wpr -start GeneralProfile -filemode
wpr -status collectors -details

rem Run the synthetic workload.

wpr -status collectors -details
wpr -stop C:\Trace\SyntheticTest.etl

wpr -status reports the dropped-event total; collectors -details exposes collector information, including events lost and lost buffers.^5^

At the ETW API level, the session properties expose:

• EventsLost
• LogBuffersLost
• RealTimeBuffersLost
• BuffersWritten

^6^

A finalized ETL header also contains EventsLost, BuffersLost, and EndTime; EndTime can be zero when the trace was not properly finalized.^7^

No supplied Microsoft documentation defines one ready-made WPR profile that exactly reproduces ProcMon’s complete process-plus-file-system operation schema. Confirm that the chosen built-in profile exposes the required events in WPA; otherwise author a custom WPR profile selecting the necessary system and event providers. WPR supports predefined and custom XML profiles.^8^

Acceptance criterion: require zero WPR dropped events during and immediately before stopping, zero ETL EventsLost/BuffersLost, a nonzero finalized EndTime, and the expected process/file-operation markers in the ETL. This provides documented loss evidence that ProcMon’s public interface does not.

References

1. Process Monitor - Sysinternals | Microsoft Learn
2. Troubleshoot Apps failing to start using Process Monitor
3. Troubleshoot Database Mail issues
4. WPR How-to Topics
5. WPR Command-Line Options
6. EVENT_TRACE_PROPERTIES structure (evntrace.h)
7. TRACE_LOGFILE_HEADER structure (evntrace.h)
8. Troubleshoot processes and threads by using WPR and WPA