Exhaustive logical mapping of the Windows Prefetch file format — the SCCA (Windows Superfetch/Prefetch Cache file) and MAM (Microsoft compression, the MAM container Windows 10 wraps it in) structures, from legacy XP to compressed Windows 11 builds — and what each field proves about program execution.
C:\Windows\Prefetch\ after each program launch. It captures every DLL, data file, and disk block the program touched in its first ~10 seconds. For investigators, it is a tamper-resistant receipt of execution.
C:\Windows\Prefetch\ under the name EXECUTABLE.EXE-XXXXXXXX.pf (the XXXXXXXX is a hash of the executable's full path). On the next launch, Windows reads the recording and pre-stages the same blocks into RAM so the program starts faster.
.pf file exists because the kernel traced a process starting from that image path, and it carries up to eight run times, a run count, and every file the process loaded along the way — even if the binary itself has since been deleted. What it does not settle is who started it, or whether the run succeeded; those limits are set out in what a Prefetch file supports, and what it does not.
Select any field in the map to reveal a deep forensic dive.
Windows Prefetch evolved from a simple binary table in XP to a complex, compressed database in Windows 11. It remains one of the most critical artifacts for proving Application Execution history, as it records exactly what files were loaded into memory during the first 10 seconds of a process's life.
Modern versions (v30+) utilize MAM compression (XPRESS Huffman), wrapping the forensic payload to save disk space. To parse these, an investigator must first strip the 8-byte MAM header and decompress the remaining payload to reveal the original SCCA structure.
Prefetch is not a security feature. It is a performance optimization driven by the Windows Cache Manager. Every time an executable launches, the kernel quietly traces its first ten seconds of disk I/O — every DLL imported, every configuration file opened, every data file mapped — and persists that trace to disk. On the next launch, the Cache Manager replays the trace ahead of the process, pre-paging the same blocks into RAM so the program "feels" faster.
This optimization side-effect is what makes Prefetch one of the most reliable execution-evidence artifacts on Windows. The file is written after the process runs, by the kernel, into a system-protected directory. Anti-forensic actors can delete it, but they cannot easily forge one without leaving secondary indicators — mismatched timestamps in $MFT, inconsistent run counts, or a missing entry under HKLM\..\PrefetchParameters.
The lifecycle of a single .pf file:
C:\Windows\Prefetch\<EXE>-<hash>.pf.Prefetch shipped with the original release of Windows XP and has been continuously refined for over two decades. Each major Windows generation bumped the on-disk format version, changing structure sizes and adding fields — which is why a single parser must dispatch on the 4-byte Format Version field at offset 0.
sysmain) is layered above the kernel prefetcher to model usage patterns by hour-of-day. The on-disk format grows: FileMetric structs are now 32 bytes with an 8-byte NTFS MFT reference per file, the volume entry expands to 104 bytes, and the file gains a much larger File Information block. Single Last Run Time is retained. Cap remains 128 .pf files.loaded_block_count. The retention cap is raised 8× to 1024 .pf files, dramatically extending the historical window available to forensic analysis.Microsoft.XboxGamingOverlay_8wekyb3d8bbwe). FileMetric and trace structs are tightened: trace is now 8 bytes, dropping the older next_array_entry_index and loaded_block_count fields. Cap stays at 1024. Two sub-variants exist (v30v1 with metrics offset 304, v30v2 with offset 296).0x1F. MAM/XPRESS Huffman compression remains, the 8-slot timestamp array stays, and the Hash Pool string continues to carry AUMIDs for Modern Apps. Cap remains 1024 .pf files — the same effective historical window as Windows 8.When the per-version cap is reached, Windows evicts the least-recently-modified .pf file to make room for a new one. This means the contents of C:\Windows\Prefetch\ at any moment is essentially a rolling window of the most recently executed binaries on the system.
Location. Every .pf file lives in a single, system-protected directory:
Filename pattern.
The 8-hex-digit suffix is a hash of the full Unicode path to the executable. Two copies of the same binary launched from different paths produce two different .pf files — an investigator can spot side-loaded or dropped duplicates this way.
Common examples:
NOTEPAD.EXE-AF43252D.pf — classic NotepadCMD.EXE-0BD30981.pf — Command PromptPOWERSHELL.EXE-022A1437.pf — PowerShellNTOSBOOT-B00DFAAD.pf — the special boot trace, regenerated on every bootEnablePrefetcherPrefetching is governed by a single REG_DWORD value. A change here is one of the first things an investigator checks during an anti-forensics review:
| Value | Behaviour |
|---|---|
| 0 | Disabled — no .pf files written. Red flag in an IR engagement. |
| 1 | Application-launch prefetching only. |
| 2 | Boot prefetching only (NTOSBOOT). |
| 3 | Both — the Windows default on workstation SKUs. |
A sibling value, EnableSuperfetch, governs the Vista+ SuperFetch user-mode service. Modern Windows 11 disables SuperFetch automatically on SSDs — this is benign and not the same as EnablePrefetcher = 0.
| Offset | Size | Field Name | Forensic Meaning & Value |
|---|
| Bit | Definition | Significance |
|---|---|---|
| Bit 0 | IsBootFetch | Identifies if the prefetch was created during system boot (NTOSBOOT). |
| Bit 1 | Encrypted | Rarely seen; indicates the SCCA payload uses basic XOR encryption. |
| Bit 2 | AppLaunch | Standard application launch prefetch (Default). |
| Bit 3 | IsGapped | Indicates non-contiguous file read operations. |
| Mask | Flag Name | Forensic Result |
|---|---|---|
| 0x01 | IsDirectory | Entry represents a directory instead of a file. |
| 0x02 | IsVolumePath | Path is relative to the volume root. |
| 0x04 | PreLoad | Resource was pre-loaded by Cache Manager. |
Prefetch is the artifact most often asked to carry a whole allegation on its own. It is strong evidence of execution and weak evidence of almost everything around it:
The kernel begins tracing when the image is loaded. A program that started and failed
immediately — a missing DLL, a crash on launch, a denied privilege — leaves a
.pf file that looks exactly like a successful run. The run count rises either
way. Prefetch answers "this image was launched from this path"; whether the launch achieved
anything is a question for the event log, the registry or the files it touched.
The format carries no SID, no session and no parent process. A file in
C:\Windows\Prefetch\ is machine-wide: on a multi-user host it does not say
which account ran the program, and on any host it does not distinguish a person launching it
from a scheduled task, a service or another process spawning it. Attribution needs a logon
session or a process-creation event alongside the run time.
Windows keeps a bounded number of .pf files — 128 on Windows 7 and
1024 on Windows 8 and later — and discards the oldest. Prefetch can be disabled
outright through EnablePrefetcher, is off by default on many SSD-era server
builds, and never covers a process that ran from a path Windows does not trace. A missing
.pf means the artifact is not there, not that the program never ran.
Windows 8 and later keep the last eight run times; Windows 7 keeps one. A program run fifty times shows its most recent eight and a run count of fifty — so the count and the timestamps answer different questions, and the gap between the oldest kept timestamp and the file's own creation time is unaccounted activity, not idle time.
What it is genuinely good for: the loaded-file list. No other artifact records what a process actually reached for in its first seconds — every DLL, configuration file and data file the loader touched, with its full path. That list survives the deletion of the binary, names the directory the program really ran from, and routinely exposes a second stage or a staging directory that nothing else on the machine points at.
How sophisticated adversaries try to defeat Prefetch as evidence — and how an investigator catches each play:
Table 5| Technique | Indicator in Prefetch | Counter-detection |
|---|---|---|
| Selective .pf deletion | A known-executed binary has no Prefetch entry, yet other evidence proves execution. | Cross-reference against Amcache, ShimCache, Event Log 4688/4689 and the USN Journal, and look for EnablePrefetcher tampering in the registry. Explained in full: ShimCache |
| Prefetcher disabled via registry | Whole C:\Windows\Prefetch\ directory is empty or sparsely populated post-incident. |
Inspect HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher. 0 = disabled, 3 = default. Any recent change is a red flag. |
| FILETIME timestomping | Last Run Times all zero, all identical, or set to obviously stale / future values. | Compare slot 0 against $MFT creation / modification times for the same binary; nation-state actors rarely sync all three artifacts. |
| MAM header corruption | Crow-Eye logs Error decompressing Windows 10/11 prefetch and the file fails to parse. |
Manually carve the SCCA payload starting at byte 8 (after the 8-byte MAM header) and attempt direct decompression with dissect.util.compression.lzxpress_huffman. |
| Run-count clipping | run_count = 1 but multiple non-zero Last Run Times exist (or vice versa). |
Crow-Eye sanity-checks this in save_to_sqlite(); mismatched counts surface in the DB and warrant a closer look at the timestamp array. |
| Living-off-the-land hiding | Suspicious DLL loaded by a signed Windows binary (e.g. rundll32.exe, regsvr32.exe); the .pf filename looks benign. |
Walk the resources column — the MFT references to loaded DLLs survive even when the binary itself is signed and trusted. Look for unusual %APPDATA% / %TEMP% DLL paths. |
| External-media wiping | A volume serial number is referenced but the drive is no longer present. | The volume's creation FILETIME plus the loaded paths still survive in Prefetch. Useful for proving USB-borne tooling was present even after the device is gone. |
The Charts button on the Prefetch table tab opens a dashboard over
prefetch_data.db — every program that ran, when
(its up-to-eight run times), how often, from where, and what it loaded. The colour language is
run location: where the .exe itself ran from — the first thing to
check, because malware runs from Temp / AppData, not System32.
| Location | The .exe ran from | Colour |
|---|---|---|
| System | C:\Windows\… | blue |
| Program Files | C:\Program Files / (x86) | green |
| User / AppData / Temp | \Users\…\AppData, \Temp, \Downloads — the suspicious space | amber |
| Removable / other volume | a non-C: drive, or a volume the header marks Removable / Network | rose |
| Other | ProgramData, root, … | purple |
The exe's full path is the entry in the program's resources list whose name matches the executable — that path decides the colour.
Left — five run-location strips (a cell per day, location = colour) built from every run time across all programs; click a day for the drill-down: runs-by-hour (stacked by location), top programs, top directories, and an execution list (time · location · program · path · run count). Right — the overview: totals, an Insights card, the most-run programs, a by-location breakdown, and a Volumes (execution device history) card.
Click a day to fill the
drill-down, or a program (in the executions list or the most-run list) for its full
profile: every run time, its run count, the exe path and volume/serial, the
.pf file's own MAC times, and the full loaded resources list —
with the files and DLLs loaded from outside System / Program Files highlighted, so a
side-loaded or injected module stands out. Filters: search, a location and a
volume selector, and a date dropdown.
Crow-Eye decodes Prefetch (SCCA), including Windows 10/11 MAM-compressed files, to recover run counts, the last-eight run times, and the files each program loaded — hard evidence that a binary actually ran.
Download Crow-EyeIn C:\Windows\Prefetch. Each file is named after the executable followed by a hash of the path it ran from, such as NOTEPAD.EXE-D8414F97.pf, so the same binary run from two locations produces two separate .pf files.
It is strong evidence that the binary ran on that system, and the run count and execution timestamps say how often and when. The absence of a .pf file proves much less: prefetching can be disabled, the folder is capped and evicts the least recently used entries, and some server builds ship with it off.
Windows XP through 7 keep up to 128; Windows 8 and later keep up to 1024. When the cap is reached the least recently modified .pf file is evicted, so the folder is a rolling window of recent execution rather than a complete history.
From Windows 8 onward a .pf file stores the last eight execution times rather than one, so a single artifact can show a pattern of runs. Earlier versions store only the most recent execution.