Why ShimCache + AmCache matter for Windows DFIR: These artifacts capture process execution metadata that the kernel writes for compatibility-shim plus inventory purposes. They are not logging artifacts that get cleared by routine retention; they accumulate slowly plus persist for the lifetime of the Windows installation. For incident response investigations opening weeks or months after the relevant activity, ShimCache plus AmCache often outlast the corresponding event log entries.
The Application Compatibility Cache (ShimCache) Origin
The Application Compatibility Cache, commonly called ShimCache, was introduced in Windows XP plus has been present in every Windows release since. The original purpose was to support the Application Compatibility Infrastructure: the Windows component that applies compatibility shims to legacy applications. When a user launches an application, the Application Compatibility subsystem checks whether the binary needs a compatibility shim plus applies it if necessary. ShimCache records the binary path, the binary modification timestamp plus some metadata about the binary itself to support fast lookup on subsequent launches.
The forensic relevance was discovered later. The same cache that supports compatibility decisions also records every executable that Windows attempted to launch, regardless of whether the launch succeeded. For investigators trying to confirm that a specific binary executed on a Windows system at some point in the past, ShimCache is one of the most reliable sources because the kernel writes the entry as part of the launch process plus the entry persists across reboots plus user sessions.
What ShimCache Records on Modern Windows
The ShimCache implementation differs across Windows versions but the modern (Windows 10 plus 11) format records the binary path, the binary last-modified timestamp, the file size plus a flag indicating whether the binary actually executed. The records live in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache. The registry value is binary-encoded plus needs a parser to interpret. The key technical detail: the ShimCache flag indicating actual execution is unreliable on modern Windows because Microsoft changed the semantics across updates. Investigators should treat ShimCache entries as evidence of attempted launch, not necessarily confirmed execution.
The ShimCache capacity is bounded. Modern Windows retains approximately 1024 entries (the exact number varies by version). When the cache fills the oldest entries are evicted. For a system with active application usage the cache may turn over in days. For a system with limited application diversity the cache can preserve months of entries. The retention behaviour matters for triage: investigators arriving at a system months after the relevant activity may find that the entries of interest have been evicted by intervening application launches.
The Application Compatibility Database (AmCache) Companion
AmCache was introduced in Windows 8 as the successor companion artifact to ShimCache. Unlike ShimCache which lives in the registry, AmCache lives as a separate file at C:\Windows\AppCompat\Programs\Amcache.hve. The file is a registry hive itself but is stored separately from the standard system hives. AmCache records substantially more metadata than ShimCache including the binary path, the SHA1 hash of the binary, the binary product name, the binary publisher, the file size, the file timestamps plus the FirstInstallTime per-binary.
The SHA1 hash field is the load-bearing detail for AmCache forensic value. Even when investigators no longer have access to the binary itself (deleted, overwritten, encrypted) the SHA1 hash from AmCache provides positive identification of which binary executed. The hash can be cross-referenced against threat intelligence databases (VirusTotal, MalwareBazaar, ThreatGrid, internal IOC lists) to identify whether a known-malicious binary executed.
AmCache retention is longer than ShimCache. The hive accumulates entries over time plus does not have the strict capacity limit that bounds ShimCache. For typical Windows installations AmCache preserves multiple months of execution history. For investigators handling incident response months after the relevant activity AmCache is often the artifact that survives when other sources have rolled off.
Parsing the Two Artifacts
The standard tooling for ShimCache parsing is Mandiant ShimCacheParser plus Eric Zimmerman AppCompatCacheParser (AppCompatCacheParser.exe). The Eric Zimmerman tool is the current canonical implementation plus handles the format variations across Windows 7, 8, 8.1, 10 plus 11. The tool reads the registry value, decodes the binary structure plus emits a CSV summary with one row per cache entry. For forensic workflows the CSV ingests into a timeline tool (Plaso log2timeline, ELK stack, Splunk) for cross-artifact correlation.
The standard tooling for AmCache parsing is Andreas Schuster amcache-parser plus Eric Zimmerman AmcacheParser (AmcacheParser.exe). The Eric Zimmerman tool is again the canonical implementation. The tool reads the Amcache.hve file, walks the registry structure plus emits CSV output with the per-binary records plus the associated metadata. For forensic workflows the AmCache CSV ingests into the same timeline tools as ShimCache.
The Cross-Correlation Workflow
The two artifacts together produce a stronger forensic record than either alone. ShimCache provides the attempted-launch evidence with the binary path plus timestamps. AmCache provides the binary hash plus rich metadata. Cross-correlating the two by binary path identifies entries present in both, confirms the metadata plus extends the analysis with hash-based threat intelligence lookup.
Entries present in ShimCache but absent from AmCache often indicate older execution (the ShimCache entry has aged out of AmCache equivalent) or execution of binaries that AmCache did not index (some service binaries, some Windows-internal binaries). Entries present in AmCache but absent from ShimCache may indicate that the ShimCache entry has been evicted while AmCache retained the longer-tail record. The cross-correlation pattern itself reveals the timeline depth available for the investigation.
For investigators cross-correlating against other Windows artifacts the ShimCache plus AmCache pair joins with the Windows Event Log (especially Application plus System plus Sysmon when present), the Prefetch artifacts (in C:\Windows\Prefetch) plus the registry MUICache entries to produce a comprehensive process execution timeline. The Sherlock Ultimate Event Viewer handles the event log side of the cross-correlation; the ShimCache plus AmCache parsing happens through the Zimmerman tooling plus the combined timeline ingests into the standard DFIR workflow.
The Common Investigation Use Cases
ShimCache plus AmCache support several recurring investigation use cases. The first is malware execution confirmation. When investigators identify a suspected malicious binary on a Windows system, ShimCache plus AmCache confirm whether the binary actually executed plus when. The execution timestamp anchors the broader incident timeline.
The second is post-execution binary removal detection. When investigators suspect that a malicious binary executed plus was subsequently removed, the binary itself may no longer be on the system but the ShimCache plus AmCache entries persist. The SHA1 hash from AmCache positively identifies the removed binary plus supports the forensic conclusion that the binary executed despite being absent at investigation time.
The third is unauthorized software discovery. When investigators audit a Windows system for policy violations, ShimCache plus AmCache reveal every binary that executed regardless of whether the user installed it through standard channels or sideloaded it from external sources. The binary path plus the FirstInstallTime from AmCache reveal the introduction pattern.
The fourth is timeline reconstruction across multi-month incident windows. When investigations open weeks or months after the relevant activity, ShimCache plus AmCache often provide the only surviving execution evidence because Security event log plus Sysmon log retention may have rolled off. The two artifacts provide the anchor points for the long-tail timeline reconstruction.
The Practical Limits Investigators Should Know
The first limit is the ShimCache execution flag unreliability on modern Windows. Treat all ShimCache entries as evidence of attempted launch (which is typically equivalent to actual launch but not strictly guaranteed). For confirmed-execution claims rely on AmCache hash entries or on Event Log corroboration.
The second limit is the ShimCache capacity bound. Investigators arriving at a busy Windows system months after the relevant activity may find that the entries have been evicted. Check the oldest timestamp in the ShimCache output to determine the effective coverage window before drawing conclusions about absence of evidence.
The third limit is the binary path resolution for moved or renamed binaries. ShimCache plus AmCache record the binary path at the moment of the cache write. If the binary was subsequently moved or renamed the cache entry retains the original path plus the file system does not have a record at that path. The hash field in AmCache supports the correlation but the path-only ShimCache entries can be misleading without the hash cross-reference.
The fourth limit is the anti-forensic clearing pattern. Sophisticated attackers may clear ShimCache (through registry value deletion) or AmCache (through file deletion plus replacement) as part of post-incident cleanup. The clearing itself is forensic evidence (the absence of expected entries indicates deliberate suppression) but it eliminates the per-entry detail that would otherwise support the investigation.
The Operational Discipline This Suggests
For organizations operating Windows infrastructure the operational discipline this suggests is to include ShimCache plus AmCache in the standard forensic acquisition list for any Windows incident response triage. The acquisition is fast (under one minute for the registry value plus the hive file) plus the analytical yield is high. For organizations building internal Windows DFIR capacity the Sherlock toolkit plus the Zimmerman tooling together handle the parsing plus analysis workflow.
For organizations engaging external incident response support the Sherlock Forensics methodology covers ShimCache plus AmCache analysis as part of the standard Windows compromise investigation scope. The artifacts have produced the load-bearing evidence in multiple Canadian enterprise incident response engagements where the original logging sources had rolled off plus the long-tail execution history was the only path to root cause attribution.