Process Monitor 4.12: supported Runtime exit status and file-backed log finalization

Open the preserved PML with Process Monitor 4.12 and export All events to a separate CSV or PML; this is the supported offline validation path, whereas /Runtime exit-code meanings and finalization guarantees are not publicly documented.

Validate the retained PML without changing it

1. Keep the original PML read-only and work from a copy. Record the copy’s hash before testing.
2. Start the same signed Procmon64.exe interactively.
3. Use File → Open and select the copied PML.
4. If it opens successfully:
   • Note the event count displayed by Process Monitor.
   • Clear display filters if necessary so the validation covers the complete capture.
   • Select File → Save.
   • Choose All events, then save to a different path as CSV.
   • Optionally also save All events as Native Process Monitor Format (PML) to a new file.
5. Compare the CSV’s event count and final fixture events with the expected operation sequence. Do not treat your reverse-engineered reader’s 0x71 result as a PML integrity verdict.
6. Hash the original again afterward. Opening and exporting to another path should leave your evidence file unchanged; the hash check independently verifies that it did.

Microsoft’s troubleshooting guidance directs analysis by opening the recorded trace in Process Monitor, and identifies All events plus Native Process Monitor Format (PML) as the complete-save selection. It also states that a file-backed capture does not require a separate manual save before Procmon exits.^1^ Process Monitor describes PML as its native format preserving captured data for later loading.^2^

A successful native open and export is the narrowest supported parser-level check available for this retained file. It can establish that Procmon 4.12 accepts and can enumerate the file; it cannot independently prove that every event generated before shutdown reached the file. If native open or export fails, preserve the original and submit the zipped PML—with its hash, Procmon binary hash, exact command, OS build, and launcher timeline—to Microsoft Support. Microsoft’s published Procmon workflow likewise directs users to zip PML captures for support analysis.^3^

/Runtime exit status

The available Process Monitor 4.12 documentation does not publish:

• the expected process exit value for ordinary /Runtime 20 expiry;
• a table assigning meanings to nonzero values;
• a statement that all nonzero values represent capture failure; or
• a guarantee connecting exit value zero—or process exit generally—to PML structural completeness.

Consequently, the wrapper’s nonzero observation cannot be classified now because the actual value was not retained. Its own exit code 2 has no Procmon meaning.

For the next occurrence, retain at least:

• the unsigned 32-bit exit value and hexadecimal representation;
• whether the process exited naturally or through the job/watchdog;
• start, resume, runtime-expiry, and exit timestamps;
• standard output/error, even if normally empty;
• any Application Error or Windows Error Reporting event.

Windows defines a process exit code as the value returned by its entry point or supplied to ExitProcess/TerminateProcess; a fatal exception can instead become the exit code.^4^ That explains how to preserve the value, but it does not supply Procmon-specific semantics.

Does /Runtime prove finalization?

No published Procmon contract establishes that /Runtime completion is a durability or finalization barrier for every PML index and tail structure. The observed 20.82-second lifetime is consistent with bounded execution, but it does not by itself establish completeness.

Microsoft documents that file-backed recording writes directly to a file and does not require the manual save required by virtual-memory backing.^1^ That documented behavior should not be extended into an undocumented guarantee about internal PML-v9 layout, index construction, cache flushing, or /Runtime.

Suspended, job-contained launch

Creating a process suspended, assigning it to a job, and then resuming it is a documented Windows mechanism. AssignProcessToJobObject specifically documents suspended creation for certain job security configurations.^5^ However, no Procmon documentation establishes this launcher arrangement as a supported or tested Procmon automation contract.

The job can materially affect termination:

• JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE terminates associated processes when the last job handle closes.^6^
• Job limits apply after assignment, and nested-job or breakaway behavior can affect child processes.
• Forced termination gives the process no opportunity to execute termination handlers or DLL detach processing.^4^

Your report says containment did not fire, so the job is not established as the cause of this attempt. It remains an uncontrolled variable for product-support reproduction. If escalation requires a minimal reproduction, use the documented direct elevated launch with -backingfile, then stop through Procmon’s documented -terminate -quiet path, outside the custom job wrapper.^1^ That would be a new capture and is not required for the first offline examination of the retained original.

References

1. Troubleshoot Apps failing to start using Process Monitor
2. Process Monitor - Sysinternals | Microsoft Learn
3. Troubleshoot Microsoft Defender Antivirus performance issues with Process Monitor
4. Terminating a Process
5. AssignProcessToJobObject function (jobapi2.h)
6. Job Objects