I need to comment to the comments to the question, particularly the confusion between "page table" and "page file". This is not an answer but it won't fit in the space allowed for comments.
"Page table" is indeed a very different thing from the pagefile. Having n MB of RAM used for page tables does not mean you are using n MB of pagefile space. And although some page table entries (PTEs, which are what page tables consist of) do refer to pagefile contents, not all do.
The page tables are in-memory structures that are used by the CPU's MMU to perform address translation from virtual addresses (again, not the pagefile) to physical addresses, and by the OS to keep track of virtual address space and help resolve page faults. Page tables consist of page table entries (PTEs). Each PTE occupies 8 bytes and defines 4K bytes of virtual address space - i.e. one virtual page. There is, roughly, one PTE for each not-free page of virtual address space.
By the way, although the pagefile can experience both external and internal fragmentation (the former is usually not much of a problem; the latter can be ameliorated by making it about four times as big as it needs to be), page tables cannot. They're sort of always fragmented already, and it doesn't matter in the slightest.
Each PTE has a "valid" bit. For "valid", aka "resident" pages, the PTE contains the physical page number that corresponds to the virtual page number that's associated with the PTE; this is used directly by the MMU.
For "invalid" pages the MMU raises a page fault and the PTE then has many possible formats and interpretations.
Note: All of the above applies to any operating system that enables paging on x86/x64. The following is largely specific to Windows, but many of the concepts apply to other OSs, with differences in details of implementation.
For a page in the page cache, the PTE still contains the physical page number. For pages that have been lost from RAM and written to the pagefile, the PTE does contain the pagefile number and the offset within the pagefile where the page contents were written. Other possible PTE contents are references to virtual address descriptors, references to "prototype PTEs", references to demand zero pages, etc., which I'm not going to get into. Suffice it to say that only some of the PTEs refer to locations in pagefiles.
I mention all of this mostly to show that the pagefile and the page tables, while related, are definitely not the same thing.
Page tables are organized into a tree structure. There is a different such tree, or collection of page tables, for each process - this is what allows each process to define its own instance of virtual address space. The page table at the root of the tree must be in RAM at all times. The others are pageable; they are even non-existent where they would correspond to large (minimum of 2 MB) regions of undefined, or free, virtual address space.
The page table entries in the tables at the "leaves" of the tree correspond to pages of virtual address space. The PTEs in the higher-level tables - the ones closer to the root (and the root itself) - tell where the next lower-level tables are (if they exist at all).
The number shown by RAMmap is the physical memory (RAM) occupied by all of the resident (in-RAM) page tables for all processes plus the OS.
What is important here is that the system in the OQ had 2.5 GB of RAM tied up with page tables. That means that, at minimum, there's 2.5 GB of page tables defined. Since page tables are themselves pageable, the virtual size could be much larger than the physical size, which is all RAMmap can show us. But assume it's "only" 2.5 GB. At eight bytes per PTE that is about 320 million PTEs. Since each PTE defines one page - 4K bytes - of virtual address space, that means that over 1.2 terabytes of virtual address space are defined by in-memory page tables.
That's not impossible but it's rather a lot.
For reference, on my system atm, I have about 125 MB of RAM in page tables. This would indicate only about 65 GB of virtual address space. My actual virtual usage is much higher (125 TB just for processes) but that is because most of the page tables aren't in RAM. "Large pages", another thing I shouldn't get into here, can also help account for different ratios between size of page tables vs. size of in-use virtual address space.
So: TO find the culprit, I would first go looking in Performance Monitor under the Process category for processes with a high "Virtual Bytes" counter value.
You have to determine what is using your page file to understand the reason your page file ( i.e. your virtual memory ) usage is high. – Ramhound – 2014-07-14T11:13:49.040
1No, I think this is physical memory in use, not virtual. I thought the page table was some kind of reference for the memory manager? – benshepherd – 2014-07-14T11:43:39.660
A page file is a container for virtual memory. Virtual memory is a mechnic within an operating which tells programs they have access to the all the memory on the system. The fact you did a reboot and the page file was cleared indicates you have a program running in the background. – Ramhound – 2014-07-14T11:51:50.047
2As I said in the question, there aren't any processes that are using memory. I was under the impression that the page table was a different thing to the page file. – benshepherd – 2014-07-14T13:33:50.023
3http://superuser.com/a/769002/174557 – magicandre1981 – 2014-07-14T16:11:16.457
1The page table IS a very different thing from the page file. See my answer below. Also, while the pagefile can get fragmented, page tables... well, they're always fragmented (as in scattered throughout RAM) and it doesn't matter in the slightest. – Jamie Hanrahan – 2015-09-26T14:31:50.950