How to acquire a Windows SYSTEM hive for offline ShimCache analysis

4 min read

TL;DR. You can't just copy C:\Windows\System32\config\SYSTEM while Windows is running — the file is locked. Use FTK Imager, KAPE, robocopy /B, a VSS snapshot, or Velociraptor to get a forensic copy on a live host, or read the file directly off a mounted offline disk. Whatever method, grab SYSTEM.LOG1 and SYSTEM.LOG2 alongside — without them, recent writes are missing.

Why you can't just copy it

The Windows kernel holds the SYSTEM hive open with exclusive access whenever the OS is running. A plain copy or cp returns The process cannot access the file because it is being used by another process. Worse, even if you bypass the lock and read the bytes, the running OS keeps recent registry writes in memory until the next clean shutdown — including the most useful ShimCache entries.

So your goal is one of:

  1. Bypass the lock cleanly on the running host (raw NTFS / VSS / forensic copy).
  2. Read the file directly from a mounted offline disk image or paused VM.
  3. Recover the in-memory copy from a memory image (the only way to get entries that never made it to disk).

Method 1 — dead box / mounted offline disk

If you can power down the machine or mount its disk read-only, this is the simplest path:

<DriveLetter>:\Windows\System32\config\SYSTEM
<DriveLetter>:\Windows\System32\config\SYSTEM.LOG1
<DriveLetter>:\Windows\System32\config\SYSTEM.LOG2

Copy all three. The .LOG1 / .LOG2 files are transaction logs; a robust parser replays them before reading the main hive, so you don't miss writes that haven't been merged yet.

Method 2 — live system: forensic-grade copy

On a running host, several tools can read locked files at the volume level:

  • FTK Imager — GUI, free. "Obtain Protected Files" → "Custom" → select SYSTEM, SYSTEM.LOG1, SYSTEM.LOG2. Output to an external drive.
  • KAPE — command-line, scriptable. The RegistryHives target pulls all relevant hives + logs: 
    kape.exe --tsource C: --target RegistryHives --tdest C:\out
  • robocopy with /B — /B opens files in backup mode, bypassing the user-mode lock (still needs admin and SeBackupPrivilege). Quick-and-dirty option when no DFIR tooling is available: 
    robocopy C:\Windows\System32\config C:\out SYSTEM SYSTEM.LOG1 SYSTEM.LOG2 /B
  • VSS snapshot — vssadmin create shadow produces a point-in-time snapshot you can read from. Useful when you need a consistent view and can't bring the system down.

Method 3 — memory image (best for fresh entries)

The on-disk SYSTEM hive only contains entries persisted at the last clean shutdown. For a host that hasn't been cleanly rebooted since the incident, the most recent entries are in memory and nowhere else.

Capture a memory image (WinPmem, Magnet RAM Capture, AVML), then extract the SYSTEM hive — or extract ShimCache directly — with Volatility:

# Extract the registry hive
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.registry.hivedump --offset <addr>

# Or skip the hive and read ShimCache straight from memory
vol -f memory.raw windows.shimcachemem

Extracting the ShimCache from a memory dump covers this in depth.

Method 4 — live triage at scale (Velociraptor)

For fleet-wide collection, Velociraptor reads the locked hive via direct NTFS access and returns it for offline analysis. Use the Windows.Forensics.AppCompat or generic Windows.Registry.NTUser family of artifacts, or just collect the hive file with Generic.Forensic.LocalHashes plus the accessor: ntfs option.

Don't skip the transaction logs

This is the most common mistake: copying SYSTEM without SYSTEM.LOG1 and SYSTEM.LOG2. Pending writes live in the logs until the next checkpoint, and that delta can include the entries you care about most. Robust parsers (Eric Zimmerman's AppCompatCacheParser, ShimCacheParser, this tool) replay the logs before reading the hive — but only if you supply them.

Then parse it

Drop the SYSTEM hive into the Shimcache Parser — it runs entirely in your browser, no upload step, and handles every Windows version from XP through Windows 11. For the format details, see the Windows 10 / 11 binary format reference.

Further reading

Related articles