$MFT is an NTFS metadata file, and it does not sit at a fixed spot: the volume's boot sector records the cluster where it starts (the MFT cluster number), and its runlist in record 0 says where the rest of it lives. While the volume is mounted, Windows does not hand it out through the normal file APIs. xcopy will fail. Robocopy will fail. PowerShell's Copy-Item will fail too: the open is refused (access denied or file not found), so you get no copy at all, not a partial one. You need a tool that reads the raw volume, bypasses the filesystem, and assembles $MFT from its cluster runs.

There are three options I trust in practice. They cover the live-host triage cases I see week to week.

Option 1: KAPE, the default for IR

If you are doing incident response and you are on a Windows host, the answer is KAPE with the FileSystem compound target plus the $MFTMirr target. FileSystem pulls $MFT, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS and the $TxfLog stream $T in one pass; $MFTMirr is not part of it, hence the second target. KAPE preserves the original timestamps on the collected files and writes a tidy directory tree you can carry to analysis.

kape.exe --tsource C: --target 'FileSystem,$MFTMirr' --tdest C:\triage --vss

The single quotes are for PowerShell, where an unquoted $MFTMirr is expanded as an (empty) variable. From cmd.exe, drop them: --target FileSystem,$MFTMirr.

--vss is the flag people forget. It tells KAPE to also pull $MFT (and the rest of the target) from every Volume Shadow Copy on the source. Older snapshots are independently useful and you should collect them as a matter of course. See Volume Shadow Copy and $MFT for what to do with them.

KAPE handles the locked-file problem with its own raw NTFS reader, so it does not need RawCopy.exe or any other helper. The collected file is bit-identical to what a forensic image would yield. Use it unless you have a specific reason not to.

Option 2: FTK Imager, the GUI fallback

FTK Imager remains the standard free GUI tool for acquisition. It is what you reach for when KAPE is not on the host and you need to grab $MFT once and walk away. The workflow:

File → Add Evidence Item → Physical Drive (use Logical Drive only if you are working off a remote share or mounted image).
Pick the disk and let it enumerate volumes.
Expand the NTFS volume's root in the tree on the left. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap and the rest of the metadata files are visible there even though Explorer hides them.
Right-click $MFT → Export Files. Hash it (SHA-256) immediately.

FTK Imager reads the locked volume by mapping the physical device and parsing NTFS itself. The export is the actual on-disk file, fixup arrays and all.

The same workflow reads .dd, .E01, and .AFF4 images. If you have an offline image, mount it as evidence and use the same export path.

Option 3: fsutil and a raw read, when you cannot install anything

On a hardened host where you cannot drop KAPE or FTK Imager, the built-in fsutil command will tell you where $MFT lives:

fsutil file queryextents C:\$Mft

Output is a list of (Virtual Cluster Number, Logical Cluster Number, length) triples. To turn that into a file you read the raw volume at each LCN and assemble. Powershell with a P/Invoke into CreateFile(\\.\C:, GENERIC_READ) does the job; so does any of the small PowerShell raw-read modules on GitHub. RawCopy.exe from Joakim Schicht is the simplest standalone.

This is a building block, not a final answer. Use it when policy forbids loading other tooling.

What people get wrong

Expecting Copy-Item -Force to work. -Force changes nothing here: the normal file APIs still refuse to open $MFT. Use one of the raw-read options above, then check the result: its size against fsutil file queryextents, and its records as described under verification below.

Forgetting $MFTMirr and the transaction logs. $MFTMirr is sixteen records of insurance. The transaction logs ($LogFile, plus the per-resource $TxfLog files under $Extend\$RmMetadata) carry the operations that may not have hit $MFT yet at the moment of acquisition. Acquire them together. KAPE does this for free.

Not pulling the USN journal. $UsnJrnl:$J is essential for timeline reconstruction (see pairing the journal with the file table). It rotates, which means waiting two days to come back for it loses evidence. Grab it the first time. If you are working from a disk image, the steps for pulling $UsnJrnl:$J out of the same image mirror the $MFT export.

Collecting from a live system without VSS. The live MFT is consistent at the volume level (NTFS is journalled), but if the host is busy you may collect a $MFT and a $UsnJrnl that disagree by tens of seconds because the MFT was read first. Take a VSS snapshot, then read both from the snapshot. The snapshot freezes them.

Trusting the wrong timestamp on the collected file. The "modified" time on the exported $MFT is whatever your collection tool set. Hash the bytes, write the hash and the acquisition time to a separate log, and reference that log everywhere.

A VSS-based acquisition that I actually use

When I am on a live host and I want a clean point-in-time $MFT plus journal plus log, this is the snippet:

vssadmin create shadow /for=C:

Read the Shadow Copy Volume Name from the output (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN). Do not point robocopy or copy at it: $MFT, $LogFile and $UsnJrnl:$J are NTFS metadata files, and the normal file APIs do not hand them out from a shadow copy any more than from the live volume. The snapshot freezes the bytes; you still need a raw NTFS reader to get them out:

KAPE with --vss (Option 1) reads every snapshot with its own NTFS parser and collects the whole target set.
The raw read from Option 3 works against the snapshot too: open the shadow copy's device path instead of \\.\C: and assemble $MFT from the runlist in record 0.
Offline, image the disk and export with FTK Imager or icat, as in the next section, or with one of the free tools if you don't have FTK Imager to hand.

Hash everything once it lands, delete the snapshot if it is yours to delete (vssadmin delete shadows /shadow={GUID}), and walk away.

The raw-read route needs nothing beyond what ships in Windows.

Reading from a disk image

If you already have a .dd or .E01 image you skip the locking entirely. Mount the image read-only (xmount, ewfmount, vshadowmount for VSS-aware images) or use a parser that consumes images directly. $MFT always sits at LCN MftStartLcn from the boot sector at offset 0 of the partition. Sleuth Kit's icat -o <partition_offset> image.dd 0 extracts the file. Inode 0 is always $MFT.

Verification before analysis

Hash the file (SHA-256) immediately after acquisition. Hash it again before parsing. Mismatches happen more often than people admit, usually because of mid-acquisition disk pressure or copy tools that retry partial reads silently.

Then run a structural check. Parse the first ten records, confirm the FILE signature on each, confirm record 0 is $MFT itself with a self-referential $DATA runlist, confirm record 1 is $MFTMirr, confirm record 5 is the root directory with a $INDEX_ROOT attribute. If any of those fail, the acquisition is bad and you need to repeat it. MFTECmd and mft_dump will both throw warnings on a corrupted file; do not suppress them.

Extracting $MFT from a live Windows host without breaking it