ActivitiesCache.db Location and Acquisition Guide

TL;DR. The database is C:\Users\<user>\AppData\Local\ConnectedDevicesPlatform\<account-folder>\ActivitiesCache.db. Collect the whole ConnectedDevicesPlatform folder for every profile, including ActivitiesCache.db-wal. On a live system use a raw-disk collector (KAPE's WindowsTimeline target, Velociraptor) or a shadow copy, and take the database and WAL together. Hash before you parse.

Getting the file is easy on a dead disk and surprisingly easy to get wrong on a live one. The two classic mistakes are copying the database without its WAL, and copying the two files at different moments. Both give you a timeline that looks fine and is quietly incomplete.

The path

Two details matter in practice.

One user, several account folders. kacos2000 observed that when a user switches from a local account to a Microsoft account, the L.<username> folder is removed and a new folder is created for the Microsoft account, with earlier entries carried over; switching back leaves the Microsoft account database in place (kacos2000). Do not stop at the first folder you find.

The folder name is not the user. For Microsoft and Entra ID accounts the folder name does not contain the username. Attribute the database from the profile path (Users\<name>\), and keep that structure in your collection. The ConnectedDevicesPlatform glossary entry summarises the naming.

Which files to take

SQLite states that the WAL file "is part of the persistent state of the database" and that separating the two can lose committed transactions (sqlite.org/wal.html). Treat the pair as one piece of evidence.

From a disk image

Dead-box acquisition is the clean case: nothing is holding the files open, and no checkpoint can happen while you work.

1. Mount the image read-only.
2. Export Users\*\AppData\Local\ConnectedDevicesPlatform\ recursively, preserving paths.
3. Hash every exported file.
4. Check each account folder for a -wal. A zero-byte or missing WAL on a disk image usually means the last connection closed cleanly and checkpointed (sqlite.org); note it, it is not an error.

Also look inside volume shadow copies if the image has them. An older snapshot can hold a database from before the user cleared history or before entries expired. The disk image parser and Recycle Bin parser cover the neighbouring evidence you will want from the same image.

From a live system

On a running machine the user's session has the database open. A normal file copy often fails with a sharing violation or, worse, succeeds on the database and not on the WAL.

KAPE. The WindowsTimeline target in KapeFiles collects ActivitiesCache.db* recursively under each user's ConnectedDevicesPlatform folder, which picks up the database, WAL and SHM in one go (WindowsTimeline.tkape). KAPE reads locked files through raw disk access.

Velociraptor. The Windows.Forensics.Timeline artifact defaults to C:\Users\*\AppData\Local\ConnectedDevicesPlatform\*\ActivitiesCache.db; its documentation marks it as deprecated in favour of Generic.Forensic.SQLiteHunter (Velociraptor docs). For file collection, use a glob that ends in ActivitiesCache.db* so the WAL comes along.

Shadow copy. Creating a new shadow copy and copying from it gives you a consistent, point-in-time pair. It changes the system, so record it in your notes.

Whatever you use, the rule is the same: the database and WAL must come from the same instant. A WAL from another moment can hold frames that do not match the database pages. The Windows Timeline Parser checks that the replayed result is still a plausible Timeline and ignores a mismatched WAL with a warning, but it cannot recover what a bad copy never captured.

Signs of a bad copy

The tool reports each of these explicitly: files that start with zeros, a WAL without its database, and an ignored -shm are listed under "Files not parsed", and a missing WAL raises a warning.

Attribution and chain of custody

• Keep Users\<name>\AppData\Local\ConnectedDevicesPlatform\<account-folder>\ intact in the collection. The tool attributes each database from Users/<name>/ or from the L.<name> folder; your report should do the same.
• Hash the collected files, then work only on copies. Opening the originals with a standard SQLite library can checkpoint the WAL into the database and delete it when the connection closes (sqlite.org), which changes the evidence.
• Record the system's time zone and the user's, then keep timestamps in UTC in your working notes.

Triage collections: what else to grab

If you are already collecting Timeline, the same run should take the artifacts that corroborate it: SRUDB.dat for SRUM, C:\Windows\Prefetch for Prefetch, AutomaticDestinations for Jump Lists, Recent\*.lnk for LNK files, user hives for registry evidence, and the event logs for EVTX. Timeline is strongest when it is one voice among several; see Windows Timeline vs SRUM vs Prefetch vs Jump Lists.

FAQ

Where is the Windows Timeline database stored?

In C:\Users\<user>\AppData\Local\ConnectedDevicesPlatform\<account-folder>\ActivitiesCache.db. The account folder is L.<username> for a local account and a different identifier for Microsoft or work and school accounts.

Do I need the -shm file?

No. The -shm file is a shared-memory index that SQLite rebuilds. Collect it if your tooling grabs it, but the evidence is in ActivitiesCache.db and ActivitiesCache.db-wal.

Can I copy ActivitiesCache.db from a running system?

Not with a plain copy while the user is logged on, because the file is typically held open. Use a raw-disk collector such as KAPE or Velociraptor, or a volume shadow copy, and take the database and its WAL at the same moment.

Next steps

Once you have the files, analyze ActivitiesCache.db in your browser, or start from the complete guide to Windows Timeline forensics.