Where Amcache.hve is located on disk (and how to collect it)

If you are reaching for Amcache, the first practical question is "where is the file?". This page is the definitive answer for every Windows version you are likely to encounter, plus the right way to collect the hive so you do not silently lose the most recent data.

For the broader context on what Amcache records and why, see the Amcache complete reference.

The short answer#

On every supported Windows desktop and server build from Windows 8 onward, the hive lives at:

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

You want all three files, every time. The .LOG1 and .LOG2 files are the hive's transaction logs — if you take only Amcache.hve you can silently miss the most recent writes.

The longer answer: per-Windows-version#

Amcache moved around in its early days. The full history:

Windows 7 / Windows Server 2008 R2#

There is no Amcache.hve. The equivalent artefact is RecentFileCache.bcf, located at:

C:\Windows\AppCompat\Programs\RecentFileCache.bcf

It is a flat binary file (not a registry hive) with far less metadata than modern Amcache — typically just file paths and a single timestamp. AmcacheParser does not parse it; for RecentFileCache.bcf you want a dedicated parser like RecentFileCacheParser (also in the Zimmerman suite) or a Python script from the DFIR community.

If you are reading this in 2026 you are unlikely to encounter Windows 7 in production, but it still appears in legacy environments and in old triage images.

Windows 8 / 8.1 / Server 2012 / 2012 R2#

The hive Amcache.hve exists at the modern path, but the schema is the legacy schema with only Root\Programs and Root\File keys:

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

AmcacheParser handles the legacy schema and produces a ProgramEntries.csv from Root\Programs. There is far less per-file detail than on Windows 10+.

Windows 10 / 11 (current)#

Same path as Windows 8, but the hive now contains the full Inventory* schema (added in Windows 10 build 1709, Fall Creators Update). This is what most modern analysis targets:

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

Windows Server 2016 / 2019 / 2022 / 2025#

Identical path to Windows 10/11. The schema is the same. The appraiser runs less frequently on servers than on desktops (often several days between passes rather than daily), so the hive's "latest write" timestamp tends to be older on a server than a workstation in the same environment. See Amcache on Windows Server for the server-specific quirks.

In a forensic disk image#

When you are working with an acquired image rather than a live system, the file lives at the same path inside the image's C: partition:

<image>\Windows\AppCompat\Programs\Amcache.hve
<image>\Windows\AppCompat\Programs\Amcache.hve.LOG1
<image>\Windows\AppCompat\Programs\Amcache.hve.LOG2

If you have mounted the image read-only (via Arsenal Image Mounter, FTK Imager, or losetup + mount -o ro on Linux), the path is literally the file system path under the mount point. AmcacheParser takes a normal file path and reads the hive without locks — no special handling needed.

Volume Shadow Copies#

On a workstation that has been running for months, you may find multiple copies of Amcache.hve inside Volume Shadow Copies. Each shadow copy is a point-in-time snapshot of the volume, and each contains its own snapshot of Amcache.hve and its logs.

For an investigation where you suspect anti-forensics tampering of the live hive, always check the shadow copies. They are mounted at paths like:

\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\AppCompat\Programs\Amcache.hve
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\AppCompat\Programs\Amcache.hve
...

You can enumerate them with vssadmin list shadows on a live system or with vshadowmount from libvshadow on a forensic image. Each copy is a separate parse target — feed them all to AmcacheParser and diff the output if you suspect the live hive was modified.

On a live system#

If you absolutely must read the hive on a live, running Windows host (for example, during a triage with no time for a full image):

Do not parse C:\Windows\AppCompat\Programs\Amcache.hve in place. The hive is open by the system; reading it directly is unreliable and forensically poor practice.

Do copy the hive + both logs to a working directory first. The standard PowerShell pattern:

$target = 'C:\Triage\Amcache'
New-Item -ItemType Directory -Path $target -Force | Out-Null
 
# Need elevated PowerShell. Copy hive + logs together.
Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve'      $target -Force
Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve.LOG1' $target -Force
Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve.LOG2' $target -Force
 
# Hash everything for chain of custody
Get-ChildItem $target -Filter Amcache.hve* |
  ForEach-Object { Get-FileHash -Algorithm SHA256 $_.FullName }

If the file system refuses to copy Amcache.hve because it is held open by the appraiser, the fallback is to use a raw-volume reader:

• RawCopy.exe (from the Joakim Schicht suite) reads the file bypassing file-system locks.
• Get-RawFile in PowerShell does the same via CreateFile with FILE_FLAG_BACKUP_SEMANTICS.
• KAPE uses the same technique internally — see the next section.

Collection with KAPE#

KAPE's Amcache target is the easiest correct way to collect the hive on a live or imaged system:

.\kape.exe `
  --tsource C: `
  --target Amcache `
  --tdest .\out\HOST01\collected

What KAPE does:

1. Bypasses file-system locks using its raw-volume reader.
2. Copies Amcache.hve + Amcache.hve.LOG1 + Amcache.hve.LOG2 into out\HOST01\collected\C\Windows\AppCompat\Programs\.
3. Preserves original timestamps and writes a log of what was collected.

Pair the Amcache target with the AmcacheParser module for a one-line collect-and-parse pipeline. See the AmcacheParser CLI cheatsheet for KAPE patterns.

Collection with Velociraptor#

For fleet collection, Velociraptor's Windows.Forensics.Amcache artifact handles it remotely:

artifacts:
  - Windows.Forensics.Amcache
  parameters:
    - name: AmcacheGlob
      value: 'C:\Windows\AppCompat\Programs\Amcache.hve*'

The trailing * in the glob is intentional — it matches the hive and both transaction logs in one pass. The artifact downloads AmcacheParser if needed, runs it server-side, and uploads the CSV output. Pair it with a hunt to run across thousands of endpoints on a schedule.

Common collection mistakes#

A short list of mistakes that come up over and over in incident work, in rough order of frequency:

1. Copying only Amcache.hve without the .LOG1 / .LOG2 files. Silently drops the most recent writes. Always copy all three.
2. Reading the live hive in place. Sometimes works, sometimes produces a parse error, sometimes produces a plausible-looking but wrong parse. Always copy first.
3. Forgetting Volume Shadow Copies in a tampering investigation. The live hive may have been wiped; the shadow copies preserve history.
4. Hashing the hive after parsing. Hash before parsing too, so you can prove the parsing did not modify it.
5. Not preserving timestamps on collected copies. Use Copy-Item -Force (which preserves) or robocopy with /COPY:DAT. The original LastWriteTime of the hive file is itself useful evidence.

See also#

• Amcache complete reference — what the hive records and why it matters.
• AmcacheParser complete guide — how to parse the file you just collected.
• AmcacheParser CLI cheatsheet — collection-to-parse patterns for KAPE and Velociraptor.
• Amcache registry structure and keys — what is inside the hive once you can read it.

Want to look at a hive you just collected without installing anything? Drop it on the parser home page — it never leaves your browser.