Where does Windows store prefetch files?

Windows writes them to C:\Windows\Prefetch\. A healthy workstation contains hundreds of .pf files. The folder is readable by administrators.

Why is each prefetch file named with an 8-character hash?

The hex suffix is a hash of the full executable path encoded in UTF-16. Two copies of the same binary launched from different folders therefore produce two different prefetch files.

Does parsing a .pf file upload anything?

No. The parser compiles a pure-Rust SCCA decoder to WebAssembly and runs it in a Web Worker. The bytes stay in the browser — there is no backend and no telemetry on file contents.

Which Windows versions are supported?

Every SCCA version from Windows XP through Windows 11: v17 (XP/Vista/7, uncompressed), v23 (Win8), v26 (Win8.1), v30 (Win10) and v31 (Win11). Compressed and uncompressed files are detected automatically.

Understanding Windows Prefetch

Windows Prefetch .pf files live in C:\Windows\Prefetch\ and record metadata about every executable the OS has launched on a workstation host. They are the most reliable execution artifact most analysts touch in a normal week. A binary does not need to be installed, persistent, signed, or even still present on disk for its .pf to remain.

Each .pf is named <EXECUTABLE>-<HASH>.pf. The eight hex characters are a hash of the full launch path encoded in UTF-16, prefixed with \DEVICE\HARDDISKVOLUME{n}\. The byte contents of the binary itself never enter the hash. Two copies of an identical binary at C:\Program Files\Tool\tool.exe and C:\Users\victim\AppData\Local\Temp\tool.exe produce two different .pf files. That property is exactly why Prefetch can distinguish a legitimate vendor binary from the same binary dropped into a user directory.

What a parsed `.pf` actually contains

For every .pf dropped into the parser, you get:

Executable name as recorded in the SCCA payload.
SCCA version number. v17 on XP/Vista/7, v23 on Win8, v26 on Win8.1, v30 on Win10, v31 on Win11. The version tells you which header layout applies and how many last-run slots exist.
Run count. Monotonic. SysMain only increments it; a value that decreases between collections is impossible under normal Windows behavior.
Last-run times. Up to eight FILETIME values on v26+, one on earlier versions. Each is a u64 of 100-nanosecond ticks since 1601-01-01 UTC, in UTC, marking when Windows began monitoring the process.
Volume information. Device path, NTFS serial number, and creation timestamp for every volume the binary referenced. The serial number is the same one LNK files and the MFT record.
File-metric list. Every path Windows traced during the first ten seconds of monitored execution: DLLs, configuration files, data files, anything that produced a page fault on a file Windows knew about. Typically a few hundred entries on a real application.

That is enough to answer "did this binary run, when, from where, and what did it touch" — which is roughly 70% of the execution questions on a normal engagement.

Why client-side WebAssembly

.pf files are evidence. Uploading them to a third-party web service to parse them defeats chain of custody and exposes file paths, volume serials, and user profile directory names that can be sensitive on their own. The parser on this site compiles a pure-Rust SCCA decoder (frnsc-prefetch) to WebAssembly and runs it in a Web Worker inside the browser. The bytes never leave the machine. No upload endpoint, no telemetry on file contents.

The equivalent desktop tools are PECmd (Eric Zimmerman, .NET) and libscca (libyal, C with Python bindings via pyscca). Use whichever fits your pipeline. For a quick triage on a host you would rather not install anything on, the browser parser is faster than provisioning a tooling VM.

The Win8+ compression problem

Starting with Windows 8, SysMain compresses .pf files before writing them to disk. Each file begins with MAM\x04 followed by a u32 uncompressed-size field, then an Xpress Huffman compressed payload. Tools that pre-date Windows 8 and have not been updated will read the MAM bytes as the start of an SCCA header and silently produce wrong output. If a parser claims to support Windows 10 but cannot read your files, the first thing to check is whether it has an Xpress Huffman decoder in the pipeline at all.

The parser on this site detects MAM-compressed and legacy uncompressed files automatically. The MAM framing has not changed since Windows 8; only the SCCA payload inside it has.

How to read what you get

For triage, sort by NTFS creation time descending and look at the recent entries first. Sort by run count ascending and look at the single-execution binaries — these are usually more interesting than the ones that ran a hundred times. For each candidate, expand the file-metric list and look for DLL load paths in user-writable directories, references to documents that match a phishing claim, or configuration files in \AppData\Roaming\ that match known malware patterns.

Then corroborate. Prefetch alone proves a process started. It does not prove who started it, with what arguments, or that the binary on disk now is the binary that ran. Pair with AmCache for the SHA-1, Shimcache for path corroboration, the USN journal for when the binary appeared on disk, and the Security or Sysmon EVTX for command-line and user context. The dedicated Prefetch-as-evidence post walks through the full workflow.

Try it

Drop a .pf or an entire C:\Windows\Prefetch\ directory into the parser. You get a sortable, searchable table of every execution with drill-down into volumes and the file-metric list. Hit Download JSON to export structured output for jq, a notebook, or your case timeline.