Amcache vs ShimCache: when each artefact wins

Amcache and ShimCache (also called AppCompatCache) are the two Windows artefacts most often confused with each other, because both sit in the "Application Compatibility" infrastructure and both record binaries that have been on a host. They are different mechanisms, maintained by different Windows subsystems, with different limits and different forensic value.

The headline differences:

ShimCache is shorter, sparser, kernel-maintained, and updated by the loader. Amcache is longer, richer, user-mode-maintained, and updated by a scheduled task.

For the broader Amcache reference, see the Amcache complete reference. For the Amcache vs Prefetch question (a different comparison), see Amcache vs Prefetch.

---

What each one records#

ShimCache / AppCompatCache#

A binary blob stored in the SYSTEM registry hive under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. It is kernel-maintained — every time the loader touches a binary (loads it, executes it, or in some cases just stats it), the cache is updated.

Each entry stores:

• The file's full path.
• A modification timestamp (the file's $STANDARD_INFORMATION modified time at the time of the cache update).
• A flag indicating whether the binary was executed.
• On some Windows versions: an entry-creation timestamp.

The cache is flushed to the registry on shutdown, not in real time. This produces a critical quirk: on a live system, the on-disk cache is stale until the next clean shutdown. To get the freshest ShimCache, you need a memory image or a system that has shut down cleanly since the events of interest.

The cache is also size-limited:

• Windows 7 / Server 2008 R2: 1024 entries.
• Windows 8 / 2012: 1024 entries.
• Windows 10 / 11 / 2016+: 1024 entries.

When the limit is reached, older entries are evicted in LRU fashion. A heavily-used host can churn ShimCache in days.

Amcache#

A separate registry hive (Amcache.hve) maintained by the Compatibility Appraiser scheduled task, which runs roughly daily on workstations and less frequently on servers. The hive records thousands of entries per host with rich metadata: SHA-1 hash, publisher, version, link date, install context. See Amcache registry structure for the full schema.

---

The fundamental difference#

Property	ShimCache	Amcache
Storage	SYSTEM hive, single binary value	Standalone Amcache.hve
Maintainer	Kernel loader	User-mode scheduled task
Update trigger	Loader touches the binary	Appraiser scan
Persistence to disk	On shutdown	Continuous (with transaction logs)
Max entries	~1024	Effectively unbounded (thousands typical)
Records hash?	No	Yes — SHA-1 of first 31 MiB
Records publisher / version?	No	Yes
Records ProgramId?	No	Yes
Records driver / device data?	No	Yes (driver + device sub-keys)
Granularity per entry	Path + 1-2 timestamps	Path + rich metadata + multiple timestamps
Available on live system	Stale (need shutdown)	Fresh
Survives binary deletion	Yes	Yes
Available in memory	Yes (most useful place)	Yes (less critical)

For most DFIR work, Amcache is the richer artefact. ShimCache remains essential for specific questions where its kernel-side position pays off.

---

When ShimCache wins#

A handful of cases where you want ShimCache, not Amcache:

"Did the loader touch this binary, even if it didn't execute?"#

ShimCache records loader touches more aggressively than Amcache records presence. A binary that was briefly stat'd by an application but never executed and was never inventoried by the appraiser can still leave a trace in ShimCache.

This is rare but not impossible. ShimCache is the only artefact that captures it.

"I have a memory image but no disk image"#

ShimCache lives in kernel memory continuously and is one of the artefacts Volatility's shimcachemem plugin extracts cleanly. Amcache is registry hive data on disk — to get it from memory you need to extract the hive itself, which is more work.

"The appraiser is disabled on this host"#

Hardened endpoints sometimes disable the Compatibility Appraiser to prevent telemetry to Microsoft. Those hosts have no Amcache activity, but the kernel still maintains ShimCache (it is part of the loader, not the appraiser).

"I need pre-1709 Windows 10 coverage"#

The modern Inventory* schema in Amcache only landed in Windows 10 build 1709. For older 10/8.x builds, Amcache is sparser. ShimCache predates Amcache and is consistently available on Windows 7 and later.

---

When Amcache wins#

Most of the time. The cases where Amcache is dramatically better:

"What's the SHA-1 of this binary?"#

ShimCache: no answer. Amcache: directly in the Hash column. This alone is reason to make Amcache your first stop on most investigations.

"Who published this binary?"#

ShimCache: no answer. Amcache: Publisher, PublisherName, ProductName.

"When did this binary first appear on this host?"#

ShimCache: a timestamp, but it is the file's modification time at loader touch, not the touch time itself. Useful but indirect. Amcache: KeyLastWriteTimestamp is closer to "when did Amcache record this", which is closer to "when did the appraiser first see it". See Amcache timestamps explained.

"Is this binary related to an installed application?"#

ShimCache: no relationship data. Amcache: ProgramId joins to InventoryApplication for full installed-product context. See Amcache ProgramId explained.

"Cross-host hunt"#

ShimCache: 1024 entries per host, no ProgramId, only paths. A hash-based cross-host hunt is impossible from ShimCache alone. Amcache: Hash and ProgramId make cross-host pivots trivial. See Lateral movement and Amcache ProgramId pivoting.

"Driver / device evidence"#

ShimCache: only PE binaries the loader touched. Amcache: InventoryDriverBinary, InventoryDeviceContainer, and InventoryDevicePnp give you a separate, structured driver and device history. Essential for BYOVD and USB investigations.

---

How they corroborate each other#

When both artefacts have an entry for the same binary, you get a multi-source confirmation:

• ShimCache says the loader touched it.
• Amcache says the appraiser inventoried it, with a hash and metadata.
• Prefetch (if present) says it actually executed, with run times.

If only one artefact has the binary, the absence in the other is itself a signal:

• ShimCache only: the loader touched it but the appraiser never inventoried it. Possible reasons: file deleted before the next appraiser run, file in a path the appraiser does not scan, appraiser disabled.
• Amcache only: the appraiser inventoried it but the loader never touched it (in the time window covered by the current ShimCache). Possible reasons: file was present but never loaded, file's loader touch was evicted from ShimCache's 1024-entry limit, ShimCache was cleared.

---

Standard joint workflow#

1. Parse ShimCache with AppCompatCacheParser.exe (Zimmerman).
2. Parse Amcache with AmcacheParser.exe (Zimmerman).
3. Load both into Timeline Explorer.
4. For each entry in the Amcache "unsigned PE in user-writable path" triage filter, check ShimCache for the same path. If present, the loader touched it; if absent, presence-only.
5. For each entry in ShimCache with the executed flag set, check Amcache for hash / publisher metadata.
6. Cross-reference both with Prefetch for execution proof.

---

Quick decision table#

Your question	ShimCache	Amcache
Was binary X on this host?	✓ (path only, last 1024)	✓✓ (path + metadata)
What is binary X's SHA-1?	✗	✓
Did binary X execute?	partial (executed flag)	✗
When did binary X first appear?	partial	✓
Cross-host hunt by content?	✗	✓
Cross-host hunt by application?	✗	✓ (ProgramId)
Driver / device evidence?	✗	✓
Coverage on hardened/no-appraiser hosts?	✓	✗
Coverage on pre-Win10 1709?	✓	partial
Available freshly on live system?	✗ (need shutdown)	✓

---

See also#

• Amcache complete reference — the artefact in full.
• Amcache vs Prefetch — the other major execution-evidence comparison.
• Amcache vs SRUM — long-window execution evidence.
• Amcache for malware investigation — how all three artefacts combine in a real playbook.

To explore your own hive alongside your ShimCache parse, drop the file on the parser home page — it runs entirely in your browser.