Windows Timeline Limitations and Anti-Forensics
Where Windows Timeline evidence runs out: expiry, settings, cleared history, deleted rows, WAL gaps and parser limits, plus how to detect deliberate tampering.
TL;DR. Timeline evidence runs out in six predictable ways: expiry (30 days; 12 hours for clipboard), settings (collection off by user or policy), clearing (Clear history, removed entries), deletion of the file, a missing WAL, and parser limits (no carving of free pages or stale WAL frames). Each leaves traces somewhere: ActivityOperation delete rows, the Metadata table's database creation time, the USN journal, shadow copies, registry settings. Absence of Timeline rows is never, on its own, evidence that nothing happened.
Knowing where an artifact stops is what separates a finding from a guess. This is the list for Windows Timeline, with the counter-check for each.
Natural limits
Expiry
Each row has an ExpirationTime. kacos2000 measured it at exactly 2,592,000 seconds (30 days) after LastModifiedTime for normal activities, and 43,200 seconds (12 hours) for clipboard content (kacos2000). An activity that keeps being updated keeps moving its expiry forward; a one-off file open from six weeks ago is gone from the live table.
Counter-check: shadow copies and backups of the profile; SRUM, which has its own, independent retention; Jump Lists and LNK files, which have no time-based expiry field.
Coverage
Timeline records user-facing activity (apps, files, pages), not every process (Microsoft Support). A tool run from a service, a scheduled task or a remote shell without a desktop window has no reason to appear. The activity types themselves are researcher observations, not a public specification: several type numbers remain unexplained (kacos2000/WindowsTimeline).
Counter-check: Prefetch, AmCache, process-creation events in EVTX.
Windows 11
The Timeline view was retired in Windows 11 (Microsoft Support) and how much the database still receives varies. See Windows 11 Timeline: is ActivitiesCache.db still useful?
Time
Timestamps are Unix seconds in UTC, set by the local clock. A wrong system clock produces wrong times; there is no independent time source inside the database. userTimezone in the payload records the zone at activity creation (Microsoft Graph), which helps when a laptop travelled.
Deliberate anti-forensics
| Action | Effect on ActivitiesCache.db | What it leaves behind |
|---|---|---|
| Turn off "Store my activity history on this device" | New activity stops being recorded | Settings state in the user hive; a gap in rows while other artifacts continue |
Group Policy / MDM (EnableActivityFeed, PublishUserActivities) | Publishing of user activities disabled (Privacy CSP) | Policy values in the SOFTWARE hive |
| "Clear activity history" | Rows removed for the account (Microsoft Support) | Freed database pages, WAL frames, a sudden start of the timeline |
| Remove a single entry (Windows 10 Timeline) | Entry copied to ActivityOperation with a delete status (kacos2000) | A queued delete operation with its own CreatedTime |
| Delete the database file | Windows recreates it | USN journal entries; the Metadata table's DatabaseInstanceIdUpdateTime, which kacos2000 identified as the database creation time (kacos2000) |
| Edit the database with a SQLite client | Rows changed or removed | Depends on settings: deleted content may remain in free space unless secure_delete is on (SQLite PRAGMA) or the file was rebuilt with VACUUM (SQLite VACUUM) |
The delete operation is a gift
The most common clean-up, removing an embarrassing entry, is also the most visible. The ActivityOperation table keeps the operation with operation type 3, the activity's Id, and the time the deletion was queued. In the Windows Timeline Parser, these rows are flagged Deletion and dated by their creation time, not by the start time of the activity they target, so they sit in the timeline where the clean-up happened.
kacos2000 describes a subtlety: for Microsoft accounts, the deleted-status entries sit in ActivityOperation only until they sync, after which they move back to Activity until expiry (kacos2000). With cloud sync of activity history ended for Microsoft accounts in 2021 and Entra ID accounts from January 2024 (Microsoft Support), how this behaves on current systems is worth testing rather than assuming. Check ActivityStatus in Activity as well.
Signs the database was reset
- The earliest row is much newer than the profile, while SRUM and Prefetch show activity for the same user earlier.
- The
Metadatatable's creation time is recent. - The USN journal shows
ActivitiesCache.dbdeleted and recreated (USN parser). - A volume shadow copy holds a larger, older database.
Collection failures (the self-inflicted kind)
| Failure | Result | Fix |
|---|---|---|
| WAL not collected | Newest activity missing, updated rows show old values | Collect ActivitiesCache.db* (acquisition) |
| Database and WAL from different moments | Mismatched frames; a careful parser ignores the WAL | Collect both in one pass or from a shadow copy |
| Originals opened with a SQLite client | WAL checkpointed and deleted on close (sqlite.org) | Hash, then work on copies |
| Only one account folder collected | Activity under another account type missed | Collect the whole ConnectedDevicesPlatform folder |
Parser limits (this tool included)
Being explicit about the tool is part of being explicit about the evidence. The Windows Timeline Parser today:
- Parses live rows from
Activity,ActivityOperationandActivity_PackageId, with committed WAL transactions applied. - Does not carve deleted records from freeblocks, freelist pages or WAL frames from an earlier salt generation. It reports why WAL reading stopped (for example "belongs to an older WAL generation") but does not extract those frames.
- Does not parse the
Metadata,ActivityAssetCacheorAppSettingstables. - Shows the
Groupcolumn (Copy / Paste) in the JSON export, not in the table. - Loads each database into browser memory.
- Has been tested against real SQLite files built to the documented schema; cross-check critical findings with a second parser (parsers compared).
For deleted-record recovery, SQLite research tools such as bring2lite analyse freelists and the WAL (Meng and Baier, 2019), and kacos2000 publishes clipboard carving tools (kacos2000/WindowsTimeline).
FAQ
Can a user delete their Windows Timeline history?
Yes. Windows offers a Clear history button for activity history, users could remove individual Timeline entries on Windows 10, and the setting to store activity history can be turned off. Removing an entry leaves a queued delete operation in ActivityOperation, which is itself evidence.
How long does Windows Timeline keep activity?
Rows carry an ExpirationTime. Researchers measured it at 30 days after the last modification for normal activities and 12 hours for clipboard content.