Registry transaction logs

Location & availability

Companion .LOG1/.LOG2 files and other recovery files associated with a registry hive

Recovery depends on matching hive/log versions and collection consistency. Preserve originals before replay.

Fields to examine

• The source hive and exact matching companion files.
• Sequence/recovery context and parser outcome.
• Recovered values with their provenance.

What it can establish

• Help reconstruct a supported recoverable hive state.

What it cannot prove

• Supply an independent timestamp for every historical registry change.
• Justify combining arbitrary logs with a different hive from another machine or date.

Use it in a screenshare

1. Collect the hive and available companion files together and hash the originals.
2. Replay only on analysis copies using a compatible parser, recording whether recovery occurred.
3. Compare recovered values with unrecovered state and other artifacts. Distinguish transactional recovery from speculative recovery of deleted cells.

Worked example

A parser recovers a recent Amcache value after replaying matching logs. Document that recovery path and source set. The recovered inventory value still does not become proof of execution.

Cross-check the finding

• Amcache →Show that Windows inventoried a file or application identity.
• BAM →Support recent executable activity associated with a Windows user SID.
• RecentDocs →Support a retained recent-document association in a profile.

Sources

• RECmd — registry parser and batch definitions ↗