The Application Experience appraisal task: when the BCF gets written, and when it gets cleared

RecentFileCache.bcf does not write itself. There is a single scheduled task, Microsoft\Windows\Application Experience\ProgramDataUpdater, that drives the entire lifecycle of the file. Understand that task and you understand the artifact. Miss it and you will misread what an empty BCF or a stale BCF actually means.

This is a post about one scheduled task and the half-dozen things you need to know about it.

What the task does

ProgramDataUpdater is the Application Experience appraiser. On a Windows 7 SP1 host it runs the program-inventory pass: walks recently executed binaries, evaluates them for shim/compatibility purposes, updates the local appraisal datasets, and clears the working file.

The working file is RecentFileCache.bcf. Every time the task runs successfully, the file gets truncated back to its header. New executions accumulate in the BCF until the next pass. That cycle is the entire mechanism.

The task is defined in C:\Windows\System32\Tasks\Microsoft\Windows\Application Experience\ProgramDataUpdater. It is an XML file you can read directly. On a clean Win7 SP1 install the trigger looks like this in spirit (the exact phrasing varies):

A daily trigger, usually at a randomized off-hours time.
An additional trigger on user logon, with a randomized delay.
A maintenance window dependency, which means it can defer if the machine is busy.

The cadence in practice is roughly daily, but it is not exactly 24 hours. The task can skip if the machine was off, was on battery, was actively in use, or had an open maintenance window deferral. I have seen the task go four or five days between runs on a normal laptop that was only powered on intermittently.

What clears the file

Three things, in descending frequency:

The appraiser ran successfully. This is the normal path. The file is truncated to a header with zero entries. The file system metadata persists.
The file was manually deleted. Rare. Some "telemetry remover" scripts target this file. Some IR tooling did too, back when the artifact was less well known. If the file is gone but the appraiser is configured to run, expect the OS to recreate it on the next execution event.
A system reset or imaging operation. Wipes the file along with everything else.

What does not clear the file:

Reboots.
Windows updates (almost never).
Disabling Defender or any other security product.
A user clearing the recycle bin.
Disk cleanup.

If the BCF is empty and you cannot account for it via one of the three causes above, look harder. The most common explanation in a real investigation is the appraiser ran last night and you missed the window. That is a perfectly normal state.

What disables the task

Group Policy can disable Application Experience entirely:

Computer Configuration\Administrative Templates\Windows Components\Application Compatibility\Turn off Application Telemetry
Computer Configuration\Administrative Templates\Windows Components\Application Compatibility\Turn off Inventory Collector

Both flip the same underlying behavior. On a domain-joined host with strict privacy policy, expect the task to be disabled. The BCF will accumulate.

The task can also be disabled locally:

schtasks /Change /TN "\Microsoft\Windows\Application Experience\ProgramDataUpdater" /Disable
Direct edit of the task XML in C:\Windows\System32\Tasks\.
Set-ScheduledTask -Disable via PowerShell.

The registry side of the disabled state shows up under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\ and \Tree\Microsoft\Windows\Application Experience\ProgramDataUpdater. The Registry parser will give you both the Enabled value and the registered command line.

A disabled appraiser is loud in the right places, quiet in others. The task does not show up in the Defender alert stream. It does not generate a Security event. You have to go looking.

Detecting a disabled appraiser from EVTX

The relevant log is Microsoft-Windows-TaskScheduler%4Operational.evtx. The interesting event IDs:

106: task registered. Look for the user that registered it. On a default install, this is SYSTEM at machine setup time. A 106 for ProgramDataUpdater dated after the machine was built is a sign somebody re-registered the task, possibly after deleting and re-creating it with different parameters.
141: task deleted. A 141 for ProgramDataUpdater is interesting. It means the task was removed, which is more aggressive than disabling.
200: action started. The presence of 200 events tells you the task actually ran. Missing 200 events for weeks is a red flag.
201: action completed. Pair with 200 to confirm a clean run.
129: created task process. Confirms the task spawned its action.
325: task triggered. The most useful one for cadence analysis.

If the operational log has a healthy stream of 200/201 events for ProgramDataUpdater, the appraiser is running and clearing the BCF on schedule. If those events stop on a specific date and the BCF is correspondingly stale, something changed on that date. That is the pivot point for the investigation.

The EVTX parser handles this log type. The schema is dense but the filter is simple: Channel = "Microsoft-Windows-TaskScheduler/Operational" and TaskName = "\Microsoft\Windows\Application Experience\ProgramDataUpdater".

What the task touches that you can pivot on

When ProgramDataUpdater runs, it does more than just clear the BCF. It updates several registry keys and the Amcache.hve on Win8+ hosts (irrelevant for our Win7 scope). On Win7 specifically, the appraiser pass interacts with:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\ and its sub-keys.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Compatibility Assistant\.
C:\Windows\AppCompat\Programs\Install\ for installer-tracking entries.

The last-write timestamps of AppCompatFlags\Compatibility Assistant\Persisted on Win7 are a useful corroborating timestamp for "when the appraiser last ran." Compare that to the last-modified timestamp on RecentFileCache.bcf itself. They should be very close. A wide gap means the appraiser was interrupted or the file was modified out-of-band.

A specific failure mode worth knowing

I have seen one consistent issue with the appraiser on Win7 SP1: if the machine has been re-imaged from a sysprep'd master and the task scheduler stamps the task with a future trigger time, the appraiser can skip its first scheduled run. The BCF grows. The fix is benign: the next user logon triggers the task and the file clears. But in the meantime, you can find an unusually large BCF on a freshly-deployed image. Worth being aware of so you do not over-interpret a large file on a known-clean machine.

The other failure mode is more deliberate. An attacker with admin can disable the task, run their tools, then re-enable it. The next appraiser pass clears the BCF and erases the evidence. The window is short (one task cycle) but the technique works. Detection: look for a 141 (task deleted) or a state-change in the registry's TaskCache\Tree\...\Enabled value, then compare to the timestamps on RecentFileCache.bcf and the executions you are investigating. If the task was disabled-then-enabled around the time of the suspected activity, treat the BCF as compromised for that window.

Practical workflow

When you land on a Win7 host and the BCF matters:

Acquire the BCF. Now. Before the next appraisal pass.
Pull Microsoft-Windows-TaskScheduler%4Operational.evtx.
Pull the registry hives, specifically SOFTWARE and SYSTEM for the task state and AppCompatFlags.
Pull the USN journal so you can see FileWrite | Close and FileDelete | Close operations against RecentFileCache.bcf itself.
Compare the BCF's last-modified time to the most recent 200 event for ProgramDataUpdater. They should be within a few seconds of each other.

If those two timestamps diverge, somebody touched the file outside the appraiser. That is more interesting than anything inside the file.