Volatility + pagefile.sys: pairing the two for full memory forensics

Volatility and its sibling MemProcFS are the canonical tools for Windows memory forensics. Most analysts run them against a RAM dump alone and stop there. The piece that keeps getting missed: both will read pagefile.sys if you give it to them, and doing so changes what you can recover by an order of magnitude. Anything that paged out before the RAM capture comes back into reach.

This post is the workflow I run when I have both files in hand.

Why Volatility refuses pagefile alone

Volatility's job is to walk kernel data structures from a captured memory image: EPROCESS lists, page-table entries, kernel pools, network buffers. All of that lives in RAM. None of it is in pagefile.

Pagefile in isolation is content with no attribution. 4 KB raw frames. No process tag, no virtual address, no allocation type. Volatility cannot pick a slot for a given virtual address without the PTE that points at it, and the PTE is in RAM.

This is why standalone pagefile tools, including this one, fall back to carving. Content only. See the limitations post.

What changes when you give Volatility both

With the RAM dump and the matching pagefile, Volatility can:

1. Walk PTEs in the RAM image and resolve which process and virtual address each pagefile slot maps to.
2. Read paged-out pages on demand during plugin execution. A pslist, cmdline, vadinfo, dumpfiles gets the full content even for regions that paged out.
3. Run plugins that were previously failing or partial: pstree, cmdline, dlllist, handles, consoles, cmdscan come back complete.

Effectively the pagefile is mounted as a backing store for the memory image. Plugins that used to return zeroes for paged ranges now return the real bytes.

Volatility 3 syntax

# Without pagefile (paged-out content is missing)
vol -f memory.dmp windows.pslist

# With pagefile (paged-out content gets fetched)
vol -f memory.dmp \
    --layer "Stacker.layer0:PageFile=pagefile.sys" \
    windows.pslist

The --layer syntax stacks a PagefileLayer over the physical memory layer. Volatility's address translation falls through to it when a PTE has the pagefile bit set. The exact stacking CLI has changed across minor versions, so verify with vol --help and the -h for windows.info on your build before scripting against it.

Volatility 2 syntax

Legacy but still in production at plenty of shops:

vol.py -f memory.dmp --profile=Win10x64_19041 \
    --pagefile pagefile.sys \
    pslist

--pagefile works for most Win64 / Win10 profiles. For older profiles the flag may not be wired through.

MemProcFS syntax

MemProcFS mounts the analysis surface as a virtual filesystem you can cd into:

MemProcFS.exe -device memory.dmp -pagefile0 pagefile.sys

-pagefile0 accepts a single path. -pagefile1, -pagefile2, and so on are for additional pagefiles, which is the case on multi-volume servers with several PagingFiles entries in the registry.

Once mounted:

M:\pid\1234\virt2phys.txt
M:\pid\1234\memory.vmem
M:\pid\1234\modules\...

These paths read with paged-in content filled from the pagefile transparently. I find MemProcFS easier than Volatility for interactive triage because you can grep, ls, and pipe through familiar tools.

When to use which tool

A full IR triage usually involves all of them. RAM capture for live state, pagefile for paged-out content, a strings sweep for quick IOCs.

Practical workflow

What I run end to end on a Windows host where this matters:

1. Acquire RAM. DumpIt, WinPMem, Magnet RAM Capture, whichever the host tolerates. Always first.
2. Acquire pagefile. See how to acquire pagefile.sys.
3. Acquire hiberfil.sys if it exists. See the comparison post.
4. Power down, image the disk. Pull AmCache, Shimcache, Prefetch, the USN journal, EVTX channels, the registry hives, LNK files, jump lists, SRUM, the recycle bin, browser history, MFT, RecentFileCache.
5. First pass: drop the pagefile into this parser for a quick IOC sweep. URLs, IPs, command lines, credentials. Fastest path to "is there anything obviously bad here?".
6. Second pass: run MemProcFS with RAM + pagefile. Walk processes, dump LSASS, check network connections, examine drivers.
7. Third pass: Volatility 3 plugins for anything MemProcFS doesn't cover. Custom plugins, malware-family-specific extractors, windows.malfind for injected code.
8. Cross-reference carved findings against EDR and Sysmon for time anchoring. A pagefile-only finding usually wants an EVTX 1 (Sysmon process create) or 4688 to nail down "when".

What if you only have the pagefile

Common when the live capture was not possible: host locked, BitLocker without recovery key, attacker shut down, host already rebooted.

• Volatility and MemProcFS are largely useless without a corresponding RAM image.
• This parser, bulk_extractor, page_brute, photorec. Carving plus strings plus regex sweeps will produce the strongest signal achievable from pagefile alone.
• Quality is content-only, not context. See the limitations post.

What if you only have the RAM dump

Common in cloud or VM forensics where pagefile lives on a hypervisor volume you cannot reach.

• Volatility and MemProcFS work, but any paged-out address returns zero.
• Some plugins partially fail. Others (anything that only touches non-paged kernel pools) are unaffected.
• The pagefile is the supplement that turns a partial memory image into a complete one. Get it if you can.

Crash dumps as a hybrid

MEMORY.DMP from a kernel crash is structurally similar to a RAM dump and Volatility reads it natively. It does not include pagefile content. Pair it with pagefile.sys the same way you would a live capture.

Further reading

• Volatility Foundation, Volatility 3 documentation for the canonical layer-stacking and plugin reference.
• Ulf Frisk, MemProcFS documentation for the filesystem-style memory analysis approach.
• Andrew Case et al., The Art of Memory Forensics, for the foundational background on PTEs and address translation that the paired workflow depends on.