C:\pagefile.sys is the place Windows dumps the memory it does not have room for in RAM. The Memory Manager picks anonymous pages that have gone cold, writes them out in 4 KB frames, and reclaims the physical frames for something hotter. When code touches the address later, the page faults back in.
The file is marked hidden and system, sits at the root of the boot volume by default, and is held with an exclusive kernel handle for the entire boot. That last detail is the one that matters in DFIR: you cannot copy C:\pagefile.sys from a live shell and you cannot read it through normal Win32 APIs. Acquisition runs through raw NTFS, a forensic image, or an offline mount.
What actually lives in it
There is no header. No table of contents. No per-page metadata. No order. The Memory Manager dropped each evicted frame into whichever pagefile slot happened to be free, so two consecutive frames on disk almost always belong to different processes and frequently to different kinds of allocations.
Things I have routinely pulled out of a pagefile carve:
- PE fragments: image sections that paged out from
services.exe,lsass.exe, an unsigned dropper, JIT code from a CLR worker. - Registry hive bins (
hbin) paged out of the SAM, SECURITY, SOFTWARE, NTUSER.DAT working sets. The registry parser workflow picks up from here once you have carved enough bytes. - MFT records,
$LogFilepages, file-system cache lines. - SQLite pages from browser history databases, mail clients, Teams, Slack.
- Document content the user was editing: JSON, XML, plain text, image headers.
- Plaintext secrets the kernel had no way to recognise as sensitive:
Authorization: Bearerheaders, JWTs, decrypted DPAPI blobs,Password=connection strings, command-line arguments topsexec.
Why I open it
The pagefile is one of a small number of disk artifacts that preserve data which was only ever supposed to live in RAM. If a live RAM acquisition was not possible because the host was already off, locked, BitLocker-sealed, or simply rebooted before I arrived, pagefile.sys is the closest substitute. It is partial, it has no process attribution, and it is overwritten constantly while the machine runs, but it is the next thing I reach for.
Why parsing is awkward
There is nothing to parse in the usual sense. You cannot walk the file the way you walk an EVTX channel or an MFT. The standard move is carving: scan page by page, identify each 4 KB frame by its content (magic bytes, statistical profile, string density), and pull whatever survives. Tools like bulk_extractor, page_brute, photorec, and scalpel have done this for a decade. This site does the same thing in the browser, page by page, without uploading the bytes.
Further reading
- pagefile.sys vs hiberfil.sys vs swapfile.sys for the difference between the three paging-related files at the root of a Windows volume.
- How to acquire pagefile.sys for the capture mechanics.
- Limitations of pagefile.sys analysis for the honest version of what carving can and cannot recover.