TL;DR. Use Eric Zimmerman's AppCompatCacheParser for casework — broadest OS coverage, CSV output, well-tested. Use Velociraptor for live triage at scale. Use Mandiant's ShimCacheParser when a simple Python reference helps. Use this tool when you want zero install and zero upload — fast triage in the browser. Cross-validate disagreements; the format is finicky enough that two parsers occasionally see things differently.
The four parsers that matter
| Tool | Language | Distribution | Best for |
|---|---|---|---|
| Mandiant ShimCacheParser | Python | Source on GitHub | Reading the format, scripting custom analysis |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | Single binary | Case work — most reliable for production reports |
Velociraptor Windows.Registry.AppCompatCache | VQL | Velociraptor server | Live collection at fleet scale |
| Shimcache Parser (this tool) | Rust → WebAssembly | Browser only, no install | Quick triage without setup, no data leaves the machine |
When to reach for which
Eric Zimmerman's AppCompatCacheParser (the default for case work)
EZ's C# parser is the de-facto standard for offline analysis. It covers every Windows variant from XP through Windows 11, replays SYSTEM transaction logs automatically, and outputs CSV that drops cleanly into Timeline Explorer. If your output is going into a final report, this is what reviewers will expect you used.
AppCompatCacheParser.exe -f SYSTEM --csv .
Caveats: Windows-only binary; you need .NET Framework / Core installed; not great for ad-hoc browser-based triage.
Velociraptor Windows.Registry.AppCompatCache (collection at scale)
When you need to pull ShimCache from dozens or thousands of hosts, Velociraptor wins. The artifact reads the in-memory cache directly from running endpoints — the same view the OS would have flushed at shutdown, but without waiting for shutdown. See Extracting the ShimCache from a memory dump for the rationale.
Caveats: requires Velociraptor infrastructure. Overkill for one-off analysis.
Mandiant ShimCacheParser (the format reference)
The original Python proof-of-concept. Less polished than EZ's tool but useful when you want to read the code to understand exactly how the format is decoded, or to script custom analysis around it. The output is plain text; integrate it with other Python pipelines.
python ShimCacheParser.py -t -h /path/to/SYSTEM
Caveats: requires Python 2.x (or a compatibility fork); CSV / JSON output is less polished than EZ's.
This Shimcache Parser (no install, no upload)
This tool exists for two cases the others don't cover well:
- Zero-install triage: open the page, drop a hive, see entries. Useful when you're on a host without DFIR tooling installed, or analyzing on a laptop / loaner.
- Trust-sensitive analysis: the hive is parsed entirely in your browser via WebAssembly. The file never leaves the page, never hits a server, never appears in any log. That matters when the hive belongs to a client / case where upload isn't acceptable.
Trade-offs: no command-line interface, no CSV export (yet), no automation hooks. Use it for human-driven triage, not for pipelines. For pipelines, EZ's tool is the right answer.
Cross-validation: when two parsers disagree
The ShimCache binary format is unforgiving — the Windows 10/11 layout reference shows why a single offset miscount can cascade through the rest of the blob. In practice, parsers usually agree, but real-world hives sometimes ship slightly off-spec data, and parsers disagree on:
- Bitness detection on Win7 hives — the header doesn't unambiguously say "x86 vs x64", so parsers heuristically pick. A pair of tools producing different paths on the same hive is your tell.
- Path normalization — backslash escaping, drive letter case, leading
\??\markers. Different parsers normalize differently. - Empty / placeholder entries — some tools emit blank rows for unused slots; others skip them.
When it matters, run two parsers and diff. The combinations I'd reach for:
- EZ + this tool for fast cross-check
- EZ + Mandiant for a "Python vs C#" sanity check
- EZ + Velociraptor for "live in-memory vs on-disk hive" comparison
Common pitfalls
- Don't forget transaction logs.
SYSTEM.LOG1/SYSTEM.LOG2carry pending writes; without them you're reading a stale hive. EZ's tool replays them automatically; some others don't. See Acquiring a SYSTEM hive. - Don't compare on-disk and in-memory ShimCache directly. They're different sources of truth — on-disk has only the last clean-shutdown state, in-memory has the current session. Treat them as complementary, not redundant.
- Don't assume execution. No parser can fix this — the cache records examination, not execution.
Further reading
- Eric Zimmerman's AppCompatCacheParser — reference parser.
- Mandiant's ShimCacheParser — original Python implementation.
- Velociraptor
Windows.Registry.AppCompatCache— VQL artifact. - Windows 10/11 AppCompatCache deep dive (Ø Security) — explains why parsers occasionally disagree.