Where is the ShimCache stored, and when is it written?

3 min read

TL;DR. ShimCache lives at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Windows rebuilds it in memory every session and flushes it to the SYSTEM hive only on clean shutdown — hard reboots can drop recent entries entirely. Don't forget to replay SYSTEM.LOG1 / SYSTEM.LOG2 for the most current picture.

A lot of ShimCache misadventure traces back to a single misunderstanding: investigators assume the cache is updated like a log file, with entries flushed to disk as they happen. It isn't. Here is exactly where the ShimCache lives and when Windows writes to it.

ShimCache: in-memory writes vs on-disk flush timing

The registry path

The ShimCache lives inside the SYSTEM hive, at:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

That last AppCompatCache is a value, not a subkey. Its data is a single binary blob whose schema varies by Windows version — XP, 7, 8, 8.1, 10 and 11 each use a slightly different layout. The binary format walkthrough covers the modern Windows 10/11 schema in detail.

You can read the same value offline by extracting the SYSTEM hive — it's one of the files under C:\Windows\System32\config\ — and pointing a parser at it. The Shimcache Parser does exactly that, in your browser, without uploading the file anywhere.

The "current" ControlSet trick

Windows actually maintains multiple ControlSets (ControlSet001, ControlSet002, sometimes more). At any moment, exactly one is the active control set, indicated by the HKLM\SYSTEM\Select\Current value. CurrentControlSet is a runtime alias for whichever one is active.

When parsing offline you should:

  1. read HKLM\SYSTEM\Select\Current (a DWORD, typically 1 or 2),
  2. walk the corresponding ControlSetXXX\Control\Session Manager\AppCompatCache\AppCompatCache value,
  3. fall back to scanning both ControlSet001 and ControlSet002 if Select\Current isn't readable.

Most parsers — including this tool — handle that automatically.

When the cache is written

Here's the part that surprises people: while the system is running, ShimCache lives in memory. Windows only flushes it to the SYSTEM hive at clean shutdown. So:

  • A hard reboot, power loss, BSOD, or hypervisor-level VM kill will drop any recent entries that hadn't been persisted yet.
  • A live triage of a running system using reg.exe or RegRipper sees the previously-persisted ShimCache, not the one currently being built in memory.
  • Memory forensics (e.g. Volatility's shimcachemem plugin) can recover the current in-memory cache before it would otherwise be lost.

That timing is why dead-box analysis of a hive often misses the most recent activity, and why investigators reach for AmCache (which writes continuously — see ShimCache vs AmCache) to fill the gap.

What about the registry transaction log?

The SYSTEM hive is accompanied by transaction-log files (SYSTEM.LOG1, SYSTEM.LOG2). They can hold unflushed writes that never made it into the main hive. Robust offline parsers replay those logs before reading the ShimCache; if you're rolling your own analysis, account for them or use a parser that does.

Quick checklist

  • ShimCache value: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache
  • Active ControlSet selected by HKLM\SYSTEM\Select\Current
  • Stored in memory, flushed only at clean shutdown — corroborate with AmCache for recent activity
  • Replay SYSTEM.LOG* transaction logs before parsing for the most current picture

Further reading

Related articles