TL;DR. Each Windows generation rewrote the AppCompatCache structure. XP uses a 0xDEADBEEF magic and a fixed 552-byte record; Server 2003, Vista/2008, Windows 7/2008 R2, and Windows 8/8.1 each have their own header and entry layout. A parser must branch on the header magic — there is no single format.
Most ShimCache documentation covers the Windows 10/11 layout. But incident responders still meet Windows 7 domain controllers, Server 2008 R2 boxes, and the occasional XP appliance. The on-disk structure on those hosts is materially different. This is the per-version reference.
Why there is no single format
ShimCache is an internal Windows structure with no public spec. Microsoft re-shaped it across releases as the shim infrastructure evolved. The registry value name and path also moved. A robust parser identifies the version from the header before reading a single entry.
Per-version cheat sheet
| Windows | Registry value | Header magic | Entry shape |
|---|---|---|---|
| XP (32-bit) | …\AppCompatibility\AppCompatCache | 0xDEADBEEF | Fixed 552-byte records, max 96 |
| Server 2003 | …\AppCompatCache\AppCompatCache | 0xBADC0FFE | 24-byte (x86) / 32-byte (x64) entries |
| Vista / 2008 | …\AppCompatCache\AppCompatCache | 0xBADC0FFE | Like 2003, different flags |
| Windows 7 / 2008 R2 | …\AppCompatCache\AppCompatCache | 0xBADC0FEE | 32-byte header; entries carry the insertion flag |
| Windows 8 / 2012 | …\AppCompatCache\AppCompatCache | 0x00000080 | Variable-length 00ts entry signature |
| Windows 8.1 / 2012 R2 | …\AppCompatCache\AppCompatCache | 0x00000080 | 10ts entry signature |
(The Windows 10/11 10ts/00ts modern layout is detailed separately.)
XP — the outlier
Windows XP is unlike everything after it: a 0xDEADBEEF magic, fixed-width 552-byte records, a hard cap of 96 entries, and UTF-16 paths padded to a fixed length. It also stored a last-update timestamp and a file-size field that later versions dropped. If you see 0xDEADBEEF, you are in XP territory and none of the modern parsing logic applies.
Windows 7 — the one you'll meet most
Windows 7 / Server 2008 R2 is still common in IR. Magic 0xBADC0FEE, a 32-byte header, and per-entry records that include the path, the file's last-modified time, and — uniquely useful — an execution flag that was removed in Windows 8 and later. On Windows 7 a set flag is reasonable (not absolute) corroboration of execution; do not extrapolate that to newer systems, as explained in does ShimCache prove execution.
The 8 / 8.1 transition
Windows 8 introduced the variable-length entry with a per-entry signature (00ts), and 8.1 bumped it to 10ts. This is the structural ancestor of the Windows 10/11 format, so a parser that handles 8.1 is most of the way to handling 10.
Parsing them without a toolchain
The Shimcache Parser auto-detects the header magic and branches to the correct decoder for XP, 2003, Vista, 7, 8, 8.1, and 10/11 — so you can read a legacy SYSTEM hive in the browser without staging old tooling. For collection guidance on these older systems, see acquiring a SYSTEM hive.
Further reading
- Mandiant: leveraging the ShimCache — the original per-version reverse-engineering.
- Eric Zimmerman's AppCompatCacheParser — handles every version; a good ground truth.