Does the ShimCache prove a program was executed?

TL;DR. No. A ShimCache entry proves Windows examined the file, usually but not always for execution. Windows 10/11 removed the in-cache execution flag entirely. Confirm execution with Prefetch, AmCache, or process-creation events (Security 4688 / Sysmon 1).

"The ShimCache shows it ran" is the single most expensive sentence in Windows incident response. It gets written into reports. It gets challenged by opposing counsel. It gets the analyst on the stand explaining why an mtime is not a process start, while everyone in the room learns more about the Application Compatibility Cache than they ever wanted to. Do not be that analyst.

What the ShimCache actually records

The cache, formally the Application Compatibility Cache stored at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache, captures executables that Windows examined to decide whether a compatibility shim needs to apply. Examination is not execution. Windows examines a binary when:

A user double-clicks it.
Explorer enumerates a folder and inspects a PE header for icon data.
An AV scanner, indexer, or EDR walks the filesystem.
A right-click "Properties" pulls the version resource.
A system call resolves a path that ends in .exe.

Most of those happen alongside execution. Some do not. A binary an attacker dropped, renamed, and deleted without ever launching can still land in the cache because Defender scanned it on the way down.

The flag Windows 10 took away

Older builds (XP through Windows 8.1) embedded an Executed flag in each entry. Plenty of analysts learned to grep for "yes" and call it a day. Windows 10 removed that flag. Windows 11 did not put it back. The modern cache carries the path, an mtime, and structural metadata. There is no in-cache marker that says "this ran."

If you trained on legacy hives and are now reading a Windows 10/11 SYSTEM, recalibrate. The "Executed" column you remember is gone. Every parser worth using (Eric Zimmerman's AppCompatCacheParser, Mandiant's Shim Cache Parser, this tool) reflects that absence honestly. If you see a tool reporting an execution flag on a modern hive, that tool is making it up.

For the field-level layout, see the Windows 10/11 binary format walkthrough.

What confirms execution

Treat the ShimCache hit as a hypothesis. Then go find evidence that actually records process creation.

Prefetch. C:\Windows\Prefetch\*.pf files get written within ~10 seconds of every process start on workstation SKUs. Run count, last eight run times, loaded modules. If the file exists, the binary ran. The Prefetch parser explains the format and the disable cases.
AmCache. Amcache.hve carries SHA-1 hashes and explicit first-run timestamps, written continuously. The AmCache parser has the field guide.
EVTX / Sysmon. Security 4688 (with command-line auditing enabled) and Sysmon Event ID 1 are the highest-fidelity records you will ever get. The EVTX parser covers the triage workflow.
BAM / DAM. Per-user last-execution times under HKLM\SYSTEM\CurrentControlSet\Services\bam\State. Cheap to read, criminally underused.
UserAssist. Interactive Explorer launches only, ROT13-encoded names. Useful for "did the user double-click this?" not "did the binary ever run?"

Cross-reference patterns are in the program-execution artifacts reference.

How to phrase it in a report

Bad: "ShimCache shows mimikatz.exe was executed at 14:33:21 UTC on 2026-04-11."

Better: "ShimCache records the file C:\Users\Public\mimikatz.exe with $STANDARD_INFORMATION mtime 2026-04-11 14:33:21 UTC. Prefetch entry MIMIKATZ.EXE-A1B2C3D4.pf shows one execution at 14:34:02 UTC. AmCache SHA-1 matches known mimikatz build 2.2.0."

That second sentence holds up under cross-examination. The first does not.

Parse a hive without leaving the browser

Drop your SYSTEM hive into the Shimcache Parser. Everything runs client-side. No upload, which matters when the hive came from a regulated environment or a client engagement.