Unified binary stream mapping of the AutomaticDestinations-ms Jump List — the DestList stream and its modern Version 4 entries in Windows 11 — and what it proves about recently opened files.
Select any field in the map to reveal a deep forensic dive.
Automatic Jump Lists (.automaticDestinations-ms) are OLE Compound File Binary (CFB) containers used by Windows to track user productivity. They act like a mini-filesystem inside a single file.
Why Microsoft Created Them: To power the "Recent" and "Frequent" Taskbar categories. Instead of scanning the drive, Windows caches these links to provide immediate access to the user's workflow.
Forensic Value: They provide proof of file interaction, usage frequency, and exact target paths, even for deleted or wiped files. They are a master record of user activity.
| Offset | Size | Field Name | Forensic Meaning & Value |
|---|
| Offset | Field Name | Meaning |
|---|---|---|
| 0x00 - 0x03 | Version Number | Determines layout: 1 (Win 7/8), 3 (Win 10), 4 (Win 11). |
| 0x04 - 0x07 | Total Current Entries | Number of items currently tracked in the jump list. |
| 0x08 - 0x0B | Total Pinned Entries | Number of explicitly pinned items (never age out). |
| 0x10 - 0x17 | Last Issued ID | Total lifetime entries ever assigned (monotonically increasing). |
| 0x18 - 0x1F | Number of Actions | Total lifetime interactions across all items. |
Unlike Custom Destinations which are purely sequential LNKs, Automatic Destinations contain a central DestList index stream containing massive forensic value not found inside the individual embedded LNKs. Explained in full: the LNK format
Each row below is one field of a DestList entry: its name, and the single thing it lets an investigator say. Read them as a set — the identity fields place the entry on a machine, the time fields place it in a sequence, and the counter says how often it was refreshed.
Table 3| Key Field | Forensic Value |
|---|---|
| Object UUIDs | Birth is the object's first identity, New its identity after a move, so the pair traces a file across volumes. A version 1 UUID also encodes the MAC address of the machine that minted it — not every UUID here is version 1, so read the version nibble before attributing one. |
| NetBIOS Name | Records the %COMPUTERNAME% where the entry was created. Vital for attribution. |
| Last Access Time | Definitive event timestamp for jump list interaction, independent of LNK file times. |
| Access Counter | A counter the shell increments each time the entry is refreshed, so it separates a habitual working document from a single-use one. It counts the shell's own updates, not a person's openings, and it never decreases. |
The Application Identity (AppID) is not explicitly stored inside the Automatic Destinations format. The filename itself is the hex representation of the AppID (e.g., 1b4dd67f29cb1962.automaticDestinations-ms).
| AppID Hash | Target Application |
|---|---|
| 1b4dd67f29cb1962 | Windows Explorer |
| f01b4d95cf55d32a | Command Prompt (cmd.exe) |
| 5d696d521ea23821 | Google Chrome |
The Charts button on the LNK and Jump-List tabs opens the opened-files dashboard — LNK shortcuts, automatic and custom jump lists on one timeline, with a per-target profile and a volume/device-history trail. Documented in Reading the LNK / Jump-List dashboard.
Crow-Eye parses every AutomaticDestinations file — the DestList stream and its embedded LNKs — into a clean per-application file-access timeline, with no manual OLE compound-file carving.
Download Crow-EyeAn Automatic Jump List is the shell's own record of what an application was recently used with, and it survives the deletion of both the file and the application's own history. Three claims it does not carry:
The list is maintained by the shell, not by the application. Opening a document adds an entry — and so does pinning one, and so do some programmatic routes that never showed the file to a person. The access counter is the shell's count of those additions, not a count of times a human looked at the document.
The filename is a hash derived from the application's launch path, so two installs of the same program at different paths produce different AppIDs, and a single AppID can span versions. It says which program's recent list this is. It does not say which build ran, from where, or who was at the keyboard — that last one comes from the profile the file sits in, and nothing finer.
Windows keeps a bounded number of destinations per application and drops the oldest as new ones arrive; a user can also clear the list from the taskbar without touching any other artifact. A document with no entry may never have been opened in that application, or may have been opened long enough ago to have fallen off the end.
What it is genuinely good for: tying a file to the application that touched it, and to the machine it came from. No other artifact pairs a target path with the program that opened it as directly as the AppID does, and the embedded LNK stream carries the volume serial, the NetBIOS name and, where a tracker block survives, the originating machine — so a document can be followed back to a host that is not the one being examined.
In the user's Recent folder under AppData, in the AutomaticDestinations subfolder. Each file is named with the AppID of the application that created it, so the filename itself identifies which program the recent-file history belongs to.
An OLE compound file holding a LNK-format stream per recent item, plus a DestList stream that orders them by recency and records access counts - so it preserves both what was opened and roughly how often and in what order.
Jump Lists were introduced with Windows 7 and are present in later versions. They are absent from XP and Vista images, where the Recent folder's LNK files are the fallback.
A hash identifying the application. Published AppID lists map the value to a program, which is how a Jump List is attributed to, say, Word or Explorer rather than an unnamed process.