Game and launcher logs

Location & availability

The instance path configured by the launcher; for Minecraft, the relevant logs and loader configuration

Launchers can use multiple profiles or custom directories. Rotated logs and relaunches can replace evidence.

Fields to examine

• Instance path, launcher profile and game/loader versions.
• Recorded session times and reported loaded components.
• Errors, rotation context and links to the examined files.

What it can establish

• Support the application’s recorded description of a particular instance/session.

What it cannot prove

• Guarantee the log is complete, authentic or a complete module inventory.
• Treat an empty default mods folder as the state of a different configured instance.

Use it in a screenshare

1. Identify the active instance from the launcher and live process context before selecting logs.
2. Preserve the relevant log set and configuration before relaunching. Compare reported component versions with actual files.
3. Align the session with independent execution or filesystem records, keeping wall-clock and log timezone assumptions explicit.

Worked example

A default mods folder is empty, but the launcher points to another instance whose log names installed mods. Examine that instance. The first folder observation did not describe the game actually used.

Cross-check the finding

• Live processes and loaded modules →Support that a process or module was visible at the observation time.
• USN Journal / $UsnJrnl →Support recorded file/directory changes and a sequence within retained journal coverage.
• Prefetch →Support execution of an associated executable within the retained history.

Sources

• Fabric — game log locations ↗