UserAssist & user context
Investigate user-specific shell activity without assuming it captures every launch or identifies the person at the keyboard.
Question & scope
UserAssist records are useful for examining user-specific shell activity. The relevant data lives within user registry context, commonly in NTUSER.DAT. Establish which user hive you collected and which profile it belongs to before discussing an application entry. Data formats, counters, and recorded fields vary, so use a parser that explains its interpretation for the collected system.
In a shared gaming computer, the Windows profile, game account, and person operating the machine may be different entities. Keep those identities separate. A user-specific record helps locate context; it does not alone authenticate the human who performed an action.
What to collect
| Source | Retain and examine |
|---|---|
| User hive | NTUSER.DAT and relevant transaction logs from the examined profile. |
| Profile mapping | SID, profile path, and how it relates to the observed session. |
| Parsed entry | Decoded name, supported timestamps or counters, and raw record location. |
| Session sources | Game logs, launcher information, and available Windows logon or execution data. |
Examination workflow
- Identify the actual Windows profile associated with the displayed game instance.
- Collect the user hive and logs without modifying registry values to expose a record.
- Decode and parse UserAssist using a documented implementation, preserving the raw source and parser output.
- Resolve shell identifiers, paths, or aliases with other profile information; do not silently substitute a guessed executable name.
- Compare the relevant entry with session time and independent execution records, describing coverage limits in the report.
Interpretation & false positives
UserAssist is not a complete process-start log. Command-line launches, services, different accounts, and other mechanisms may have different coverage. A parser label such as run count should be interpreted according to the field and version, not assumed to count every lifetime execution.
Decoded names can contain shell-specific identifiers instead of a direct filesystem path. Resolve them cautiously and record the mapping method. An entry in one profile does not establish the state of another profile. Missing data can reflect coverage or collection gaps as well as removal.
Worked scenario
The active game is running from a secondary profile, but a viewer shows UserAssist data for the main account. That output may be genuine and still irrelevant to the disputed session. Collect the correct profile context before comparing entries. If identity remains uncertain, state that limitation rather than assigning activity to the player.
Report checklist
- The source hive and profile mapping are recorded.
- Decoded names retain their source context.
- Counters are not treated as comprehensive lifetime history.
- Profile activity and personal attribution are separated.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.