What causes page faults?

Question

According to Wikipedia:

A page fault is a trap to the software raised by the hardware when a program accesses a page that is mapped in the virtual address space, but not loaded in physical memory. (emphasis mine)

Okay, that makes sense.

But if that's the case, why is it that whenever the process information in Process Hacker is refreshed, I see about 15 page faults?

Or in other words, why is any memory getting paged out? (I have no idea if it's user or kernel memory.) I have no page file, and the RAM usage is about 1.2 GB out of 4 GB, which is after a clean reboot. There's no shortage of any resource; why would anything get paged out?

Answer 1

Let us understand the basics of the working of memory. Memory has physical and logical addresses. The physical address has blocks named frames. The logical address has blocks called pages. The CPU generates the logical address and divides it into two parts, namely offset and page number. A page table consists of indexes to respective page numbers and their matching to the individual frame numbers. It adds the offset to the frame number, finally giving the address in the physical memory.

The absence of the required page number in the table gives rise to a page fault. The main reason for page faults is the absence of a piece of memory in the physical memory(or main memory) or the lack of the amount of memory at the requested location. It means that a piece of memory is part of the program's working set, but the system cannot trace it in the physical memory. It is an exception generated by the computer's hardware, which tells the operating system about the missing references.

The memory Management Unit(MMU) handles this process. Now, there are two types of page faults, namely hard page faults and soft page faults.

Hard Page Fault It occurs when the required page is not in the main physical memory, so the system must fetch it from the virtual memory. There is a validity bit associated with the entries in the page table. If the validity bit is found to be zero for some entry, it indicates that the page has not been assigned any frames, so page fault occurs.

Soft Page Fault It occurs when the page to be found is found somewhere else in the memory. This actual place where the system finds the piece of memory can be the 'cache.'

Now let us understand the different causes of page fault.

A page fault can occur when you wish to access a page that is not a main memory resident. But, the piece of memory to be accessed is in the virtual memory from where it is to be fetched.

A page fault can occur when you want to access a page that is part of a page table that comes under the 'standby' mode category. It means that the page is under a modified page table, and to solve this; the page has to be transferred to the correct session's page table or the proper working set.

An occurrence of a page fault may be due to the practice of accessing a demand-zero page. It happens when you wish to allocate a block from the heap memory, and the heap manager gives new pages, and when you try to access those pages, a demand-zero page fault occurs.

When you try to hook a function in kernel32 by writing to its pages, a copy-on-write page fault occurs. It is because these pages get copied silently. So, the changes on these do not affect other processes.

So, a page fault occurs for more than one reason discussed above.

Answer 2

(I'm the author of Process Hacker.)

Firstly:

A page fault is a trap to the software raised by the hardware when a program accesses a page that is mapped in the virtual address space, but not loaded in physical memory.

That's not entirely correct, as explained later in the same article (Minor page fault). There are soft page faults, where all the kernel needs to do is add a page to the working set of the process. Here's a table from the Windows Internals book (I've excluded the ones that result in an access violation):

Reason for Fault	Result
Accessing a page that isn’t resident in memory but is on disk in a page file or a mapped file	Allocate a physical page, and read the desired page from disk and into the relevant working set
Accessing a page that is on the standby or modified list	Transition the page to the relevant process, session, or system working set
Accessing a demand-zero page	Add a zero-filled page to the relevant working set
Writing to a copy-on-write page	Make process-private (or session-private) copy of page, and replace original in process or system working set

Page faults can occur for a variety of reasons, as you can see above. Only one of them has to do with reading from the disk. If you try to allocate a block from the heap and the heap manager allocates new pages, then accesses those pages, you'll get a demand-zero page fault. If you try to hook a function in kernel32 by writing to kernel32's pages, you'll get a copy-on-write fault because those pages are silently being copied so your changes don't affect other processes.

Now to answer your question more specifically: Process Hacker only seems to have page faults when updating its service information - that is, when it calls EnumServicesStatusEx, which RPCs to the SCM (services.exe). My guess is that in the process, a lot of memory is being allocated, leading to demand-zero page faults (the service information requires several pages to store, IIRC).

Answer 3

A slow but steady source of page faults is the OS probing for infrequently accessed pages. In this case, the operating system marks some pages not present, but leaves them in memory as-is. If an application accesses the page, then the #PF trap occurs and the OS simply marks the page present again without further ado. If a "long time" passes and a page never trips a fault, then the OS knows the page is a good candidate for swapping should the need arise. This mechanism can run proactively even in times of no resource pressure.

Answer 4

"page that is mapped in the virtual address space, but not loaded in physical memory" does not imply that it previously was in physical memory. Suppose you map a file? It's still on disk, not in memory yet.

Suppose you map a log file and keep appending to it. Every time you exceed the end of committed memory, a page fault occurs, the OS will provide you with a new empty page and adjust the file length.

---

It could also be access violations which are caught and handled by the program.

---

It could also be that the program uses more memory segments than fit in the TLB (which is a cache for the page tables). When pages are contiguous, they can all be handled by a single page table entry. But if memory is fragmented in physical address space, many page table entries are needed, and they may not fit in the TLB. When a TLB miss occurs, the OS page fault handler is invoked and looks up the mapping in the process's page table.

In some ways, this is a variation on Dean's answer: the pages are already in physical RAM, and the OS does need to load those mappings into the TLB, but not because of IPC.

Brian pointed out that x86 (and therefore all Win32 systems) handles this without a page fault.

---

Yet another cause of page faults is triggering guard pages used for stack growth and copy-on-write, but usually those would not occur without bound. I'm not 100% sure if those would show up as access violations or not, because they will be marked as an access violation on entry to the MMU trap, but are probably handled by the OS page fault handler and not transformed into the user mode (SEH) access violation.

Answer 5

Resource allocation is a delicate balance between keeping primary storage available for use and preventing needing to go to secondary as much as possible. If a process tries to allocate memory and can't that's usually an exception and sometimes a fatal exception.

Essentially, you can't keep everything in RAM with no free resources available because when a program starts or asks for more it will crash.

Answer 6

Any time a mmap'd section is read, a page fault is generated, which includes whenever you load a DLL. So, loading a DLL doesn't actually read all of the DLL into memory, it only causes it to be faulted in as the code is executed.

Answer 7

Operating Systems use paging to group items witch should be placed in physical memory and move them between physical memory and shared memory. most of the time, data items witch place in a single page, are related to each other. when data items in a page are not used for a long time, operating system moves it to virtual memory to free some space in physical memory. and then when a page is required witch is in virtual memory, operating system moves it from virtual memory (hard disk) to physical memory. this is Page Fault !

and remember, different operating systems are different in paging algorithms.

Basics of Page Faults

Answer 8

You'll see soft page faults when memory is being shared between processes. Basically, if you have a memory-mapped file shared between two processes, when the second process loads the memory-mapped file, soft page faults are generated - the memory is already in physical RAM, but the operating system needs to fix up the memory manager's tables so that the virtual memory address in your process points to the correct physical page.

Particularly for something like Process Hacker, which is likely injecting code into every running process (in order to collect information) it's likely making quite heavy use of shared memory for doing IPC.