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

URL: https://www.mytechnician.tech/labs/amcache-hve-windows-11-forensics/
Published: 2026-08-08 | Author: Ankit Kumar
Track: Forensic artifact | Difficulty: Intermediate | Authorization: defensive
Time required: 30 min
Verified on: Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch, AmcacheParser 1.5
MITRE ATT&CK: T1057
Tags: Forensics, Execution Artifacts, Registry, Windows 11
Summary: Amcache stores the SHA-1 of executables Windows has encountered — including ones already deleted. Here is how to parse it on Windows 11 and what its entries do and do not prove.

## 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](https://www.mytechnician.tech/labs/prefetch-files-windows-11-proving-execution/) 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](https://www.mytechnician.tech/labs/shimcache-vs-amcache-vs-prefetch-execution-evidence/) — which one answers which question
- [Windows 11 forensic artifacts overview](https://www.mytechnician.tech/labs/windows-11-forensic-artifacts-program-execution/)
- Consumer guide: [removing a rootkit or bootkit](https://www.mytechnician.tech/tips/remove-rootkit-bootkit-windows-11/) — `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](https://www.mytechnician.tech/labs/usb-device-history-windows-11-registry-setupapi/) 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.

---

Source: https://www.mytechnician.tech/labs/amcache-hve-windows-11-forensics/ — My Technician Security Labs.
Authorization: defensive. This write-up is published for defensive and educational use on systems you own or are authorized to test.
More labs: https://www.mytechnician.tech/labs/