What is RecentFileCache.bcf?

RecentFileCache.bcf is the artifact you forget exists until a Windows 7 box lands on your bench. It is small, narrow, and short-lived. It records the full paths of executables the Application Experience scanner has seen since the last appraisal pass. No timestamps per entry. No hashes. No signers. Just a list of paths in UTF-16LE.

And that list, on the right host, is one of the cleanest "this ran recently" signals you can pull off the disk.

Where it lives

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

Same directory as Amcache.hve on later builds. The two artifacts almost never coexist as primary evidence. Win7 and Server 2008 R2 give you the BCF and a thin Amcache. Windows 8 onward kills the BCF and leans entirely on Amcache.hve. If you find a BCF on a Win10 host, somebody made an unusual choice and you should figure out who.

What it actually contains

A 20-byte header, then a tight run of length-prefixed UTF-16LE path strings until EOF.

That is it. No timestamps. No hashes. No PE metadata. The format has not changed since Windows 7 SP1, which means parsing is forgiving and tools agree.

If you want richer telemetry for the same era, you need Amcache.hve, Prefetch, or Shimcache. The BCF is the cheap lead, not the verdict.

Who writes to it

The Application Experience service (AeLookupSvc on Win7) feeds the file at runtime. The scheduled task Microsoft\Windows\Application Experience\ProgramDataUpdater drains it on a roughly daily cadence and promotes survivors into Amcache.hve. The lifecycle has consequences for triage, covered in Application Experience and ProgramDataUpdater.

The short version: a path lands in the file after the executable crossed the AppCompat code path. The next ProgramDataUpdater run rewrites the file, often shorter than it was. If the appraiser is disabled, the file accumulates indefinitely and you get a longer window. I have seen 18-month-stale BCFs on hosts where somebody disabled the task with a telemetry-remover script.

Path semantics

A typical entry looks like:

\??\C:\Users\bob\AppData\Local\Temp\setup.exe

The \??\ prefix is the NT object manager's notation for a DOS-style path. Treat it as C:\ and move on. Decent parsers strip it for you; treat the rest like any other Win32 path.

Why it still matters in 2026

Two reasons, neither of which has gone away.

First, Windows 7 has not died. Industrial control, kiosk fleets, medical device endpoints, ATMs, embedded MES boxes. There are still millions of Win7 and Server 2008 R2 systems in the field. When one gets compromised, you are parsing BCF files in 2026 exactly the way you were in 2014.

Second, old images keep landing on benches. Cold-case re-investigations, M&A due diligence, civil discovery. A Win7 disk image from 2017 is just as relevant the week it shows up in your queue.

Limits worth being honest about

• No per-entry timestamps. The file's own LastWriteTime is a coarse upper bound on when the last entry landed and tells you nothing about earlier ones.
• The file is rewritten, not appended. Entries disappear between runs.
• Only executables that crossed the loader's AppCompat path. In-memory PE loaders, reflective DLLs, certain LOLBin tradecraft never touch this file.
• No metadata about the executable. A path is an identity claim, not an identity. Pair with Amcache.hve or a hash off disk if the binary is still there.
• No user attribution. Per-machine, not per-user. The "who ran this" question needs separate evidence from EVTX or Registry.

Parsing it

The parser on this site takes a .bcf and emits a structured list of paths. Everything runs in your browser. The file is never uploaded, which matters when the file in question is from a regulated client whose lawyers care about chain of custody.

For the format details and a worked hex dump, read the next post in the series.

Further reading

• The .bcf format, byte-by-byte
• Application Experience and ProgramDataUpdater
• RecentFileCache vs Amcache vs Prefetch vs ShimCache