Live processes and loaded modules

Location & availability

Process Explorer or another trusted process/module inspection view

The state is volatile. Protected processes or insufficient privileges can limit visibility.

Fields to examine

• PID, image path, command line and process-start context.
• Parent relationships with time and PID-reuse caveats.
• Loaded module paths and exact file identities where available.

What it can establish

• Support that a process or module was visible at the observation time.

What it cannot prove

• Prove malicious injection merely from a DLL’s presence.
• Rule out earlier or hidden activity from a clean snapshot.

Use it in a screenshare

1. Record the time and capture the current state before restarting the game or stopping processes.
2. Identify the actual game path and command line, then inspect relevant modules and identities.
3. Check legitimate overlays, recorders, accessibility software and anti-cheat components. Correlate unusual modules with file bytes and other telemetry.

Worked example

An unfamiliar module belongs to a known capture application and its bytes match the installed release. Report that identity and context. A matching name alone would have been insufficient to identify it.

Cross-check the finding

• Sysmon event logs →Link configured process telemetry and subsequent events through ProcessGuid.
• Windows Error Reporting →Support that an application encountered the reported failure.
• Game and launcher logs →Support the application’s recorded description of a particular instance/session.

Sources

• Microsoft — Process Explorer ↗