Understanding Amcache: what it is and why DFIR cares

Amcache.hve is the Windows registry hive the Compatibility Appraiser writes inventory metadata into for every PE binary it sees on the host. SHA-1 of the first 31 MiB, full path, publisher, link date, and a key write time per entry. One of the richest single Windows DFIR artefacts.

It is the hive you reach for when you need to know "was this binary ever on this host, and what was it?" — even when the binary itself is long gone.

Where Amcache came from#

Amcache is a by-product of Windows' application-compatibility machinery, not a security feature. Microsoft introduced it in Windows 8 (replacing the older RecentFileCache.bcf from Windows 7) to feed the Compatibility Appraiser, the component that decides whether installed software will survive an OS upgrade. To make that decision the appraiser has to inventory the software on the box — and that inventory, written to Amcache.hve, turned out to be a goldmine for investigators. The canonical reverse-engineering is Yogesh Khatri's 2013 work; the artefact has only grown richer since.

The practical consequence: Amcache exists on essentially every modern Windows host, it is enabled by default, and it accumulates a record of binaries that an attacker has no easy way to know about, let alone scrub selectively. For the file's on-disk location and how to copy it, see where Amcache.hve lives; for the registry view, where is the Amcache registry key.

How the appraiser builds it#

The Microsoft Compatibility Appraiser runs as a scheduled task, roughly daily, throttled by idle and power state. On each run it walks the filesystem and the installed-software inventory and updates Amcache.hve in place. Two things follow from this that shape every investigation:

• There is lag. A binary that appeared an hour ago may not be inventoried yet. Absence is never proof of absence — see why is my Amcache empty and how often Amcache updates.
• It is an inventory, not a log. One entry per file, updated in place. No run counts, no per-execution rows. That is Prefetch's department.

What this tool does#

This parser compiles a Rust registry-hive reader (nt-hive) to WebAssembly. Your Amcache.hve is read into memory and parsed in your browser. It is never uploaded.

That matters when the hive came from a regulated environment that does not allow file uploads to third-party services, or when you just want a fast look without standing up the full DFIR toolchain. Drop a hive on the home page to see every value, filter, and export to JSON or CSV — or use Eric Zimmerman's AmcacheParser for the offline command-line workflow.

The keys that matter#

Everything lives under a single Root key. The sub-keys you actually use:

Key	What it records	Why you care
InventoryApplicationFile	Per-file metadata — SHA-1 (FileId), full path, name, publisher, size, link date	The headline key. Program-presence and the hash pivot.
InventoryApplication	Installed applications	Software inventory, install dates.
InventoryDriverBinary	Loaded driver binaries, with hashes	BYOVD and rootkit hunting.
InventoryDeviceContainer	Connected devices (friendly names)	USB / peripheral history.
InventoryDevicePnp	PnP device interfaces	Technical device view; joins to DeviceContainer.
InventoryApplicationShortcut	.lnk shortcuts	Evidence of installed/launched apps.
Programs, File (legacy)	Older-build equivalents	Windows 8 / early 10 hives.

The richest of these by far is InventoryApplicationFile. The field-by-field breakdown is in AmcacheParser output columns, and the full schema tour in Amcache registry structure.

Why DFIR analysts reach for it#

Three properties make Amcache disproportionately useful:

1. It carries the SHA-1. Most Windows execution artefacts give you a path and a time. Amcache gives you the file's hash, which pivots cleanly into threat intel and across every host in the estate. See SHA-1 hashes for malware hunting.
2. It survives deletion. The inventory entry persists after the binary is gone — the classic reason to open Amcache first when a tool wiped itself. See Amcache and deleted files.
3. It pivots across hosts. The ProgramId and SHA-1 let you find the same software fleet-wide with one query — turning a single-host finding into a scoping answer.

What it does not tell you#

Understanding Amcache means understanding its boundaries as well as its strengths:

• An entry is presence, not execution. The appraiser inventories PEs that were on disk; for most cases that coincides with execution, but you corroborate with Prefetch, ShimCache, or process-creation events before calling it execution. The full nuance is in what the Amcache tells you.
• Scripts are invisible. No PE header, no entry. PowerShell- and batch-driven activity leaves no Amcache trace for the script logic itself.
• Timestamps are bounds, not events. KeyLastWriteTimestamp is the appraiser's write time; LinkDate is a forgeable compile stamp. Neither is "when it ran" — see timestamps decoded.

Putting it to work#

If you came here to use Amcache rather than understand it, the next step is the workflow: how to find evidence of execution with Amcache walks acquire → parse → filter → pivot → corroborate end to end. For the exhaustive artefact reference, see the Amcache complete reference.

Further reading#

• Yogesh Khatri, Amcache.hve in Windows 8 is a goldmine for malware hunters. The canonical reverse engineering.
• Eric Zimmerman's AmcacheParser. The de facto industry-standard offline tool.

Related#

• Amcache: the complete Windows .hve forensics reference
• How to find evidence of execution with Amcache
• Amcache vs Prefetch
• Amcache vs Shimcache
• Amcache registry structure