Understanding the Windows ShimCache (AppCompatCache)

Most analysts meet the ShimCache the same way: somebody on the team says "pull the AppCompatCache, see if the binary is in there," and it works often enough that the artifact gets a reputation it does not entirely deserve. I have spent enough hours arguing about ShimCache rows in case reviews to know the artifact is worth its weight, but only if you treat it as what it actually is. Not an execution log. Not a process audit. A list of executables that Windows looked at hard enough to decide whether a compatibility shim should fire.

That is the framing. The rest is mechanics.

What the cache actually records

The Application Compatibility Cache, almost always shortened to ShimCache or AppCompatCache, lives in the SYSTEM hive and holds up to roughly 1,024 entries on modern Windows. Each entry carries the full file path of an executable, the file's $STANDARD_INFORMATION last-modified time, and (on older versions) a flag describing whether the binary was actually executed. That flag is gone on Windows 10 and 11. Pretend it never existed.

Windows builds the cache in memory at every boot and only writes it to disk at clean shutdown. A BSOD, a hard reset, or a hypervisor-level kill of a VM eats whatever entries were sitting in volatile memory. That single fact accounts for half the "but I saw the binary in production" stories that turn into "the on-disk hive shows nothing" tickets.

Where it lives

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

That trailing AppCompatCache is a value, not a subkey. Its contents are a single binary blob whose layout changed at every major Windows release: XP, 7, 8, 8.1, and the 10/11 family all use different schemas. Parsing offline means pulling the SYSTEM hive (plus its SYSTEM.LOG1 and SYSTEM.LOG2 transaction logs) and decoding the blob against the correct version. This tool parses that single SYSTEM hive file in your browser, with no upload. It does not replay the logs, so if the hive is dirty, replay them into it first with Eric Zimmerman's rla.exe.

Why investigators reach for it

ShimCache earns its keep because it survives. An attacker can drop a binary, run it, delete it, clear the Prefetch folder, and the ShimCache still holds the full path. That makes it a strong existence witness for:

Malware that has already been wiped from disk.
Renamed system binaries used as living-off-the-land payloads.
Tooling staged from a network share that nobody ever pulled locally.

Combine the path data with AmCache for hash attribution and you can pivot to threat intel even when the file is long gone.

Three things that bite people

The timestamp is the file's mtime, not when the program ran. Timestomping changes what the cache records.
An entry is not proof of execution. The Win10/11 cache has no execution flag at all.
The cache flushes at clean shutdown only. Hard reboots silently destroy recent entries.

Treat each row as a hypothesis. Corroborate with Prefetch, AmCache, EVTX / Sysmon, or registry hives before writing anything definitive in a report.

Where to go next

The rest of the blog is organized into two clusters.