| Previous | Next |
| STATUS_PAGE_FAULT_GUARD_PAGE | STATUS_CACHE_PAGE_LOCKED |
STATUS_PAGE_FAULT_PAGING_FILE
A page-file-backed hard fault supplied the missing page
This result indicates that the requested contents were not resident and had to be recovered from secondary storage. For private committed memory, that usually means the paging file; mapped-file faults use the backing file instead. The operation can complete successfully even though it introduces storage latency.
Do not diagnose this status from physical RAM usage alone. Commit pressure, working-set trimming, storage latency, and competing I/O determine whether paging becomes harmful. A few hard faults are normal; sustained faulting with low useful progress can indicate thrashing or a workload whose active set exceeds available memory.
What to inspect
- Measure hard-fault rate, page-read latency, commit charge, and available physical memory together.
- Identify the process and virtual region responsible for repeated paging-file reads.
- Check whether working-set limits or memory pressure are evicting pages that are immediately reused.
References
- Microsoft: Introduction to the page file
- Microsoft: Active memory dumps and page states
- Microsoft: Process working sets
- ReactOS source: NT page-fault resolution
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.