pagefile.sys is one of the highest-yield files on a Windows host and one of the most annoying ones to capture. The kernel holds it open with an exclusive handle for the entire boot, so any path that goes through the Win32 file API returns the familiar ERROR_SHARING_VIOLATION. There are four practical ways around that. Pick the one that fits the state of the machine you have.

1. Live system, raw NTFS read

On a running host the bytes are still readable by anything that bypasses the file system and talks to the NTFS volume directly. The tools I reach for:

RawCopy.exe from jschicht/RawCopy. Small, no install, drops a stream copy without disturbing the source. From an elevated prompt:
```
RawCopy.exe /FileNamePath:C:\pagefile.sys /OutputPath:E:\evidence
```
FTK Imager Lite. Add Evidence Item → Logical Drive → C: → right-click pagefile.sys → Export Files. Uses raw I/O underneath.
KAPE with --target MemoryFiles, a single target that copies pagefile.sys, swapfile.sys, hiberfil.sys and minidumps in one triage sweep. It only looks at the root of C:, so a pagefile relocated to another volume needs a separate copy.
X-Ways Forensics through Add Logical/Physical Disk.

Do not write the output to C:. Every byte you write to the source volume is a potential pagefile-slot overwrite. Stage to an external drive or a network share.

Also check the configured pagefile paths before assuming C:\pagefile.sys is the only one. Read HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles from the registry. On servers with multiple drives I have seen pagefile redirected to a dedicated spindle that nobody acquired because the triage script hard-coded C:.

2. Offline system, mount the disk read-only

Power down (if your IR brief allows it), then boot from a forensic Linux USB (CAINE, Tsurugi, Paladin) or pull the disk through a write blocker. Once the volume is mounted read-only, the file is just bytes:

sudo mount -t ntfs-3g -o ro /dev/sdb2 /mnt/evidence
cp /mnt/evidence/pagefile.sys /external/evidence/

No kernel lock outside Windows. This is the cleanest path when you can afford the downtime.

3. From a disk image

Most engagements end up with a full image (E01, dd, AFF4) rather than direct hardware access. The usual tools:

FTK Imager: Add Evidence Item → Image File → ... → Export Files.
Autopsy or raw Sleuth Kit: open the image, navigate to the volume root, export.

tsk_recover / icat:

fls -p -o $OFFSET image.dd | grep pagefile.sys
# take the inode, then:
icat -o $OFFSET image.dd $INODE > pagefile.sys

Same applies to companion files (hiberfil.sys, swapfile.sys, MEMORY.DMP). Pull them in the same pass.

4. From a VM snapshot

VMware, Hyper-V, and VirtualBox snapshots include the guest disk. Mount the disk (*.vmdk, *.vhdx, *.vdi) read-only on the analysis host and copy. For Hyper-V differencing disks (.avhdx) you need to merge against the parent base, or mount the chain in PowerShell:

Mount-VHD -Path .\guest.vhdx -ReadOnly

If the hypervisor host is reachable and the VM was suspended (not powered off), the .vmem or .bin file alongside the snapshot is effectively a free RAM dump. Grab it. It pairs with the pagefile and gives Volatility everything it needs to walk PTEs.

Don't forget the companions

If you are at the disk, take the whole paging family:

File	Use
`swapfile.sys`	UWP / Modern app working sets, different content set
`hiberfil.sys`	Full RAM snapshot if the machine hibernated or used Fast Startup
`memory.dmp`	Kernel crash dump if `%SystemRoot%\Memory.dmp` exists
`*.hdmp`	Crash dumps, complete or kernel-only
Live RAM dump	If the host is still up (DumpIt, WinPMem, Magnet RAM Capture)

A paired RAM dump is the single biggest upgrade to pagefile analysis. It gives Volatility the page-table entries to map pagefile slots back to processes. See the limitations post for what is missing without it.

Verify before you walk away

Hash the file. sha256sum pagefile.sys on Linux, Get-FileHash on Windows. Re-hash on the analysis box.
Sanity-check the size. A fresh Windows install with 16 GB of RAM has a pagefile around 2.5 GB. "System managed" can grow past 16 GB on busy servers. A 4 KB file means pagefile was disabled.
Log the chain of custody. Who pulled it, when, from what host, to what storage, with what tool. Sloppy custody logs sink reports.

Common pitfalls

BitLocker. An encrypted system drive means you need the recovery key or the unlocked TPM state. Capture while the volume is unlocked whenever possible.
EDR. Some products quarantine RawCopy.exe or FTK Imager on contact. Allowlist your tool path before you start, or you will burn an acquisition window debugging an antivirus pop-up.
Fast Startup / hybrid sleep. A "clean shutdown" was probably a hibernate. Check HiberbootEnabled and the size of hiberfil.sys before claiming the host was cleanly powered off.
Writing to the same volume. Do not. Every write is a possible pagefile-slot overwrite.
Encrypted pagefile. If fsutil behavior query EncryptPagingFile returns 1, the bytes you capture are AES-encrypted with a key that died at shutdown. See encrypting pagefile.sys.

Then what

Once the file is captured, drop it into the parser for a first-pass IOC and string sweep in the browser, or jump into the matching Volatility workflow if you also have a RAM image. For the carving theory behind it, read how pagefile.sys forensics actually works.

How to acquire pagefile.sys