Amcache.hve on Windows 11: What It Records and How to Read It

Why Amcache Is Worth the Trouble

Most execution artifacts give you a path and a time. Amcache gives you a SHA-1 hash.

That single field changes what you can do. A binary that was deleted three weeks ago is, from every other artifact's point of view, just a filename — and filenames are trivially faked. Amcache lets you take the hash, put it into VirusTotal or a threat intel feed, and find out what the file actually was without ever having the file.

What It Is

C:\Windows\AppCompat\Programs\Amcache.hve is a registry hive, not a normal registry key — it is loaded on demand rather than mounted at HKLM. It backs the Application Compatibility infrastructure: Windows catalogues executables so it knows whether to apply compatibility shims.

The subkeys that matter on Windows 11:

• Root\InventoryApplicationFile — the per-executable records. This is where the SHA-1 lives.
• Root\InventoryApplication — installed applications, publisher, install date.
• Root\InventoryDriverBinary — drivers, with hashes. Useful for rootkit and unsigned-driver work.
• Root\InventoryDeviceContainer — attached hardware.

The Thing Everyone Gets Wrong

Amcache is presence evidence, not execution evidence.

An entry means Windows' compatibility inventory saw the file. That happens on execution, but it also happens during scheduled inventory sweeps, installer activity, and antivirus scans. A file that was copied to disk and never run can appear in Amcache.

Treat an Amcache entry as "this file was on this machine, at this path, and here is its hash". If you need "it ran", get that from Prefetch or BAM.

The corollary is the useful half: Amcache catches things that never ran. Staged payloads, dropped tools, files pulled down and abandoned — all invisible to Prefetch, all present here.

Step 1: Copy the hive and its transaction logs

The hive is locked while Windows is running, and — this is the part usually skipped — recent writes may live only in the transaction logs. Take all three:

robocopy C:\Windows\AppCompat\Programs C:\cases\amcache Amcache.hve Amcache.hve.LOG1 Amcache.hve.LOG2

If robocopy cannot read the locked hive, use a raw-access copy tool or work from a disk image. Copying the .hve without the .LOG files gives you a stale hive, and stale is worse than missing because it looks complete.

Step 2: Replay the logs and parse

AmcacheParser replays the transaction logs automatically when they sit alongside the hive:

AmcacheParser.exe -f C:\cases\amcache\Amcache.hve --csv C:\cases\out -i

The -i switch includes entries that AmcacheParser would otherwise filter as Microsoft-signed noise. Start without it; add it when you need completeness over signal.

You get several CSVs. *_UnassociatedFileEntries.csv is the one to open first — executables not tied to an installed application, which is where dropped tooling lands.

Step 3: Sort by the right timestamp

Two time fields matter and they are not the same thing:

• FileKeyLastWriteTimestamp — when the Amcache record was written. Approximately when Windows first catalogued the file.
• LinkDate — the PE compile timestamp from the binary's header. Attacker-controllable and routinely forged, but a LinkDate in the future or set to an obviously fake epoch is a flag in itself.

Sort on FileKeyLastWriteTimestamp to build a "when did this appear on the machine" timeline.

Step 4: Pull the hashes and check them

The SHA1 column is the payoff. Note that AmcacheParser reports it with a leading 0000 on some record types — strip that before lookups.

Take the hashes for anything unrecognised and check them against VirusTotal or your own intel source. This works on files that no longer exist on disk, which is the entire reason to do this.

Step 5: Cross-reference paths against execution

For each interesting hash, take its FullPath and check whether a matching .pf file exists in Prefetch. Four outcomes:

| Amcache | Prefetch | Reading | |---|---|---| | Present | Present | File was on disk and ran | | Present | Absent | File was staged; may never have run | | Absent | Present | Ran before Amcache catalogued it, or the record was cleared | | Absent | Absent | No evidence from these two sources |

Where It Falls Down

Retention is not guaranteed. Amcache is maintained by a scheduled task (Microsoft Compatibility Appraiser) and its contents get trimmed. It is not an append-only log.

Version differences are real. The key structure changed significantly between Windows 7, 8, 10 1607+, and again on 11. References written against Root\File\{volume GUID} describe the old layout; Windows 11 uses Root\InventoryApplicationFile. Use a parser that tracks this rather than browsing the hive by hand.

Path is where the file was, not where it is. Amcache holds the path at catalogue time. The file may have been moved since, and the entry will not follow it.

Related

• ShimCache vs Amcache vs Prefetch — which one answers which question
• Windows 11 forensic artifacts overview
• Consumer guide: removing a rootkit or bootkit — InventoryDriverBinary is the relevant Amcache subkey there

FAQ

Does an Amcache entry prove a program was executed?

No, and this is the most common misreading of the artifact. It proves Windows' compatibility inventory catalogued the file, which happens on execution but also during inventory sweeps, installs, and scans. For execution, corroborate with Prefetch, BAM, or UserAssist.

Why do I need the .LOG1 and .LOG2 files?

Registry hives use transaction logs, and on a running system the most recent writes may exist only in those logs and not yet in the hive itself. Parsing the .hve alone gives you a stale view that looks complete — which is worse than obviously missing data, because you will not know to distrust it.

Can Amcache tell me about files on a USB drive?

Yes, if they were executed or catalogued while the drive was attached. The FullPath field records the drive letter at the time, so an entry pointing at E:\tools\ for a machine with only a C: volume tells you something ran from removable media. Pair it with USB device history to identify which device.

Is the SHA-1 in Amcache reliable?

The hash itself is computed by Windows over the file and is accurate for what was on disk at catalogue time. The caveat is scope: on some record types AmcacheParser reports a value with leading zeros that must be stripped, and for very large files Windows may hash only part of the file. Verify against a known-good sample before treating a hash mismatch as significant.