← Back to all posts

The first half of every conversation I have about Prefetch on a Win10 or Win11 host turns into a conversation about SuperFetch, SysMain, ReadyBoost, and whatever else Microsoft was calling memory-management features in a given quarter. Half of the people in the room think they are the same thing. Half think Prefetch was deprecated. Both halves are wrong, but in different directions, and the misconceptions affect how much you can trust the Prefetch directory on a modern host.

This post is the clean version of that conversation.

What each of these actually is

Prefetch is the file-level cache for application startup. Watches a process's first ten seconds, writes a .pf file, uses that file on the next launch to pre-fault the pages the process will probably need. Lives in C:\Windows\Prefetch\. This is the artifact we care about.

SuperFetch was a memory-management feature introduced in Windows Vista. It tracks application usage patterns over time (not just on startup, but during normal use) and proactively pre-loads pages into RAM during idle periods, so frequently-used applications launch faster. It writes its tracking data to Ag*.db files in C:\Windows\Prefetch\. Those .db files are not Prefetch files. They are SuperFetch databases.

SysMain is what SuperFetch was renamed to in Windows 10 1709. Same feature, same service binary (sysmain.dll), same .db files in the Prefetch directory. The service that used to be called "Superfetch" in services.msc is now called "SysMain" on any current Win10/11 host. The rename was cosmetic.

ReadyBoost is a separate feature that uses USB flash storage as a write-through cache for the working set. Not relevant to forensic Prefetch analysis but lives in the same conceptual neighborhood and so gets confused with the others.

The three Prefetch-adjacent artifacts on a Win10/11 host are therefore:

  • C:\Windows\Prefetch\<EXE>-<HASH>.pf: per-application Prefetch traces, the artifact this whole site is about.
  • C:\Windows\Prefetch\AgAppLaunch.db and friends: SysMain databases, which are a separate artifact (SRUM and SysMain databases are different things, both useful, both not Prefetch).
  • C:\Windows\Prefetch\NTOSBOOT-XXXXXXXX.pf: the boot Prefetch, regenerated on every boot.

If somebody says "the Prefetch directory" they usually mean the first. If they say "Prefetch" without context, they probably mean the first too, but it is worth being precise when you are writing a report.

The SSD-disable question

Here is the part that keeps coming up.

On Vista and Windows 7, both Prefetch and SuperFetch were enabled for everyone, on every disk type. On Windows 8, Microsoft added logic to detect SSDs and reduce or disable certain operations on them, on the theory that SSDs do not benefit from sequential pre-loading the way HDDs do.

On Windows 10, that logic became more aggressive. On Windows 11, more aggressive still.

What "disabled on SSDs" actually means in practice, as best I have been able to pin down from telemetry and Microsoft's own variable documentation:

  • Boot Prefetch (NTOSBOOT-XXXXXXXX.pf) is always written.
  • Application Prefetch (per-.exe .pf files) is partially written. Some applications produce .pf files; others do not. The decision appears to be made by SysMain based on heuristics about whether the application would benefit from prefetching.
  • SuperFetch/SysMain proactive pre-loading is largely disabled on SSDs because Microsoft considers the latency reduction not worth the I/O cost.

The forensic consequence: on a Win10 or Win11 host with an SSD, the absence of a .pf file for a given executable is not evidence that the executable did not run. It is evidence that either the executable did not run, or SysMain decided not to write Prefetch data for it.

I have empirically seen Prefetch coverage of 60% to 90% on SSD-backed Win11 hosts, compared to nearly 100% on HDD-backed Win10 hosts. The exact percentage depends on the host's workload, on which executables Microsoft's heuristics have decided to skip, and on whether the system is under memory pressure.

If you need to know with certainty whether a binary ran, do not rely on the absence of a .pf file on a modern SSD-backed host. Pair with EVTX, AmCache, and the host's actual process-execution telemetry.

The registry knobs

The registry path that controls all of this is:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

The values that matter:

  • EnablePrefetcher (REG_DWORD). Controls application Prefetch.
    • 0 = disabled
    • 1 = application Prefetch only
    • 2 = boot Prefetch only
    • 3 = both (default on most client SKUs)
  • EnableSuperfetch (REG_DWORD). Same possible values, controls SuperFetch/SysMain.
  • EnableBootTrace (REG_DWORD). Controls the boot trace. Usually 0 on client SKUs that have the rest enabled.

On a default Windows 10/11 Pro install, you will see EnablePrefetcher = 3 and EnableSuperfetch = 3. On a default Windows Server install, both are typically 0. On hosts where group policy has tweaked things, you may see any value.

The SSD-detect logic does not change these values. Even with EnablePrefetcher = 3, the OS may still skip writing certain .pf files on an SSD-backed host. You cannot infer "Prefetch will be complete" from a 3 in the registry on Win10+.

The honest summary: the registry tells you whether Prefetch is administratively enabled. It does not tell you whether Prefetch was actually written for any given execution. On Win7 and earlier, those two were the same statement. On Win10+, they are not.

What changed at Win10 1709

The 1709 release ("Fall Creators Update") is the version where:

  • SuperFetch was renamed to SysMain.
  • The application Prefetch ring of eight execution timestamps started being aggressively trimmed during idle maintenance windows. A .pf that should show eight execution times might show only three on a host that has been running a while.
  • The SSD-aware skipping of .pf writes became more aggressive than in earlier Win10 builds.

If you are reading older DFIR literature about Prefetch (anything written before 2018), assume the author was working in a pre-1709 world and that some of their assumptions about Prefetch coverage no longer hold.

The most consequential of these is the timestamp trimming. The classic teaching is "Prefetch keeps the last eight execution times". The corrected teaching is "Prefetch keeps up to eight execution times, with Win10 1709+ trimming older entries opportunistically". A .pf showing three timestamps does not mean the binary ran three times. It means the run counter says one thing (the lower bound on total runs) and the timestamp array shows three times that survived trimming.

Windows Server

Worth restating clearly: Prefetch is disabled by default on Windows Server. From 2008 R2 through 2022, the default value of EnablePrefetcher on a fresh server install is 0. SysMain is also off.

Many estates enable Prefetch on servers via GPO. Many do not. If you are working a server engagement and the Prefetch directory is empty, the first thing to check is whether Prefetch was ever enabled on that host. Pull the SYSTEM hive, read the value, check the LastWrite time. If the value was last written at OS install time and is 0, the absence of .pf files means nothing about what ran.

If the value was changed to 3 six months ago and the directory only has .pf files from the last six months, that is consistent. If the value was changed two days ago and the directory has files from before that change, you have a discrepancy worth explaining (usually it means the policy was applied recently but the directory has files from the OS install era or from a previous policy state).

What to verify before relying on a .pf file

Before I cite Prefetch in a report on a Win10/11 host, I check:

  1. Is Prefetch enabled? Pull EnablePrefetcher and EnableSuperfetch from the SYSTEM hive. Note the LastWrite time on PrefetchParameters.
  2. Was it enabled at the time of the events I care about? If the value was changed during the suspicious window, the change itself is part of the timeline.
  3. Is the host SSD or HDD? Check the disk type from the system info. On SSDs, downgrade your confidence in "absence of .pf = absence of execution".
  4. Is the host a server? If yes, factor in the default-off state and the policy history.
  5. Are there Ag*.db files in the Prefetch directory? If yes, SysMain has been running and its database may have additional execution data that is separate from .pf files.
  6. Does PECmd parse the .pf files cleanly? Inconsistent files or files that fail parser validation deserve a second look for tampering.

If all six check out, the Prefetch evidence is solid. If any of them do not, the Prefetch evidence still has value but with caveats that should appear in your report.

A note on the SysMain databases

The Ag*.db files in the Prefetch directory are a separate artifact and worth their own discussion someday. Briefly: AgAppLaunch.db tracks application launch counts and times across longer windows than Prefetch does. It can corroborate Prefetch and sometimes covers executions that Prefetch missed.

Tools to parse these exist but are less mature than Prefetch parsers. Eric Zimmerman has written about them. The format is undocumented by Microsoft and reverse-engineered, so treat any parser output with appropriate skepticism.

What I tell clients

On Win7 and earlier, Prefetch is comprehensive. On Win10 HDD-backed, comprehensive. On Win10 SSD-backed, partial. On Win11 SSD-backed, more partial. On Windows Server, conditional on policy.

The right answer to "is there a Prefetch file for binary X" is never the only question. The right answer to "should I expect there to be one given how this host is configured" is the question to ask before the first.

Further reading