Volatility and Amcache: extracting the hive from memory images

AmcacheParser.exe reads the on-disk Amcache.hve file. But what if you only have a memory image — a Volatility-compatible RAM dump of a Windows host, with no disk acquisition?

The answer is Volatility, with its registry-hive plugins, used to extract the live in-memory copy of the Amcache hive and dump it to disk where AmcacheParser can read it. This page is the practical guide.

For the broader Amcache reference, see the Amcache complete reference; for the parser side, see the AmcacheParser complete guide.

When you need this#

The disk-side hive is usually the right source for Amcache analysis. The memory-side workflow is for the cases where you cannot get the disk:

• Memory-only acquisition. A live-response capture pulled a RAM dump and triage selected artefacts, but no full disk image is available.
• Volatile-evidence-first protocols. Some incident-response procedures dictate RAM capture before disk, and the disk capture is delayed by hours or days.
• The disk-side hive has been tampered with and you suspect the in-memory copy has fresher / different data.
• Encrypted disk, decrypted memory. Bitlocker / full-disk- encryption scenarios where the disk image is not yet decryptable but the RAM dump contains decrypted hive contents.

For ordinary live-host or post-incident disk forensics, prefer the disk-side workflow described in Where Amcache.hve is on disk.

What Volatility extracts#

Windows keeps every loaded registry hive — SYSTEM, SOFTWARE, SAM, NTUSER.DAT per user, and Amcache.hve if loaded — in kernel memory in a structure called the hive list. The appraiser typically loads Amcache.hve during inventory passes and keeps it loaded for some time after; a memory image captured during or shortly after an inventory pass contains the full hive in-memory.

Volatility's registry plugins know how to walk the hive list and extract individual hives. The relevant plugins:

The basic workflow is identical across versions, with command syntax differences.

Step 1: enumerate loaded hives#

First, see what hives are loaded in memory. Volatility 3:

vol -f memory.dmp windows.registry.hivelist

Volatility 2:

vol.py -f memory.dmp --profile=Win10x64_19041 hivelist

You should see a row for each loaded hive with a virtual address and the hive's file path. If Amcache was loaded, you see:

Offset (V)        FileFullPath
0xfffff8a0...     \??\C:\Windows\AppCompat\Programs\Amcache.hve

If Amcache is not in the hive list, the appraiser was not holding it open at capture time. Move on to disk-side acquisition or recovery; memory-only Amcache is not available for this image.

Step 2: dump the hive to disk#

Once you have the virtual address, dump the hive:

# Volatility 3 — replace 0xfffff8a0... with the real offset from hivelist
vol -f memory.dmp windows.registry.dumphive --offset 0xfffff8a0... > Amcache.hve

Volatility 2:

vol.py -f memory.dmp --profile=Win10x64_19041 dumpregistry \
       --offset 0xfffff8a0... --dump-dir ./dumped

The output is a binary blob that AmcacheParser can read. Note:

• There are no transaction logs. The in-memory hive representation does not carry .LOG1 / .LOG2. AmcacheParser will warn about missing logs; that is expected.
• The hive is a point-in-time snapshot of what was in memory at acquisition. It reflects whatever the appraiser had written through to the in-memory hive structure.

Step 3: parse with AmcacheParser#

Hand the dumped hive to AmcacheParser as usual:

AmcacheParser.exe `
  -f .\Amcache.hve `
  --csv .\out `
  --csvf MEMORY_amcache.csv `
  --mp

The output is the same per-category CSV set you would get from a disk-side parse — AssociatedFileEntries.csv, UnassociatedFileEntries.csv, and so on. Triage and pivot as in the malware investigation playbook.

Caveats specific to memory-side recovery#

A handful of things to be aware of when working from a memory-dumped hive:

Transaction-log data is lost#

The in-memory representation does not include uncommitted writes that were still in the transaction logs at capture time. For a hive that was actively being written when memory was acquired, you may be missing the very latest entries. Disk-side recovery of .LOG1 and .LOG2 would catch them.

Coverage depends on what was loaded#

Some Windows builds and configurations unload Amcache after each appraiser pass; others keep it loaded. If you find no Amcache in the hive list, it does not mean Amcache is absent on the host — it means it was not loaded at capture time.

Schema interpretation may need the right Volatility profile#

Volatility 2's profile must match the captured OS for the registry-walking code to work cleanly. Get the wrong profile and the dumped hive may be incomplete or corrupted. Volatility 3 is much more forgiving here (it auto-detects), but a wrong-profile dump is still possible.

The dumped hive may parse with warnings#

AmcacheParser may emit warnings about missing transaction logs, truncated cells, or unexpected schema. These are expected when dumping from memory and do not necessarily mean the data is bad — but treat anomalies with extra care and cross-reference with disk if possible.

Comparing memory and disk hives#

If you have both a memory dump and a disk image of the same host (taken at close times), parse both Amcache copies and diff them:

$disk   = Import-Csv .\HOST01_disk_amcache_UnassociatedFileEntries.csv |
            Select-Object Hash, FullPath, KeyLastWriteTimestamp
$memory = Import-Csv .\HOST01_memory_amcache_UnassociatedFileEntries.csv |
            Select-Object Hash, FullPath, KeyLastWriteTimestamp
 
# Rows in memory but not on disk
$memory | Where-Object { $h = $_.Hash; -not ($disk | Where-Object { $_.Hash -eq $h }) }
 
# Rows on disk but not in memory
$disk | Where-Object { $h = $_.Hash; -not ($memory | Where-Object { $_.Hash -eq $h }) }

What each delta means:

• In memory only: the appraiser wrote it to the in-memory hive but the change had not flushed to disk yet (and would have on a clean shutdown). Often the freshest signal you have.
• On disk only: the entry was in the disk hive but the in-memory hive had it unloaded / aged out at capture time. Less interesting — disk is authoritative for these.

If the disk hive has been tampered with, the memory hive often preserves the original entries — making the memory-side workflow also useful as an anti-forensics countermeasure.

When this is the wrong workflow#

Three cases where you should not bother with memory-side Amcache recovery:

You have the disk#

The disk-side workflow gives you the hive plus transaction logs plus Volume Shadow Copies. Memory-side gives you a single snapshot. Always prefer disk if available.

The acquisition was too long ago#

If the memory dump is days old and you are after current state, the on-disk hive (which has been updated since the dump) is more useful. Memory dumps are point-in-time.

The hive was not loaded at capture#

If hivelist does not show Amcache, no plugin will magic it into existence. Move to disk or to per-entry recovery from process memory of the appraiser (rare, advanced).

See also#

• Amcache complete reference — the artefact in full.
• AmcacheParser complete guide — what to do once you have the dumped hive.
• Where Amcache.hve is on disk — the disk-side workflow you should usually prefer.
• RegRipper amcache plugin — another parser that accepts the dumped hive.
• Recovering deleted-binary evidence from Amcache — useful framing for memory-side recovery scenarios.

If you have a hive (memory-dumped or otherwise) and just want a fast look, drop it on the parser home page — it runs entirely in your browser.