TL;DR. Prefetch is real proof of execution with run counts and run times. ShimCache only proves a file existed and was examined. If you need "did it run, and when?", reach for Prefetch first. If Prefetch is disabled or wiped, ShimCache becomes your fallback existence witness.
The two are constantly compared because both surface "programs on a Windows host." They are not the same kind of evidence. Treat them as interchangeable and you produce wrong conclusions. Here is the head-to-head.
At a glance
| ShimCache | Prefetch | |
|---|---|---|
| Location | HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache | C:\Windows\Prefetch\*.pf |
| What it proves | File existed and was examined | File executed |
| Run count | No | Yes |
| Run timestamps | No (only file mtime) | Yes, last 8 run times |
| Files referenced | No | Yes, DLLs and data files loaded |
| Written when | Only at clean shutdown | Within ~10 s of execution |
| Default on workstation SKUs | Yes | Yes |
| Default on server SKUs | Yes | Often disabled |
| Capacity | Up to ~1,024 entries | 1,024 .pf files on Win8+ |
Where Prefetch wins
Prefetch is the stronger execution artifact, full stop. Each .pf file gives you the last run time (up to eight on Windows 8+), a total run count, and the list of files the process loaded. Enough to assert "this binary executed at these times," which ShimCache can never do because its only timestamp is the file's last-modified time, not an execution time.
The loaded-modules list is also gold for triage: a .pf showing a Word process that loaded WINWORD.EXE plus MSO.DLL plus a suspicious DLL from \AppData\ is a quick read for malicious add-in loading. Eric Zimmerman's PECmd is the standard parser. The Prefetch parser covers the format if you want to roll your own.
Where ShimCache wins
Prefetch has a critical weakness: it is frequently disabled on servers, on SSD-tuned images, and by attackers (EnablePrefetcher = 0). It is also actively deleted by clean-up tooling. ShimCache, by contrast, is always on and is sensitive enough to record a binary that was dropped and deleted before it ever ran.
When Prefetch is empty, ShimCache often still answers "did this file ever touch this host?" The full inference is in does the ShimCache prove a program was executed.
The cache also captures files Prefetch never sees:
- Binaries that crashed before completing process initialization.
- Files that Windows examined for compatibility but the user did not actually launch.
- Executables that ran from network shares before Prefetch decided to write a
.pf.
How to use them together
- Both present, paths match. Strong execution evidence. Use Prefetch's run times as the event timeline. Use ShimCache's mtime only to anchor the file's identity.
- Prefetch only. Execution is proven. ShimCache may simply not be flushed yet (it only writes at shutdown, see where ShimCache is stored).
- ShimCache only. The file existed and was examined. Do not claim execution without corroboration. Pull AmCache, BAM, and EVTX. The full matrix is in the artifacts reference.
- Neither, but you suspect execution. Look for anti-forensics. Prefetch deletion plus a missing ShimCache flush is itself a finding, covered in ShimCache anti-forensics.
To read the ShimCache side without installing anything, drop a SYSTEM hive into the Shimcache Parser. Fully in-browser.
Further reading
- libyal's Windows Prefetch (PF) format notes — reference for the
.pfbinary layout. - Mandiant's Caching Out the Val — defines the ShimCache's forensic role.