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

The first practical question on any Amcache case is where the file is. This page is the definitive answer for every Windows version you are likely to see, plus the right way to collect the hive so you don't silently lose the most recent data.

For the broader context, see the Amcache complete reference.

The short answer#

On every supported Windows desktop and server from Windows 8 onward:

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

All three. Every time. .LOG1 and .LOG2 are the registry hive's transaction logs. Take only the main hive and you silently miss the most recent writes.

Per Windows version#

The artefact has moved around in its early days. Full history:

Windows 7 / Server 2008 R2#

No Amcache.hve. The predecessor is RecentFileCache.bcf:

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

Flat binary (not a hive) with far less metadata. AmcacheParser does not handle it. Use RecentFileCacheParser or one of the community Python scripts. If you are reading this in 2026 you are unlikely to see Windows 7 in production, but it shows up in legacy environments and old triage images.

Windows 8 / 8.1 / Server 2012 / 2012 R2#

Amcache.hve exists at the modern path but the schema is legacy with only Root\Programs and Root\File keys. AmcacheParser produces *_ProgramEntries.csv but per-file detail is thin.

Windows 10 / 11 (current)#

Same path as Windows 8, but the hive carries the full Inventory* schema (added in Windows 10 build 1709, October 2017). This is what most modern analysis targets.

Windows Server 2016 / 2019 / 2022 / 2025#

Identical path. Identical schema. The appraiser runs less often than on desktops (every several days rather than daily), so the hive's latest write tends to be older. See Amcache on Windows Server for the server-specific quirks.

From a forensic disk image#

When working an image rather than a live system, the file lives at the same path inside the C: partition:

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

Mount read-only (Arsenal Image Mounter, FTK Imager, losetup + mount -o ro on Linux) and the path is literally the filesystem path under the mount point. AmcacheParser takes a normal file path and reads without locks. No special handling needed.

Volume Shadow Copies#

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

For investigations where you suspect anti-forensics tampering of the live hive, always check shadows. They mount at paths like:

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

Enumerate with vssadmin list shadows on a live system or vshadowmount from libvshadow on a forensic image. Each is a separate parse target. Diff their outputs if you suspect the live hive was modified.

On a live system#

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

Don't parse C:\Windows\AppCompat\Programs\Amcache.hve in place. The hive is held open by the appraiser. Reading it directly is unreliable and forensically poor practice.

Do copy hive + both logs to a working directory first. Standard PowerShell pattern:

$target = 'C:\Triage\Amcache'
New-Item -ItemType Directory -Path $target -Force | Out-Null
 
# 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 for chain of custody
Get-ChildItem $target -Filter Amcache.hve* |
 ForEach-Object { Get-FileHash -Algorithm SHA256 $_.FullName }

If the filesystem refuses to copy because the appraiser has the file open, fall back to a raw-volume reader:

• RawCopy.exe (Joakim Schicht suite). Reads the file bypassing filesystem locks.
• Get-RawFile in PowerShell. Same idea via CreateFile with FILE_FLAG_BACKUP_SEMANTICS.
• KAPE uses the same technique internally. See below.

Collection with KAPE#

KAPE's Amcache target is the easiest correct way:

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

What KAPE does:

1. Bypasses filesystem locks with its raw-volume reader.
2. Copies Amcache.hve + .LOG1 + .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 handles it remotely:

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

The trailing * 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 with a hunt for thousands of endpoints on a schedule.

Common collection mistakes#

Roughly in order of how often they come up on real cases:

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

Further reading#

• KAPE documentation, particularly the !Acquisition and !SANS_Triage compound targets.
• Velociraptor's documentation for Windows.Forensics.Amcache.
• libvshadow / vshadowmount on Linux for read-only access to VSS snapshots from a forensic image.

Related#

• Amcache complete reference
• AmcacheParser complete guide
• AmcacheParser CLI cheatsheet
• Amcache registry structure