Amcache: the complete Windows .hve forensics reference

TL;DR — Amcache in one paragraph. Amcache is a Windows registry hive (Amcache.hve) maintained by the Microsoft Compatibility Appraiser. It records every PE binary the appraiser has inventoried on the host, with SHA-1 hash, full path, publisher, PE link date, and the inventory timestamp. Analysts use it to prove a binary was present (not necessarily executed), pivot on hash across hosts, and recover evidence of deleted attacker tools.

Amcache.hve is the Windows registry hive that records which programs have been present or executed on a machine, with rich metadata: full path, SHA-1 hash, PE link date, publisher, version, and the inventory time. For digital forensics and incident response it is one of the four artefacts every Windows analyst learns first — alongside Prefetch, ShimCache, and the Security event log.

This page is the canonical reference to the artefact itself: what it is, where it lives, how Windows produces it, what each top-level key contains, how to use it in an investigation, and how it relates to neighbouring execution-evidence sources. For coverage of parsing tools, see the AmcacheParser complete guide; for the original short introduction, see Understanding Amcache for Windows forensics.

Amcache at a glance vs the neighbouring artefacts#

The single most common question new Amcache analysts ask is "how is this different from ShimCache / Prefetch / SRUM?" Quick reference:

Artefact What it proves Hash? Path? Capacity Source
Amcache.hve Binary was present on host ✅ SHA-1 (first 31 MiB) ✅ Full Thousands of entries Compatibility Appraiser
ShimCache (AppCompatCache) Binary was seen by the loader ❌ ✅ Full ~1,024 entries (LRU) Application Compatibility loader
Prefetch Binary was executed ❌ ✅ Full ~1,024 .pf files Windows Prefetcher (Pf service)
SRUM Binary consumed resources over 30+ days ❌ ✅ Full App-level rollups System Resource Usage Monitor
Security 4688 Process was created (real-time) ❌ ✅ Full Bounded by log rollover Audit subsystem

Pivot rule of thumb: Amcache for presence and hash; ShimCache for loader-seen list; Prefetch for execution; SRUM for usage over time; 4688 for the real-time event. Detail on each pairing: Amcache vs ShimCache, Amcache vs Prefetch, Amcache vs SRUM, Amcache vs AppCompatCache.

What Amcache actually is#

Amcache is a registry hive — the same binary format as SYSTEM, SOFTWARE, SAM, SECURITY, and NTUSER.DAT. It is not a log file, not a database, not a flat list. It is a key/value tree with typed values, and that structure is what makes it both rich and slightly painful to read by hand.

The hive is populated by the Microsoft Compatibility Appraiser, a scheduled task that ships with Windows under \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser. The appraiser scans the system for installed and present software, gathers PE-header metadata for each file, and writes structured inventory records into the hive. On modern Windows 10 and 11 builds the appraiser runs roughly daily; on Windows Server builds the cadence varies but is typically multiple times a week.

The appraiser was originally part of the Customer Experience Improvement Program (CEIP) infrastructure — Microsoft's mechanism for sending compatibility telemetry to its servers ahead of major Windows upgrades. The forensic value of Amcache is, in a sense, an accident of that telemetry pipeline: the appraiser had to maintain a local inventory to know what to send, and that local inventory is what analysts now pivot on.

Why analysts care#

Amcache answers a question no other Windows artefact answers as cleanly:

"Has this executable ever been present on this host, and if so, with what SHA-1, at what path, and around when?"

Three things make that question high-value in DFIR:

  1. It survives deletion. A wiper can remove the binary from disk; the inventory snapshot in the hive remains until the next appraiser pass — and even then the previous run is often still in the transaction logs.
  2. It pre-hashes the binary. Amcache stores the SHA-1 of the first ~31 MiB of the file at inventory time. Even if you no longer have the binary, you can submit that hash to VirusTotal, threat intel feeds, or your internal allowlist database.
  3. It records the path. Where the binary lived on disk is often the entire story — \Users\<name>\AppData\Local\Temp\svchost.exe is its own indictment.

Where Amcache lives#

On a live Windows system:

C:\Windows\AppCompat\Programs\Amcache.hve
C:\Windows\AppCompat\Programs\Amcache.hve.LOG1
C:\Windows\AppCompat\Programs\Amcache.hve.LOG2

The .LOG1 and .LOG2 files are the hive's transaction logs — the same write-ahead log mechanism every registry hive uses. Always collect all three together. If you grab only Amcache.hve, you can silently miss the most recent writes, because the latest changes may still be sitting in the logs waiting to be flushed.

For the full location-related question set (older Windows paths, where it sits in a forensic image, how KAPE / Velociraptor collect it), see Where Amcache.hve is on disk.

History across Windows versions#

The hive has a small but messy history:

  • Windows 7 / Server 2008 R2 introduced the artefact as RecentFileCache.bcf — a flat binary file, not a hive, and much poorer in metadata. It is not directly comparable to modern Amcache.
  • Windows 8 / 8.1 introduced Amcache.hve in its hive form with the Root\File and Root\Programs keys (the "legacy" schema).
  • Windows 10 build 1709 (Fall Creators Update) added the Root\InventoryApplicationFile and related Inventory* keys — the modern schema. The legacy keys remained for compatibility on some builds but became sparser over time.
  • Windows 11 continues the Windows 10 schema with minor additions, notably more granular driver and device-container records.

When you parse a hive, you are usually working with the modern Inventory* schema. The legacy Root\Programs and Root\File keys are still worth checking on old systems and on builds where the appraiser has been disabled — they sometimes capture data the modern keys miss. We cover Windows-version specifics in Amcache on Windows 11 and 10 and Amcache on Windows Server.

The hive structure#

At the top level, the hive has a single Root key with these notable sub-keys (on a modern Windows 11 system):

Root\
├── InventoryApplication
├── InventoryApplicationDriver
├── InventoryApplicationFile
├── InventoryApplicationFramework
├── InventoryApplicationShortcut
├── InventoryDeviceContainer
├── InventoryDeviceInterface
├── InventoryDevicePnp
├── InventoryDriverBinary
├── InventoryDriverPackage
├── InventoryMiscellaneousUUPInfo
├── File             (legacy)
└── Programs         (legacy)

The five that DFIR analysts touch on essentially every case:

Key Records
InventoryApplicationFile Every PE file the appraiser inventoried, with full path, SHA-1, link date, publisher, version. The richest single source.
InventoryApplication Installed applications (MSI / Add-Remove Programs entries). Parents for the file records via ProgramId.
InventoryDriverBinary Every driver binary the system loaded, with signed/kernel-mode flags. Critical for BYOVD investigations.
InventoryDeviceContainer Friendly-name device records: printers, displays, removable-media controllers.
InventoryDevicePnp PnP enumeration records, one per device interface. Pairs with InventoryDeviceContainer via InstanceId.

For a key-by-key breakdown — every sub-key, every notable value, and what it means — see Amcache registry structure and keys.

Schema versioning#

Amcache's schema has shifted multiple times over Windows 10's lifetime. New value names appear; old ones disappear or change type. This is why a generic registry viewer is a poor tool for Amcache — the values it shows are correct but unlabelled, and you spend more time correlating against blog posts than analysing. Use a purpose-built parser (AmcacheParser, this site's browser-based parser, or RegRipper's amcache plugin) and let the tool track the schema for you.

The fields analysts actually use#

A handful of values per inventory entry carry 90% of the investigative weight:

FileId#

The 41-character string "0000" + sha1_hex that uniquely identifies a file by content. The leading 0000 is a historical type tag; the remaining 40 hex characters are the SHA-1 of the first 31 MiB of the file. Strip the prefix and you have a hash you can submit to VirusTotal, IOC feeds, or your hash-allowlist database directly.

A few traps:

  • The hash covers only the first 31 MiB, not the whole file. For installers and large binaries it is still distinctive, but it is technically a prefix hash, not a full-content hash.
  • Files smaller than 31 MiB are fully hashed, so the result matches a standard SHA-1.

Full coverage: Amcache FileId explained.

ProgramId#

A 44-character identity hash Windows assigns to a logical application — a combination of name, publisher, version, and language. The same ProgramId ties a file in InventoryApplicationFile to the parent application record in InventoryApplication. It is also stable across hosts: two machines with the same application installed typically share the same ProgramId for it, which makes it a useful pivot for cross-host hunts.

Full coverage: Amcache ProgramId explained.

Timestamps#

Amcache exposes multiple different timestamps, and confusing them is the #1 mistake new Amcache analysts make:

Field What it represents
KeyLastWriteTimestamp Registry last-write of the key containing this entry. The closest thing to "when Amcache recorded this file".
LinkDate PE-header TimeDateStamp — when the binary was compiled / linked. Attacker-controllable; do not treat as evidence of presence time.
LastModified (when present) Inventory-side last-modified marker; not present in every schema version.
MsiInstallDate When the parent MSI was installed (if the file came from one).

The right pivot for "when did this binary appear on this host?" is KeyLastWriteTimestamp. Full coverage: Amcache timestamps explained.

Path, publisher, IsPeFile#

The "is this suspicious?" triage filter most analysts standardise on:

IsPeFile = True AND Publisher is empty AND FullPath is under \Users\, \AppData\, \ProgramData\, or \Temp\.

That single filter, applied to InventoryApplicationFile, surfaces the vast majority of commodity-malware artefacts on a typical infected host. It also throws plenty of false positives — pirated software, custom developer scripts, portable apps — which is why it is a triage filter, not a detection rule.

What Amcache is not#

Three persistent misconceptions are worth correcting up front, because they routinely produce wrong findings:

Amcache is not "proof of execution"#

A binary appearing in Amcache means the appraiser saw the file on disk at inventory time. The appraiser inventories files based on where they live (Program Files, ProgramData, the Start menu, recently touched paths) — not based on whether they ran. A binary can appear in Amcache without ever having executed.

For execution, you need Prefetch (the strongest signal), process-creation events (4688 / Sysmon 1), ShimCache as a corroborating signal, or SRUM for longer-window correlation. See Amcache vs Prefetch and Amcache vs ShimCache for the canonical distinctions, and Amcache vs SRUM for the longer-window pairing.

Amcache is not complete#

The appraiser misses things:

  • Files outside the paths it scans.
  • Files that came and went between appraiser runs.
  • Files on a host where the appraiser has been disabled (some hardened endpoints).
  • On older Windows builds, files outside the legacy Programs / File scope.

Absence from Amcache is not evidence that a binary was never present. It is evidence only that the appraiser did not see it.

Amcache is not tamper-evident#

The hive lives on disk in a known location. An attacker with admin privileges can modify it, delete it, or — more subtly — modify the appraiser's schedule so it stops recording. None of this is common in commodity intrusions (the value of cleaning Amcache is rarely worth the noise it generates) but it is possible, and you should treat Amcache as one signal among many, not as ground truth.

Using Amcache in an investigation#

The standard investigative loop on a Windows-only intrusion:

  1. Collect. Grab Amcache.hve + Amcache.hve.LOG1 + Amcache.hve.LOG2. KAPE's Amcache target does this in one command; Velociraptor's Windows.Forensics.Amcache artifact does it remotely.
  2. Parse. Run AmcacheParser with --mp to recover orphaned entries. You will get a CSV per category.
  3. Triage filter. Apply the "unsigned PE in user-writable path" filter to *_UnassociatedFileEntries.csv. This produces a manageable list — typically tens of rows on a typical infected host.
  4. Pivot. For each surviving row, take the SHA-1 hash and check it against VirusTotal, your TI feed, and your historical detections. For each row, also check the FullPath against your file-system timeline and Prefetch CSV — does Prefetch show the same binary executing? Does the file still exist on disk?
  5. Corroborate execution. Cross-reference matches against Prefetch (definitive execution), Sysmon 1 / 7 (process and image-load), and Security 4688 (process creation) if enabled.
  6. Time-bound. Take KeyLastWriteTimestamp of suspicious rows and build a tight time window around them. Pull all events, file-system changes, and registry writes from that window for the full picture.

For specific scenarios, the use-case posts cover the playbook in detail:

Tooling landscape#

You have several reasonable choices for actually parsing the hive:

Tool Best for
Eric Zimmerman's AmcacheParser Production DFIR on a Windows analyst workstation. The canonical implementation.
Browser-based parser (this site) Triage, education, non-Windows analysts, locked-down hosts. Runs in WebAssembly, file never leaves the browser.
RegRipper amcache plugin Quick interactive analysis as part of a broader RegRipper sweep.
Volatility plugins Pulling the hive out of a memory image, then handing to AmcacheParser.

For the practical question "which one should I use now", the answer is almost always: Eric's AmcacheParser.exe for the investigation, this site's browser parser for triage or a quick look without installing anything. The RegRipper and Volatility paths exist for specific contexts — interactive RegRipper sweeps and memory-only acquisitions, respectively.

Frequently asked questions#

How big is Amcache.hve typically?#

On a typical Windows 11 workstation, Amcache.hve ranges from 2 MB to 25 MB. Heavily-used developer workstations and servers with many short-lived binaries can push past 50 MB. The transaction logs are small (usually <1 MB each).

How far back does Amcache go?#

The hive is not bounded by time but by Windows's own retention behaviour. On a long-lived workstation you can see inventory entries months or years old, especially for Inventory* records where the binary is still present on disk. Once a binary is removed and the appraiser has had several passes to notice, the corresponding entry typically (but not always) ages out.

Does Amcache record DLLs?#

Yes, in modern schemas. InventoryApplicationFile records both EXEs and DLLs (filtered to PE files generally). Pre-Windows-10-1709 hives may not, depending on the build.

Does Amcache record scripts?#

Generally no for .ps1, .bat, .vbs, .js, etc. — Amcache focuses on PE binaries. Script execution evidence comes from PowerShell operational logs, AMSI, Sysmon, or Prefetch (for cscript.exe / wscript.exe invocations themselves).

What's the relationship between Amcache and ShimCache?#

They are different artefacts despite both involving application compatibility. ShimCache (AppCompatCache in the SYSTEM hive) is maintained by the loader for application-compatibility purposes and records up to 1024 entries per host with limited metadata. Amcache is maintained by the appraiser for compatibility-telemetry purposes and records thousands of entries with rich metadata. See Amcache vs ShimCache for the full comparison.

Can I read Amcache.hve on Linux or macOS?#

Yes. Use dotnet AmcacheParser.dll on a host with the .NET runtime, or use this site's browser-based parser which runs in WebAssembly and works in any modern browser regardless of host OS. The hive format is portable.

Is Amcache evidence admissible in court?#

That depends on jurisdiction and how the evidence was collected. Amcache itself is well-documented and widely used in DFIR, which helps. The usual rules apply: preserve the hive (and its transaction logs) with documented chain of custody, hash it before and after, and use a documented parser whose behaviour you can defend.

Where to next#

If you arrived here looking for...

Tagsforensicswindowsamcachedfirregistry

Related posts

← Back to all posts