The short answer: Approximately 128 unique executables retained. Each executable retains up to 8 recent-run timestamps. Combined with the run count this produces a comprehensive execution-attribution timeline for the last few weeks to few months of Windows activity depending on application variety. FAQ Q3 details user attribution via Security event log correlation.
Why Prefetch Matters for Forensic Investigations
Windows Prefetch exists to accelerate application launches by pre-loading the files and directories the executable references during startup. Windows records the launch behavior on first execution and refines the record across subsequent launches. For forensic investigators the Prefetch record is a byproduct: the same data structures that support fast application launch also produce a detailed execution-history artifact.
The forensic value of Prefetch comes from three properties. First, ubiquity: Prefetch is enabled by default on all Windows 10 and 11 installations except server SKUs where it may be disabled. Almost every Windows endpoint investigators encounter has Prefetch data. Second, longevity: Prefetch entries survive multiple reboots and system-cleanup operations that clear other execution artifacts. Third, cross-artifact correlation value: the Prefetch execution timestamps and file-access lists correlate with Security event log events and Sysmon process-creation records and AmCache binary-hash records to produce a rich reconstruction timeline.
What Prefetch Actually Records Per Executable
Each Prefetch .pf file corresponds to one executable identified by the executable filename and a hash of the full path. The filename format is EXECUTABLE-HASHFROM_PATH.pf where HASHFROM_PATH is the Windows-computed hash of the full path to the executable. This naming convention means the same executable at different paths produces different .pf files; a copy of notepad.exe at C:/Windows/System32/notepad.exe and a copy at C:/Tools/notepad.exe generate two distinct .pf files.
Inside each .pf file the recorded fields include the executable filename, the full file path (recoverable from the hash when the path is documented), the last-run timestamp, up to 7 additional recent-run timestamps, the total run count since the .pf was created, the list of files and directories the executable accessed at launch and volume information for the source drive. Windows 10 and 11 Prefetch format is documented through community DFIR research and the parser tools that Eric Zimmerman and others maintain (PECmd is the reference parser).
For investigators the 8-timestamp-per-executable retention is the critical constraint. When an executable is launched more than 8 times only the 8 most recent launches have documented timestamps. For attacker binaries that run once and then are removed the single execution is recorded and survives; for legitimate applications that run continuously (browsers, mail clients, productivity suites) the timestamp window covers only the recent activity.
The 128-Executable Retention Bound
Windows retains approximately 128 unique executable .pf files across the system. The exact cap has varied across Windows versions but 128 is the modern default on Windows 10 and 11. When the 128 slot cap fills the oldest .pf file (measured by the least-recently-run timestamp) is evicted and deleted from the Prefetch directory. This eviction is deterministic and predictable.
For workstations with limited application diversity (users running the same 20 to 30 applications routinely) the 128-executable cap covers months of execution history because the cap is never reached. For workstations with high application diversity (developers, security researchers, IT support staff running many tools) the cap fills within weeks and older executable entries roll off. For workstations that have run many one-off installers and utilities the cap fills fastest because each unique executable claims a slot.
For investigators the retention-depth question is contextual. Check the oldest .pf file creation timestamp to determine the effective coverage window on the specific target host. If the oldest .pf is 6 months old the retention covers 6 months; if the oldest is 3 weeks old the retention covers 3 weeks. This first-triage measurement determines whether the target time window falls within the recoverable Prefetch history.
What Investigators Actually Recover From .pf Files
The Eric Zimmerman PECmd parser (canonical implementation, actively maintained) is the standard tool for .pf file extraction. PECmd reads each .pf file and emits a CSV or JSON summary with the executable name and path and timestamps and run count and file-access list. For forensic workflows the CSV ingests directly into timeline tools (Plaso log2timeline and ELK stack and Splunk and the Sherlock Ultimate Event Viewer).
Beyond the primary timestamps and run counts the Prefetch file-access list is one of the most under-utilized forensic detail sources. Each .pf file lists every file and directory the executable touched during its first ~10 seconds of launch. This list often reveals dependencies (DLL loads, configuration file reads, registry hive access, temp-file writes) that establish what the executable was doing and where its state lived. For attacker binaries the file-access list often reveals staging directories and data-exfiltration destinations that no other artifact captures.
The volume information section captures the drive serial number and creation timestamp of the volume where the executable resides. For portable executables run from removable media (USB thumb drives, external hard drives) this section is decisive: it captures the specific USB device that hosted the executable at launch time. Cross-correlating the Prefetch volume information against the USBSTOR registry (from Sherlock Windows USB connection records Buyer Education) identifies the exact removable device that carried the executable.
The Cross-Correlation Workflow With Windows Event Log
Prefetch execution timestamps do not record the user account that launched the executable. For user attribution investigators cross-correlate the Prefetch timestamp against the Windows Security event log user session events. Event ID 4624 records successful logon with the user account name and the session identifier and the logon type; Event ID 4634 records logoff with the matching session identifier. The correlation procedure: identify the Prefetch execution timestamp, find the most recent 4624 event before that timestamp, confirm no intervening 4634 closed the session and record the user account as the attributed executor.
For Windows 10 and 11 installations that also run Sysmon the process-creation events (Sysmon Event ID 1) provide direct user attribution alongside process-lineage detail. Sysmon and Prefetch together produce the strongest execution attribution reconstruction; Prefetch alone with Security event log correlation produces near-equivalent quality for the same time-window questions.
The Sherlock UEV pairs Prefetch parsing with Windows Security event log parsing in a unified timeline visualization. The tool handles the cross-artifact correlation automatically and surfaces execution events with attributed user context without requiring the examiner to manually merge the two data sources.
What Prefetch Does Not Record
Prefetch has practical limits investigators should understand. First, Prefetch does not record command-line arguments. The .pf file captures the executable identity and timestamps and file-access list but not the specific arguments passed at launch. For command-line-parameterized attacks (net.exe, wmic.exe, powershell.exe with encoded commands) Prefetch confirms the executable ran but does not reveal the specific arguments; Security event log 4688 and Sysmon Event ID 1 provide argument capture when configured.
Second, Prefetch does not record network activity. The file-access list captures local files and directories but not network destinations. For attacker binaries with network beacon or exfil behavior Prefetch confirms execution but not destination; network telemetry (NetFlow, endpoint firewall logs, EDR network events) provides the destination detail.
Third, Prefetch may be disabled or restricted on some systems. Server SKUs (Windows Server 2016+) typically disable Prefetch by default. Some hardening baselines disable Prefetch on workstations for anti-forensic reasons. Investigators triaging a Windows host should confirm Prefetch is enabled via the EnablePrefetcher registry key (HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/Memory Management/PrefetchParameters) before drawing conclusions from absence of expected .pf entries.
The Practical Investigation Use Cases Prefetch Supports
Prefetch supports several recurring forensic investigation use cases. Malware execution confirmation: when investigators identify a suspected malicious binary Prefetch confirms whether the binary actually executed and when. Post-execution binary removal detection: when a suspected malicious binary was removed after execution the .pf file persists and the AmCache SHA1 record identifies the removed binary. Unauthorized software discovery: Prefetch reveals every executable that ran regardless of whether the user installed it through standard channels or sideloaded it. Timeline reconstruction across multi-week incident windows: when investigations open weeks after the relevant activity Prefetch often provides the only surviving execution evidence because Security event log retention may have rolled off.
Adding Prefetch to the IR Triage Checklist
For organizations building Windows incident response capacity the operational discipline is straightforward. Include the C:/Windows/Prefetch/ directory contents in the standard IR triage acquisition list. The acquisition is fast (typically under 30 seconds even for full-cap Prefetch directories) and the file set is small (typically under 20 MB total). Parse with Eric Zimmerman PECmd or the Sherlock UEV Prefetch parser. Cross-correlate against Security event log for user attribution. Document the retention window depth at time of acquisition to characterize the effective coverage.
For organizations that operate Sysmon at scale Prefetch is corroborating rather than primary evidence but the corroboration matters. Sysmon coverage is not universal (some hosts have Sysmon, some do not); Prefetch is universal (essentially every Windows 10 and 11 workstation) and provides the fallback execution-history source when Sysmon is absent. The two artifacts together produce the strongest execution reconstruction.
Prefetch is one of the most durable forensic artifact classes on Windows. It survives longer than browser history, longer than mail cache, longer than recent documents lists. For investigations where application execution history is relevant Prefetch is the right starting point and the Sherlock Ultimate Event Viewer handles the parsing and cross-correlation workflow in a single tool.