Mini-guide: what a Prefetch file proves, and the three things it cannot tell you

When somebody asks whether a program ran on a Windows workstation, Prefetch is usually the first place to look and often the best answer you will get. It is on by default, it survives the program being deleted, and it records when the program ran, not merely that it was present. This guide is what to read in a .pf file, in the order that settles questions fastest.

Where it lives and what it is called

C:\Windows\Prefetch\, one file per program, named after the executable and a hash: RCLONE.EXE-2B4F1A9C.pf. The hash is computed from the path the program ran from, so the same program run from two folders gets two files.

For a handful of hosting programs the hash also covers the command line, so several files for one name is normal: svchost.exe, dllhost.exe, rundll32.exe and mmc.exe among them. For anything else, two .pf files for one executable name means it ran from two places, and one of them may be where it does not belong.

What is inside

Field	What it gives you
Executable name	The file that ran
Run count	How many times the prefetcher recorded it
Last run times	Up to eight on Windows 8 and later, one on Windows 7. The most recent run and the seven before it
Volume information	The volume serial number and device path it ran from
Files referenced	Every DLL and data file the program touched in roughly its first ten seconds
Directories referenced	The folders behind those files

On Windows 10 and later the files are compressed. Parse them with a tool that knows that, such as PECmd, rather than a hex editor.

An illustrative reading

Invented, and trimmed, to show the shape of the output:

Executable name: SVCHOST.EXE
Hash: 5D2A1F07
Run count: 3
Last run: 2026-03-02 01:21:47
Other run times: 2026-03-02 01:19:03, 2026-03-01 23:52:10
Volume 0: \VOLUME{01d9...}  Serial: 7A3C1F22
Directories referenced:
  \VOLUME{01d9...}\USERS\PUBLIC
Files referenced:
  \VOLUME{01d9...}\USERS\PUBLIC\SVCHOST.EXE   (Executable)
  \VOLUME{01d9...}\USERS\PUBLIC\R.CONF
  \VOLUME{01d9...}\PROGRAMDATA\FIN.7Z

Three findings in eight lines. A svchost.exe ran from C:\Users\Public, which the real one never does. It ran three times, the first on the evening before. And in its first seconds it touched a configuration file and an archive, which tells you what it was for before you have found either file.

The three things it cannot tell you

Who ran it. Prefetch has no user field. Pair the run times with logon sessions from the Security log, or with the user's own artifacts such as UserAssist, to put a name on it.

What it was told to do. No command line. For that you need process creation logging, Sysmon event 1 or Security 4688 with command-line auditing, or the program's own logs and configuration.

That it did anything useful. A program that crashed immediately still gets a Prefetch entry. The files-referenced list helps here: a program that opened a target archive did more than start.

Where it runs out

Prefetch is disabled by default on Windows Server, so the servers you most want it on usually do not have it. It is controlled by the EnablePrefetcher value under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters, and a value of 0 on a workstation is worth asking about.

The folder keeps a limited number of files (1024 on Windows 8 and later), so on a busy machine the oldest go. And operators who know about it delete the files, which is itself a finding: a Prefetch folder with a gap around the time you care about, on a machine that is otherwise full, is evidence that somebody cleaned up.

Using it

Parse the whole folder into a timeline rather than opening files one at a time:

PECmd.exe -d C:\case\Prefetch --csv C:\case\out --csvf prefetch.csv

Then sort by last run time around the window you care about, and look for executables in user-writable paths. The forensic timeline cheat sheet covers how Prefetch times line up with the other clocks on the host.