TL;DR. Open the Windows Timeline Parser, drop ActivitiesCache.db and ActivitiesCache.db-wal (or the whole profile folder, or a KAPE/Velociraptor ZIP), read the warnings, then filter by type: Opened for files, In use for focus time, Clipboard for copied text, Pending operations for deletions. Open any row for the raw JSON. Export CSV or JSON. Everything runs locally in WebAssembly; nothing is uploaded.

This is the practical companion to the complete guide to Windows Timeline forensics. It assumes you already have the files; if not, start with where ActivitiesCache.db is stored and how to acquire it.

Before you start

You need	Why
A copy of `ActivitiesCache.db`	The checkpointed database
The matching `ActivitiesCache.db-wal`	The newest committed activity (why)
The `Users\<name>\` path kept in the collection	Attribution of each database to an account
A current desktop browser	The parser runs as WebAssembly in a Web Worker

The parser is read-only by construction: it reads bytes, it has no SQLite engine and no code path that writes to your files. You still work on copies, because that is good practice for any tool.

Step 1: Collect the database with its WAL

Take the whole ConnectedDevicesPlatform folder for each user. A KAPE WindowsTimeline target or a Velociraptor collection already does this (KapeFiles target). Hash what you collected.

Step 2: Open the tool and load the files

Go to the tool home page. You can:

Drop files: ActivitiesCache.db plus ActivitiesCache.db-wal.
Drop a folder or use Choose a folder: the tool finds every ActivitiesCache.db and pairs each with its WAL.
Drop a ZIP: triage archives are opened in the browser, including nested ZIPs; unrelated files are counted and ignored.
Try a sample: a synthetic database from a fictional intrusion, with the last actions left in the WAL. Useful to learn the interface before touching evidence.

The account is taken from Users/<name>/ in the path, or from the L.<name> folder for local accounts.

Step 3: Read the warnings and the counters

Do not skip this. The warnings tell you whether the timeline is complete.

Message	Meaning	What to do
No -wal file for this database	Recent activity is probably missing	Go back to the collection and find the WAL
The -wal file does not match this database	WAL from another moment or database; ignored	Re-collect both files together
N frame(s) of an uncommitted transaction ignored	Normal on a live system	Nothing; note it
Starts with zeros	The file was locked or being written when copied	Re-collect with a raw-disk tool
WAL file without its ActivitiesCache.db	Collection too narrow	Collect the database

The counters give you the shape of the data: Accounts, Activities, Only in the WAL, Clipboard items, Deletions, Flagged. A large "Only in the WAL" number on a live-collected system is expected; zero on a live system is a reason to double-check that the WAL was collected.

Step 4: Filter by question

Question	Filter
Which files did the user open?	Type Opened (app / file)
Which app did they actually work in, and for how long?	Type In use (focus), sort by the Focus column
What did they copy?	Type Clipboard, then Copy / paste for the events
Did they remove entries from Timeline?	Type Pending operations, look for Operation: delete
Anything touching USB, shares or odd folders?	Flagged only
A specific file, host or date	The text filter (matches app, file, text, clipboard and date)
Several users or machines	The database selector (All databases by default)

Flags are heuristics, not verdicts: Clipboard, Only in WAL, Changed in WAL, Deletion, User-writable folder (AppData, Downloads, Desktop, Public, ProgramData, Windows\Temp, Recycle Bin, PerfLogs), Other drive (USB?) for a drive letter other than C:, and Network path for UNC paths. Their job is to point you at rows worth reading.

Step 5: Inspect a row

Open any row to see:

The resolved application (known folder GUIDs rendered as %ProgramFiles%, %SystemRoot%\System32, ...) and the app display name.
The file or folder path decoded from contentUri.
The clipboard text, decoded from Base64.
Start, end, focus duration, last modified, expiry and, for operations, when the operation was created.
The user time zone from the payload.
The WAL status: in the checkpointed database, only in the WAL, or changed in the WAL.
The raw Payload and AppId JSON, pretty-printed, for anything the table does not show.

Field meanings are in ActivitiesCache.db activity types and payload fields.

Step 6: Set the time zone and export

The UTC / Local toggle changes the display. Pick one and state it in your notes. Exports:

CSV: one row per activity with UTC time columns, type, app, file path, clipboard text, WAL status, flags, owner and source file. Cells that start with formula characters are neutralised so the file opens safely in a spreadsheet.
JSON: every decoded field (including Group, Tag and IsLocalOnly), plus per-source metadata: path, owner, WAL frame counts, tables and parser warnings.

Exports contain only the rows that match your current filters. Clear the filters first if you want everything.

What the tool does not do (yet)

It does not carve deleted records from free pages or stale WAL frames.
It loads each database fully in memory, so very large collections are limited by the browser.
It has been built against the documented schema and synthetic fixtures; validate important findings with a second parser such as WxTCmd. See ActivitiesCache.db parsers compared.

How to Analyze ActivitiesCache.db in Your Browser