RecentFileCache vs AmCache: which one is on your host, and why

If you are pulling artifacts off an unknown host and you find both RecentFileCache.bcf and Amcache.hve in C:\Windows\AppCompat\Programs\, stop and check the Windows build. You are looking at something unusual.

On a normal Win7 SP1 host: BCF only. On a normal Win8 or later host: AmCache only. Both: a Win7 host that was upgraded in place to Win10 and inherited the old file. It happens. Rarely.

The two artifacts solve overlapping problems but they are not the same thing, and the boundaries matter when you write findings.

The version boundary

RecentFileCache.bcf was the working file for the Application Experience appraiser on Windows 7 SP1 and Windows Server 2008 R2. Starting in Windows 8, Microsoft replaced the appraiser pipeline and the BCF disappeared. The replacement, Amcache.hve, is an ESE-shaped registry hive with richer per-entry metadata. The two formats were never meant to coexist.

The version boundary is sharp. Windows 8 RTM does not write a BCF. Windows 7 SP1 does not write an AmCache. There is no middle ground in normal operation.

The exception, and it is real: an in-place upgrade from Windows 7 to Windows 10 can leave the old RecentFileCache.bcf on disk because the installer does not delete it. The Win10 appraiser will not touch it. The file just sits there. I have personally seen this twice on long-lived enterprise endpoints whose owners did clean replacements only after the hardware died. Both times the BCF held entries from years before the upgrade. Useful, in the sense that it pinned execution to a specific year. Not useful for current investigations.

Lifecycle differences

This is where the two diverge most.

The BCF is a write-ahead log. The Application Experience task processes the file roughly daily, then truncates it. A binary in the BCF ran in roughly the last 24 hours. Older executions are gone.

The AmCache is closer to a long-lived database. The Root\InventoryApplicationFile keys persist across appraisal passes. Entries can survive for the lifetime of the install. The cadence of writes is different too: AmCache updates happen during the appraisal pass, but old entries are not cleared on the same schedule. You can find AmCache entries that are months old.

For investigations, this means:

BCF answers "did this run in the last day or so?"
AmCache answers "has this been seen on this machine at any point in recent history?"

Two different forensic questions. Two different shapes of evidence.

What each one records

The BCF records:

Full NT path of the executable.
Nothing else.

The AmCache records:

Full path.
SHA1 hash of the first 31 megabytes of the file (or the whole file if smaller).
File size, PE header timestamp, link date.
Publisher, product name, version (from the PE resources).
An install time approximation.
Driver-specific keys under Root\InventoryDriverBinary.
A bunch of other less consistently populated fields, depending on the Windows build.

That hash is the big one. With the AmCache you can pivot to threat intel. With the BCF you cannot. You have to acquire the binary off disk or reconstruct it from another source and hash it yourself.

In return, the BCF gives you something the AmCache does not: a stricter claim about execution. The BCF's contents are limited to binaries that the appraiser believes were executed. The AmCache has columns that hint at execution (the Root\InventoryApplicationFile last-modified timestamps, for example) but the AmCache itself is more inventory-shaped than execution-shaped. Plenty of binaries in the AmCache never ran on the host; the appraiser scanned them. The BCF, when it exists, is closer to a clean execution record.

If you have only the AmCache, lean on Prefetch and EVTX 4688 / Sysmon 1 for execution confirmation. The AmCache alone does not prove a binary ran. The BCF alone does, to within an appraisal-window margin.

When you would see both

The legitimate case I described above: a host upgraded from Win7 to Win10 with the old BCF still present. The BCF entries date from the pre-upgrade life of the machine.

The less legitimate case: somebody dropped a RecentFileCache.bcf on a Win10 host as a misdirection. I have seen this exactly once, in a CTF, never in a real incident. Worth noting because it is a possibility, not because it is common. Check the file's MFT entry creation time against the system's install date. A BCF created last week on a Win10 box installed in 2022 is fake.

The third case, which is not "both at the same time" but worth flagging: a Win7 host that has been migrated to a domain whose policy disables the appraiser task. The BCF will accumulate without being cleared. You can end up with a BCF that holds eighteen months of executions because nothing has rotated it. That file is a goldmine, and you should grab it on first contact.

Mapping a BCF entry into AmCache thinking

If you are an analyst whose entire career has been on Windows 10, the BCF can feel unfamiliar. Two translations that help:

A BCF entry is equivalent to an InventoryApplicationFile row that was added since the last appraisal pass, minus all the metadata columns.
The "last execution timestamp" you reach for in AmCache parsers does not exist in the BCF. The closest thing is the file's own last-modified timestamp, which tells you when the appraiser last wrote to it, not when any individual entry ran.

If you live in the AmCache world and switch to a Win7 case, the loss of metadata is the hardest part. You go from "I know the hash, the publisher, and roughly when it was installed" to "I know the path." The path is still useful. It is just not as much.

Practical decision tree

When you land on a host and need to know which artifact to pull:

Check the build. winver, or the SYSTEM hive's Setup\InstallationType / CurrentVersion.
If Win7 SP1 or Server 2008 R2: BCF. Grab it before the next appraisal pass.
If Win8 or later: AmCache. The BCF, if present, is historical and probably not relevant.
If both: probably an upgrade-in-place. Treat the BCF as pre-upgrade history and the AmCache as current.
If you are on Server 2012 R2, expect AmCache and a quirky earlier schema. The AmCache parser handles the schema variations.

Pair both artifacts with the corroborating sources you always pair execution evidence with: Prefetch, Shimcache, USN journal, and MFT. Neither one is a standalone proof.

A note on tooling parity

The forensic community has had production-grade parsers for both formats for over a decade. The BCF is genuinely easy to parse; the AmCache is harder because the ESE format and the schema-variance across Windows builds add complexity. Eric Zimmerman's AmcacheParser is the reference for the AmCache. For the BCF, several open-source parsers and the parser on this site all produce equivalent output because the format leaves no room for interpretation.