Comparing ShimCache parsers: Mandiant, Zimmerman, Velociraptor, and this tool

TL;DR. Use Eric Zimmerman's AppCompatCacheParser for casework. Broadest OS coverage, CSV output, well-tested. Use Velociraptor for live triage at fleet scale. Use Mandiant's Shim Cache Parser when a simple Python reference helps. Use this tool when you want zero install and zero upload. Cross-validate disagreements. The format is finicky enough that two parsers occasionally see things differently.

There are four open tools that matter for ShimCache parsing. Each has a niche. The mistake I see junior analysts make is picking one and treating it as the answer for every case. The right answer depends on whether you are scaling, scripting, or staring at a single hive at 2am.

The four parsers that matter

Tool	Language	Distribution	Best for
Mandiant Shim Cache Parser	Python	Source on GitHub	Reading the format, scripting custom analysis
Eric Zimmerman AppCompatCacheParser	C# / .NET	Single binary	Casework. 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 de-facto standard for offline analysis. 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 expect you used.

AppCompatCacheParser.exe -f SYSTEM --csv .

Caveats: Windows-only binary, needs .NET Framework or Core, not designed for ad-hoc browser-based triage.

Velociraptor

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, which is 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 Shim Cache Parser

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

Exists for two cases the others do not cover well:

Zero-install triage. Open the page, drop a hive, see entries. Useful when you are on a host without DFIR tooling installed, or analyzing on a laptop or 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 or case where upload is not acceptable.

Trade-offs: no command-line interface, no automation hooks. Use it for human-driven triage, not pipelines. For pipelines, EZ's tool is the right answer.

Cross-validation when parsers disagree

The 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 does not 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 or placeholder entries. Some tools emit blank rows for unused slots; others skip them.

When it matters, run two parsers and diff. The combinations I 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

Do not forget transaction logs. SYSTEM.LOG1 and SYSTEM.LOG2 carry pending writes; without them you are reading a stale hive. EZ's tool replays them automatically. Some others do not. See acquiring a SYSTEM hive.
Do not compare on-disk and in-memory ShimCache directly. They are different sources of truth. On-disk has only the last clean-shutdown state. In-memory has the current session. Treat them as complementary.
Do not assume execution. No parser can fix this. The cache records examination, not execution.