pagefile.sys is a goldmine — and a trap. The same property that makes it
useful (it's a raw dump of paged-out memory) is the source of every limit on
what you can do with it.
No process attribution
A page in the pagefile cannot, on its own, be tied back to a process. The mapping from a page slot to a Process / VirtualAddress is held in page-table entries (PTEs) which live in RAM. Without a paired RAM acquisition, you can read content but you cannot say who owned it.
This is why Volatility documentation says pagefile.sys cannot be processed directly: Volatility needs the PTEs from a RAM image to know which slot of pagefile to read for a given virtual address.
No allocation reassembly
A single allocation that's larger than 4 KB (an executable section, a
document buffer, a SQLite table) was paged out as separate frames written to
whichever slots were free at the time. Two adjacent pages in pagefile.sys
almost certainly belong to different allocations.
Carving recovers per-page hits. It rarely reconstructs a complete file.
Windows 10+ memory compression
Starting with Windows 10, the Memory Manager added a CompressionStoreManager
that compresses cold pages in memory before any disk I/O. The
compression algorithm is Xpress-Huffman (CompressionFormat 4).
When such a page is finally flushed to disk, the bytes that land in
pagefile.sys are the compressed payload, not the original. A bare string
search will miss the content. Decompressing requires parsing the Huffman
code-length table at the start of each block — non-trivial in WebAssembly and
not yet implemented in this tool. The Blackhat 2019 paper "Paging All
Windows Geeks — Finding Evil In Windows 10 Compressed Memory" documents the
full algorithm.
This tool detects and flags likely Xpress-Huffman blocks (high entropy + plausible 256-byte code-length header) so analysts know what's hiding, but decompression is a future-work item.
Selective paging
Not everything paged out is in pagefile.sys. Windows has multiple paging
backends:
pagefile.sys— the default backing store for anonymous memory.swapfile.sys— UWP / Modern app working sets.hiberfil.sys— full RAM snapshot at hibernation.
If the data of interest never paged out (because RAM was sufficient) or
landed in swapfile.sys or hiberfil.sys, it won't appear here.
Volatile, fragile, partial
Even where data does land, it can be overwritten on the next page-out cycle.
What you see in a pagefile.sys capture is a snapshot of one moment in the
machine's life. Older artifacts may have been overwritten by newer ones; the
file is not append-only.
What it's still good for
Despite all of this, pagefile.sys reliably surfaces:
- Plaintext credentials that were in memory but never persisted intentionally.
- URLs and IPs an attacker's command-and-control accessed.
- Command lines of short-lived processes.
- Registry hive fragments that have since been deleted from the live hive.
- Document content an analyst couldn't otherwise recover.
For triage, that is often enough.