Exhaustive logical mapping of SCCA/MAM structures, from legacy XP to compressed Windows 11 builds.
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.
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. |
How sophisticated adversaries try to defeat Prefetch as evidence — and how an investigator catches each play:
| 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, USN Journal — and look for EnablePrefetcher tampering in the registry. |
| 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. |
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-Eye