How to acquire a Windows SYSTEM hive for offline ShimCache analysis

TL;DR. You cannot copy C:\Windows\System32\config\SYSTEM while Windows is running. The file is locked. Use FTK Imager, KAPE, reg save, a VSS snapshot, or Velociraptor on a live host. Read it directly off a mounted offline disk for dead-box work. When you copy the raw file, always grab SYSTEM.LOG1 and SYSTEM.LOG2 alongside it. Without them you are reading stale data. reg save does not need them.

The single most common acquisition mistake I see in incoming evidence is the analyst who copied SYSTEM and skipped the transaction logs. The second most common is the analyst who tried xcopy on a live host, got "The process cannot access the file because it is being used by another process," and went looking for an EDR-collected copy that was three days old. Neither needs to happen. Pick a method, use it correctly, and move on.

Why you cannot just copy it

The kernel holds the SYSTEM hive open with exclusive access whenever Windows is running. Plain copy returns the access-denied error. Even if you bypass the lock and read the bytes, the running OS keeps recent registry writes in memory until the next clean shutdown, which means the most useful ShimCache entries are not in the file you just grabbed. The storage and flush model is worth reading before you decide which method to use.

Your goal is one of:

Bypass the lock cleanly on the running host (raw NTFS, VSS, or forensic copy).
Read the file directly from a mounted offline disk image or paused VM.
Recover the in-memory copy from a RAM dump. The only way to get entries from the active session.

Method 1: dead box or mounted offline disk

The simplest path. Power down or mount read-only and copy:

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

All three files. A robust parser replays .LOG1 and .LOG2 before reading the main hive, so you do not miss writes that have not been merged yet. Skip them and you are reading a stale view.

Method 2: live system, forensic-grade copy

Several tools get around the lock, each in its own way: FTK Imager and KAPE read the file at the volume level, reg save goes through the registry API, and esentutl /vss or a VSS snapshot read from a shadow copy:

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 plus logs:
```
kape.exe --tsource C: --target RegistryHives --tdest C:\out
```
reg save. Built into Windows, needs an elevated prompt. It asks the kernel to write out the loaded hive, so the result is clean and consistent and needs no transaction logs. If you want the raw file instead, esentutl /y /vss copies it out of a temporary shadow copy (run it again for SYSTEM.LOG1 and SYSTEM.LOG2):
```
reg save HKLM\SYSTEM C:\out\SYSTEM.hiv /y
esentutl /y C:\Windows\System32\config\SYSTEM /vss /d C:\out\SYSTEM
```
Do not use robocopy /B on the live system. Backup mode bypasses file ACLs, not the kernel's exclusive lock on a loaded hive, so the copy fails with a sharing violation. Keep it for a mounted image or shadow copy, e.g. robocopy E:\Windows\System32\config C:\out SYSTEM SYSTEM.LOG1 SYSTEM.LOG2 /B with the image mounted as E:.
VSS snapshot. A point-in-time shadow copy you can read from. Useful when you need a consistent view and cannot bring the system down. vssadmin create shadow only works on Windows Server; on a client, esentutl /y ... /vss (above) creates and removes one for you, or create one in an elevated PowerShell with Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume='C:\'}.

All four methods produce a usable copy. FTK Imager and KAPE are what reviewers expect to see referenced in the methodology section of a report. reg save works in a pinch with nothing to install; note in your report that it writes out the hive's current contents rather than a byte-for-byte copy of the file, so deleted cells and slack space are not preserved.

Method 3: memory image

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

Capture memory with WinPmem, Magnet RAM Capture, or AVML. Then either extract the SYSTEM hive or pull ShimCache directly with Volatility 3:

# 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, including the Velociraptor live-collection path.

Method 4: live triage at scale

Velociraptor reads the locked hive via direct NTFS access and returns it for offline analysis. For fleet-wide collection, collect Windows.Triage.Targets with the RegistryHivesSystem target (older servers: Windows.KapeFiles.Targets with RegistryHives). It pulls the SYSTEM hive together with its transaction logs; download the collection ZIP and parse it offline.

For broader registry triage beyond ShimCache, see the registry parser.

Do not skip the transaction logs

Pending writes live in SYSTEM.LOG1 and SYSTEM.LOG2 until the next checkpoint. The delta can include the entries you care about most. Eric Zimmerman's AppCompatCacheParser replays the logs automatically, but only if they sit next to the hive. Mandiant's Shim Cache Parser and this tool do not replay anything: they read the primary hive file as-is. For those, replay the logs first with Eric Zimmerman's rla.exe (Registry Log Applier) or Registry Explorer, and parse the cleaned hive.

If you collected a hive months ago without the logs and need to know what is missing: the answer is "the most interesting bit." Re-acquire if possible.

Then parse it

Drop the SYSTEM hive into the Shimcache Parser. It takes that one file; if the hive is dirty, replay its .LOG1 and .LOG2 into it with rla.exe or Registry Explorer first. 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.