Why does Windows Server have no prefetch files by default?

Microsoft disables prefetch on Server SKUs because long-running services do not benefit from the app-launch optimization the feature exists for. Both EnablePrefetcher and EnableSuperfetch default to 0.

Which registry key controls prefetch behavior?

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters. The EnablePrefetcher value (DWORD) accepts 0 (off), 1 (app launches), 2 (boot), or 3 (both, the workstation default).

Which service writes prefetch files?

SysMain, formerly called Superfetch. Even with EnablePrefetcher = 3, no .pf files appear if SysMain is stopped or disabled.

Does enabling prefetch back-fill historical execution data?

No. SysMain only writes new .pf files from the moment it begins running again. For past executions on systems where prefetch was disabled, rely on Amcache, ShimCache and event logs instead.

Why Windows Server has no prefetch files

If you triaged a Windows Server install and the Prefetch\ directory is empty, your first instinct should not be "the attacker wiped it." The first instinct should be "Server defaults." Microsoft ships Prefetch off on Server SKUs because the workload assumption — long-running services rather than short-lived interactive apps — makes the feature counter-productive for the kind of memory management Server cares about.

That default catches DFIR analysts out about once a quarter on engagements I have seen. Knowing the registry layout up front saves the embarrassing email asking the customer "is your Prefetch missing on purpose."

The registry knob

One key controls all of it:

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

Two values that matter:

EnablePrefetcher (DWORD). 0 disabled. 1 app-launch Prefetch only. 2 boot Prefetch only. 3 both, the workstation default.
EnableSuperfetch (DWORD). Same semantics. Controls the broader SuperFetch / SysMain feature that hosts the Prefetch logic on modern Windows.

Workstation defaults are 3 for both. Server defaults are 0 for both. The boot/app split on EnablePrefetcher is mostly historical; in practice you almost always see 3 or 0, not the intermediate values.

Parse the SYSTEM hive offline with the registry parser if you only have an image and want to know what the live state would have been at acquisition. Compare against the values in older Volume Shadow Copies to see whether a workstation was reconfigured to 0 mid-investigation; the SYSTEM hive LastWrite time gives you the moment of change.

The SysMain service

The service that actually writes .pf files is SysMain (renamed from Superfetch years ago). If SysMain is stopped or disabled, no Prefetch is generated, no matter what the registry says. Both conditions have to hold:

EnablePrefetcher = 3
SysMain running

On a live system:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters"
sc query SysMain

On a dead system, the equivalent is parsing the SYSTEM hive and the System EVTX for SCM events. Service Control Manager logs every SysMain start/stop in the System log — useful for narrowing when generation actually paused.

Forensic implications

An empty Prefetch\ folder is not, by itself, a finding. Before you conclude "no execution evidence on this host", check four things:

OS edition. Server SKUs that have been up for months still have essentially no Prefetch. Workstation SKUs that have been up for an hour have dozens already.
Registry values at collection time. Both EnablePrefetcher and EnableSuperfetch set to 0 is configuration, not tampering. One at 3 and one at 0 is unusual and worth a closer look.
SysMain state. The System EVTX reveals service stops and starts; correlate the timeline against the period of interest.
SSD-specific behavior. Some Windows 10 builds and Win11 22H2+ on SSD-only systems opportunistically disable parts of Prefetch. The registry still says 3. Coverage drops anyway. This is not (only) anti-forensics — it is OS behavior.

If items 1–4 all check out and the folder is still empty, then ask whether the directory was wiped. Carve unallocated for MAM\x04 signatures and pull the USN journal for .pf deletion events. The dedicated tampering write-up has the full procedure.

Re-enabling for ongoing collection

If you control the host and want Prefetch on for visibility going forward:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 3 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnableSuperfetch /t REG_DWORD /d 3 /f
sc config SysMain start= auto
net start SysMain

Turning it on does not back-fill anything. SysMain starts writing fresh .pf files from the moment it begins; you get no record of executions that happened before. For pre-enablement execution evidence on a Server, fall back to AmCache, Shimcache, SRUM for process resource usage, and the Security/Sysmon EVTX if process auditing was on.

Disabled by policy, not by attacker

In hardened environments — CIS baseline, STIG, vendor configuration profile — Prefetch is sometimes suppressed by Group Policy. The registry values look the same as a manual disable. The way to tell is gpresult /h on a live host (or parsing the relevant Group Policy artifacts from the image). When the policy forces EnablePrefetcher = 0, that is intent. When the value flips from 3 to 0 mid-uptime with no corresponding GPO refresh, that is something else.