The Depths of Windows Memory (Part 2) — The Life of a Physical Page: Five Lists and the Truth About the Page File

In the previous article, “The Depths of Windows Memory (Part 1) — The Moment a Virtual Address Becomes Physical RAM”, we followed as far as the page-fault handler assigning a physical page at the moment a committed page is first touched. So where does that physical page go after it is removed from the Working Set?

You often see the explanation boiled down to “it is evicted to the page file”, but in reality there are several states before and after that. An unmodified page can move to Standby with its contents left in place. A modified page first waits for write-back on Modified. At reuse it may pass through Free or Zeroed, and if the same contents are needed again, it can return from Standby with a soft fault.

This article uses the PFN database as the axis and follows how a single physical page moves through Active, Modified, Standby, Free, and Zeroed. The reading of the numbers themselves takes the introductory article “What Does Windows’ “Memory Usage” Actually Mean?” as a given.

“The Depths of Windows Memory” — All 3 Parts

1. Part 1: Virtual Addresses and Page Faults
   We follow when a committed virtual page obtains physical RAM.
2. Part 2 (this article): The Life of a Physical Page
   We follow the state transitions of a page that leaves the Working Set, and the role of the page file.
3. Part 3: Section Objects and Copy-on-Write
   We follow the mechanism by which DLLs, file mappings, and shared memory share physical pages.

The question Part 2 answers is just one.

Does a physical page that leaves the Working Set disappear, go to disk, or remain in RAM?

Intended readers are developers and operators who want to understand, from the mechanism up, why Available is high while Standby is also high, behavior after Working Set trimming, page-file configuration, and memory compression. Prerequisites are Windows 10/11 or current Windows Server, and required background is the basics of Working Set, Commit, and soft/hard faults. The difficulty is intermediate; we use internal terms such as PFN and page lists, but we focus on what you can observe with RAMMap and PerfMon without a kernel debugger.

1. The Bottom Line First

To start, here are the points that are easy to misread.

• A page that leaves the Working Set does not necessarily disappear immediately.
  A clean page remains on Standby and can return without reading disk if the same contents are needed.
• A modified page cannot be reused immediately.
  Private contents are made reusable after they can be written back to the page file; a mapped file, after they can be written back to the corresponding file; and so on.
• Available includes Standby.
  Standby is a cache that still holds contents and, at the same time, a reuse candidate that can be taken immediately if needed.¹
• Writing to the page file is not a batch job that starts only after RAM is completely exhausted.
  It proceeds in the background according to the Modified list and memory pressure.²³
• The page file is not merely “slow RAM”.
  It widens the Commit Limit, becomes the backing store for modified private pages, and supports crash dumps.⁴
• Disabling the page file does not fix a memory leak.
  The Commit Limit drops, and you can lose options for using RAM effectively and the ability to capture dumps.

In one sentence: before Windows discards a page, it checks the possibility that it will be needed again and whether there is a place from which the original contents can be restored.

2. The PFN Database — the Ledger on the Physical-RAM Side

The PTE we saw in Part 1 represented the translation from a virtual page to a physical page. The ledger that looks at this from the physical-page side and follows “what is this RAM page being used for right now” is the PFN database. PFN stands for Page Frame Number: physical RAM numbered in page units.

A PFN entry conceptually tracks the following information.

• The current state of the physical page
• Reference count and share count
• The corresponding PTE
• Whether it is modified
• Which page list it belongs to
• Information related to NUMA node and priority

In WinDbg, !pfn displays information for a specific PFN, and !memusage displays physical-memory usage and totals for each page list.⁵⁶ If you want to observe the same world without a kernel debugger, Sysinternals RAMMap is available. Use Counts shows purpose and page list, Priority Summary shows Standby by priority, and Physical Pages shows per-page usage.⁷

3. Connecting the Five States on One Picture

This article treats the flow of a physical page as the following five states, simplified. Strictly speaking, current Windows has states and lists not drawn here — Standby by priority, Transition, Bad, and others — and Active refers less to a single “Active list” than to the state of being referenced from a Working Set or similar through a valid PTE. Even so, this picture is more than useful for reading an app’s memory behavior.

Figure 1: A page referenced in the Working Set moves to Standby if clean and to Modified if dirty. The same contents can return; another use either reuses the page directly or goes through Free/Zeroed in preparation for an allocation that requires zeros.

The most important point in this figure is that leaving the Working Set and losing the contents are not the same thing. Also, when a Standby page is taken for another purpose, it does not necessarily pass through Free/Zeroed in order. If it will be handed to user mode as a new demand-zero private page, the old contents must be erased; if the whole page will be overwritten, as when it is the destination of a file read, the Standby identity can be dropped and the page reused directly.

4. Active / Valid — a Physical Page You Can Reference Now

An Active/Valid page is referenced from a process’s Working Set or from system space through a valid PTE. The CPU can reach it with ordinary address translation, so the access itself does not need a page fault.

There is no guarantee, however, that the page will remain Active. To maintain available memory, the memory manager looks at Working Set size, how recently the page has been used, and similar factors, and trims candidate pages. Microsoft’s Working Set documentation also explains that the memory manager removes pages from the Working Set in order to create available memory.⁸

4.1. A Trim Is Not a Free

What Working Set trimming mainly changes is the resident state of being immediately referenceable through a valid PTE. Distinguish the following four as separate events.

• Removing from the Working Set
• Releasing Commit
• Releasing a virtual address range
• Losing the original data

Running EmptyWorkingSet or a tool’s “Trim Working Set” is not a substitute for VirtualFree or a heap free. If you touch the same page again, it comes back via a soft fault from Standby or a hard fault from a backing store. So “I made the Working Set smaller” does not mean “I fixed the leak”.

5. A Clean Page Goes to Standby

Even after a page is removed from the Working Set, if its contents still match the original file or it already has a safe backing store, it can be placed on Standby. Representative examples include the following.

• Unmodified EXE/DLL code
• An unmodified memory-mapped file
• A private page that has already been written back
• Data remaining in the file cache

A Standby page keeps its correspondence to the previous contents. When the same process or another process needs those contents, if the page has not yet been reused, a soft fault that reconnects the PTE is enough to restore it.

On the other hand, if another allocation needs a physical page, the old Standby identity can be discarded and the page reused. If the reuse destination is a user-mode private page that requires zero initialization, a Zeroed page is prepared; if the whole page will be overwritten with file contents or the like, it can be reassigned directly without zeroing.

This two-sidedness is exactly why Standby is both a cache and Available.

5.1. Why Available Includes Standby

MEMORYSTATUSEX.ullAvailPhys represents physical memory that can be reused immediately without writing to disk, and it is the sum of Standby, Free, and Zeroed.¹

flowchart LR
    accTitle: The three page lists that make up Available
    accDescr: Available physical memory is the sum of Standby, Free, and Zeroed; Active pages referenced in a Working Set are not included
    standby["Standby (reuse candidate that keeps its contents)"] --> avail["Available (available physical memory)"]
    free["Free (unused, not zeroed)"] --> avail
    zeroed["Zeroed (unused and zeroed)"] --> avail
    active["Active (referenced in the Working Set)"] -.->|Not included| avail

Figure 2: Available is the sum of Standby, Free, and Zeroed. Standby, which still holds its contents, is also counted as “available”.

So it is not a contradiction when Task Manager shows “Free is low, yet Cached/Standby is high and Available is sufficient”. Windows does not leave free RAM idle; it leaves recently used files and code on Standby so they can be reused quickly as a cache if needed, and takes them if another purpose needs them.

Do not conclude “Free is low, so we are immediately short of memory”; look at Available, Commit, hard faults, and processing delay together.

6. A Dirty Page Waits on Modified

When an app writes to a page, those contents no longer match the original backing store. Overwriting that dirty page for another purpose would lose the data. So a modified page removed from the Working Set waits for write-back on Modified.

The write-back destination depends on the kind of page.

Microsoft’s page-file documentation also explains that .dll, .exe, and ordinary files that already exist on disk do not need to be written again to the page file, and that modified data with no original disk copy is what becomes a candidate for the page file.²

6.1. The Modified Page Writer

The Modified Page Writer is a system worker that scans dirty pages backed by the page file that the memory manager tracks, and writes them out to the page file.³ On the mapped-file side there are paths such as the Mapped Page Writer, which cooperate with the file system and the cache manager to write back to the corresponding file.

The important point here is that write-out is not a “do nothing until RAM is 0 bytes” scheme. Windows prepares pages that can be reused in the future in the background, according to the Modified list, Available, the state of the page file, and similar factors. When write-back finishes and there are no other valid references, the page proceeds to Standby with its contents intact.

flowchart TB
    accTitle: Write-back paths for a modified page
    accDescr: A modified page that leaves the Working Set waits on the Modified list; for a private page, if a page file is configured, the Modified Page Writer writes it to the page file, and a mapped-file page is written back to the corresponding data file by the Mapped Page Writer or similar, then proceeds to Standby with its contents intact
    dirty["Modified page that left the Working Set"] --> modified["Wait for write-back on the Modified list"]
    modified -->|"Private page (when a page file is configured)"| mpw["Modified Page Writer writes to the page file"]
    modified -->|Mapped-file page| mapped["Mapped Page Writer or similar writes back to the corresponding file"]
    mpw --> standby["After write-back, to Standby with contents intact"]
    mapped --> standby

Figure 3: The write-back destination is determined by the kind of page, and both paths proceed in the background. On a system with the page file disabled, the private-page side has no write-back destination, so modified private pages remain in RAM.

6.2. Separating Page Output from Page-File-Specific I/O

The following counters are easy to confuse, so confirm what they mean.

• Memory\\Page Writes/sec: the number of paging write I/Os issued to free physical memory
• Memory\\Pages Output/sec: the number of pages written to disk by those writes
• Memory\\Page Reads/sec: the number of disk-read I/Os issued to resolve hard faults
• Memory\\Pages Input/sec: the number of pages that entered RAM from those reads

Note that Page Writes/sec and Pages Output/sec are not counters that identify the page file alone. They can also rise on the path that writes back file-backed dirty pages, such as mapped files. Conversely, the input side also does not distinguish the page file, DLLs, EXEs, and memory-mapped files.² If you want to identify I/O specific to pagefile.sys, do not estimate from these four counters alone; record File I/O and Disk I/O with ETW/WPA and confirm the target file by matching FileObject and FileName.⁹

One more point: writing to the page file first does not mean immediately reading back from disk. If the page is not accessed, the written-back page can be removed from RAM and physical memory given to pages that are used more often.

7. The Difference Among Standby, Free, and Zeroed

7.1. Standby

A state that still holds the correspondence to the previous contents.

• If the same contents are needed, it can return via a soft fault
• If another purpose needs it, the old identity can be discarded and it can be reused
• There are Standby lists by priority

7.2. Free

The valid correspondence to the previous contents has been lost, and the page is allocatable. However, the old bit pattern may still remain in the page. Handing it to user mode as-is risks leaking information from the previous process.

7.3. Zeroed

The contents are zero, and the page can safely be handed out as a new user-mode page. The demand-zero fault in Part 1 was a representative case of obtaining an available Zeroed page and binding it to a PTE. Preparation from Free to Zeroed is done according to demand and system state.

So even though “Free” and “Zeroed” both look unused, they differ in their security-related readiness.

8. The Memory Compression Store — Creating One More Destination Inside RAM

From Windows 10 onward, when there is memory pressure the memory manager can, in some cases, compress infrequently used pages in RAM instead of writing them to disk immediately. That collection of compressed pages is the compression store.

In the early Windows 10 implementation the compression store was accounted inside the System process’s Working Set, but on current Windows it appears in debugger process lists as a dedicated Memory Compression process. So when you investigate the current compression amount, do not follow only the System process’s Working Set. The purpose itself — keeping more apps in physical memory and reducing disk I/O — has not changed.¹⁰¹¹

Keep the following points in mind, though.

• Compressed pages still use RAM
• Compression and decompression have a CPU cost
• Compression does not erase the Commit promise
• There is not a fixed order of “always compress, then the page file”
• The policy changes with the kind of page, pressure, and access history

Task Manager’s “In use (Compressed)” does not mean that compression completely emptied physical memory. The compression store is not a feature that makes the page file unnecessary; it adds one option that uses CPU to reduce I/O between RAM and storage.

9. The Real Role of the Page File

The page file has at least three roles.

flowchart LR
    accTitle: Three roles of the page file
    accDescr: The page file widens the Commit Limit, becomes the backing store for infrequently accessed modified private pages, and becomes the receptacle for a system crash dump
    pagefile["Page file"] --> limit["Widen the Commit Limit (headroom on the ceiling side)"]
    pagefile --> backing["Backing store for modified private pages"]
    pagefile --> dump["Receptacle for a system crash dump"]

Figure 4: The page file’s role is not only “slow RAM”. Even when usage is 0 it still supports the ceiling and dumps.

9.1. Widening the Commit Limit

The system’s Commit Limit is determined roughly by RAM plus the total of all page files. Without a page file, the Commit Limit drops to a level a little smaller than installed RAM. When Commit Total reaches the ceiling, new Commit fails and can lead to abnormal app termination or system trouble.⁴

This is a different matter from “how many GB are currently written to pagefile.sys”. The page file is also headroom on the ceiling side that supports the Commit promise.

9.2. Backing Modified Private Pages

If infrequently accessed modified private pages are backed by the page file, those physical pages can be removed from RAM and given to frequently used code and data.⁴ Disabling the page file reduces the option of removing such pages from RAM. You cannot simply say “it is fast because paging out does not happen”.

9.3. Supporting System Crash Dumps

To produce Memory.dmp at a system crash, you need a page file or a dedicated dump file that can support the dump method you chose.² Complete memory dump, kernel memory dump, and automatic memory dump differ in the amount required.

In an environment where you investigate crashes, deleting the page file only to save space can mean that evidence is missing when you need it most. For collection methods, see also “An Introduction to Collecting Windows Crash Dumps”.

10. The Right Size Is Not Uniform

You should not decide page-file size from a fixed formula such as “1.5 times RAM” alone. Microsoft explains that the appropriate size differs per system on the following two points and cannot be generalized.²

1. Peak System Commit Charge
2. The system crash dump you need

In practice, think in the following order.

10.1. Start from System-Managed as the Baseline

The Windows default is system-managed. It grows and shrinks according to installed RAM, Commit demand, crash-dump requirements, and the like. Unless you have a special constraint or measurement result, starting here is the safe choice.

10.2. Measure Peak Commit Under a Representative Load

Collect the following counters in PerfMon over a long period.

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

Include actual peaks in the collection period — month-end processing, backups, builds, several users at once, and so on.

A high page-file usage percentage alone does not prove a storage-performance problem. Sticking to the ceiling, however, is a warning of insufficient capacity. Look together at whether Commit is approaching the ceiling, whether a large amount of Modified is waiting, and whether the disk is saturated.²

10.3. Decide the Dump Requirement First

Decide whether you need a complete memory dump, whether a kernel memory dump is enough, or whether you will use a dedicated dump file. If you change to a fixed size, it must satisfy not only peak Commit but also the dump requirement.

11. See It for Yourself

11.1. Looking at Page Lists in RAMMap

Start RAMMap as administrator and open Use Counts first.⁷ The items to look at are the following.

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summary lets you confirm that Standby is split by priority. Processes shows each process’s Working Set; File Summary and File Details let you follow file data that is in RAM.

As a trial, read a fairly large local file once, end the read, and then Refresh. That file’s pages may remain in File Summary or on the Standby side. Reading the same file again can restore pages that have not been reused with no disk I/O, or with little I/O. Results vary with memory pressure, antivirus, and file size, so look at the direction of the state transition rather than a single set of numbers.

Note that RAMMap’s Empty menu changes system state artificially. Do not clear Standby as a production performance improvement; use it only on an isolated test environment.

11.2. Separating Commit and Touch with Testlimit

Testlimit is a Sysinternals tool that simulates resource shortages of memory, handles, processes, threads, and the like. First run the following against the binary you have on hand and confirm the version and usage that are displayed.

.\\testlimit64.exe -?

The following targets Testlimit v5.24. In the official v5.24 syntax, -m [MB] allocates the specified amount of memory, -d [MB] allocates and Touches, -e [seconds] is the allocation interval, and -c [count] is the allocation count. Specify -c last. If what you see locally differs, prefer that usage.¹²

Next, try it small on a disposable VM.

# -m 64: allocate 64 MiB, -e 1: 1-second interval, -c 8: stop after 8 times
.\\testlimit64.exe -m 64 -e 1 -c 8

# The same count and interval, with -d so that each region is Touched
.\\testlimit64.exe -d 64 -e 1 -c 8

While it runs, record the following at the same time.

• Task Manager’s “Committed X/Y”
• RAMMap’s Active, Modified, and Standby
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

If you actually reproduce Commit exhaustion, do not do it on the host PC; increase the count step by step on a VM with a snapshot. A run that automatically allocates up to the ceiling can freeze the screen, terminate processes abnormally, and lose logs. The purpose is not to destabilize the OS; it is to observe that as you approach the Commit Limit, new Commit fails.

12. Four Misreadings to Avoid in Practice

12.1. “Standby is high, so it is a memory leak”

Standby is a reusable cache and is included in Available. Judge a leak by whether the process-private Commit baseline and the allocation breakdown keep growing even after the load ends.

12.2. “Cutting the Working Set will fix the leak”

A trim only changes residency; it does not release Commit or a virtual allocation. On re-access the page faults back in.

12.3. “Page-file usage is 0, so it is unnecessary”

The page file supports not only the current write amount but also the Commit Limit and crash dumps. Deciding to delete it from everyday usage alone loses peak headroom and evidence at failure time.

12.4. “Memory compression first, then always the page file”

Compression is not a fixed serial pipeline. Windows chooses dynamically according to the kind of page, compression efficiency, CPU load, memory pressure, and whether a backing store exists.

13. Summary

• The PFN database is the ledger that tracks a physical page’s ownership, references, modification, and page-list state.
• A clean page that leaves the Working Set remains on Standby and can return via a soft fault if the same contents are needed.⁸
• A dirty page waits on Modified and is written back to the page file if it is private, or to the corresponding file if it is mapped, and so on.³
• Available is the sum of Standby, Free, and Zeroed; a large Standby by itself is not a memory shortage.¹
• Memory compression compresses pages in RAM to reduce I/O, but it does not erase the roles of Commit and the page file.¹⁰
• The page file supports the Commit Limit, modified private pages, and system crash dumps.⁴²
• The appropriate size is determined by peak Commit and dump requirements; it cannot be decided by a uniform multiplier.²
• Working Set trimming and clearing Standby are not memory-leak fixes.

Continued in Part 3, “Section Objects and Copy-on-Write: What DLLs and File Mappings Really Are”.

We follow why file pages and DLLs that remain on Standby are visible from multiple processes as the same physical page.

Related Articles

• The Depths of Windows Memory (Part 1) — The Moment a Virtual Address Becomes Physical RAM: A Page Fault from Start to Finish
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now

Related Consulting Areas

KomuraSoft LLC handles investigations of Windows application memory pressure, Commit exhaustion, paging, Working Set growth, and crash-dump collection design.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Migration
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is a page written to the page file as soon as it leaves the Working Set?

No. An unmodified page moves to Standby with its contents intact and becomes a cache that can be reused immediately. A modified page moves to Modified, and after it is written back as needed to the page file or the corresponding file, it proceeds to a reusable state such as Standby.

Does Task Manager's Available include Standby memory?

It does. The available physical memory Windows reports is the sum of Standby, Free, and Zeroed. Standby still holds old contents, but because it can be reused for another purpose immediately if needed, it is counted as available memory.

Does writing to the page file start only after RAM is completely exhausted?

No. Windows writes back infrequently accessed modified pages in the background according to the Modified list and the state of available memory. It is not a simple mechanism that waits for absolute exhaustion and then evicts everything at once.

Does disabling the page file make Windows faster?

You cannot assume it will, as a general rule. Disabling it lowers the Commit Limit, makes it harder to remove infrequently accessed modified pages from RAM, and also affects system crash dumps. Normally you leave it system-managed and decide by measuring peak Commit and dump requirements.

If you have memory compression, is the page file unnecessary?

It does not become unnecessary. A compression store compresses pages in RAM to reduce I/O, but compressed pages still use physical memory and do not replace the Commit guarantee. The choice between compression and paging out is a dynamic policy of the memory manager.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.