I have an trouble with Windows Server 2008 R2 Enterprise. The paged pool load memory but does not load the actual pagefile (I have space on the drive for it).

Actually the problem is in memory excesive load and I assumed that this is the problem.

Virtual memery setting :


Pagefile usability: screen and the memory usage still slowly slowly grow

Task Manager performance: screen

Task Manager processes: screen

RAM map: screen

System information: screen

  • 1
    But your page file is used. Note how the current “commit” is already higher than the amount of physical memory. // Also, are you really expecting the kernel to use that much memory? – Daniel B Feb 11 '18 at 11:12
  • 1
    use poolmon to see why paged pool usage is too high and which driver is using so much RAM. – magicandre1981 Feb 11 '18 at 17:49
  • i.stack.imgur.com/p8Ub6.png the top processes are about 143 MB, am i searching in the right direction ? – George21 Feb 12 '18 at 14:59
  • sort the data first with B for bytes – magicandre1981 Feb 12 '18 at 15:25
  • i already done this i.stack.imgur.com/BpZSy.png – George21 Feb 12 '18 at 15:40

First comment: the display of "kernel memory - Paged", almost 22 GB here, is the virtual size of the paged pool.

The "pools" in Windows are kernel-space heap storage. They're used by kernel drivers and Windows kernel mode code in much the same way as heap is used by user mode programs, but they're in kernel address space, common to all processes, and of course, accessible from kernel mode only. There are several types of pool allocations but they break down to "nonpaged" and "paged" areas. The nonpaged pool is always resident in RAM.

The paged pool should really be called the "pageable" pool, because being called the "paged pool" doesn't mean that it is paged out of RAM, or that it necessarily will be. It does mean that it's just as subject to being paged out as are most user mode allocations.

And as with user mode allocations, we can expect that at any time, some subset of the paged pool's virtual size will be "resident" or "valid" in RAM (accessible without incurring a page fault; such RAM is considered "in use"); another subset will be "in transition" (on the standby or modified page list, and accessible but with a soft page fault), and the rest will be truly paged out - in the page file, requiring a hard page fault to access.

Now, 22 GB is a lot of paged pool. I mean, really, really a lot. Such an amount is very unusual. I suspect you have a faulty device driver that's leaking paged memory like a sieve.

I would use poolmon or Windows Performance Toolkit to find out what's allocated all of that pool. There are many answers here on SU that show how to do this in detail.

In a comment to your question, magicandre1981 linked to one of his answers that details the procedure.

Beyond that, it appears that something is preventing writing to the pagefile.

Your screen cap from RAMmap (and thank you for including that) shows that of the 19 GB of paged pool that is occupying RAM (note, this is smaller than the virtual size), about 620 MB of it is "active". Meaning that much RAM is considered to be "in use". That's the part that can be accessed without a page fault. The PTEs that describe those virtual pages have their "valid" bits set.

Almost the same amount, about 680 MB, is on the Standby page list.

And then here's the indicator of a second problem: over 17 GB are on the "Modified" list.

The "Modified" page list is where pages are put when they are moved out of a working set after having had their contents modified since they were brought in. (If a page's contents weren't modified since it was paged in, then when it's lost from its working set it's just put on the Standby page list, part of "available" RAM and immediately repurposable for other use.) Such pages cannot simply be released for use by some other process; their contents have to be saved. For pages backed by the pagefile, "saved" means "written to the pagefile".

After a modified page has been written to disk, it gets moved to the standby list, from which it can be repurposed. The standby list is counted as part of "available" RAM. (It's also part of the "Cached" counter in that task manager display.)

So you have over 17 GB of RAM on the modified page list - RAM that your system would like to write out to your pagefile.

This is wildly excessive.

Most systems have no more than a few percent of their RAM on the modified list. There are threads in the System process that are supposed to take care of writing modified pages back to disk, every time the modified list exceeds a small threshold. They're not doing the job.

I notice your current pagefile size is about 5 GB and per the WMI output it is full. (So your system is writing to the pagefile.) But it appears that pagefile expansion is, for some reason, not happening.

Hmm - you have limited your pagefile size to 20 GB maximum and even if it was expanded to that size, that would not be enough to hold its current contents plus 17 GB more. Perhaps if you made the maximum possible PF size larger (Windows suggests almost 40 GB) then things would be unstuck.

But I doubt it. I see no reason for Windows to not expand the pagefile up to the limit. True, it wouldn't hold all of the modified pages, but holding most of them is much better than keeping so many of them in RAM.

Meanwhile, those 17+ GB are not "available" for other use. This is why your "Available" RAM is so low.

We have seen bugs in pagefile size that are cleared by:

  • set the pagefile to disabled
  • shut down and reboot
  • be sure the old pagefile is gone. If not, delete it.
  • set the pagefile sizes to something reasonable
  • if necessary, shut down and reboot

You might try that.

But your real problem is that you really shouldn't need 20 GB of paged pool in the first place. Find and fix that.

After that, you should examine your pagefile usage again and set its initial size to be at least twice as large as the routine usage. There is no good reason to set the initial size smaller than your system will routinely need. (I like to see the pagefile no more than 25% in use, for reasons having to do with the space allocation algorithms - they work a lot better with a lot of free space to work in.)

btw, both "Standby" and "Modified" pages are (somewhat misleadingly in my opinion) counted as part of "Cached" on that Task Manager screen. So the fact that you have 17.4 GB "Modified" explains that huge "Cached" number. The huge "Cached" number is not in and of itself a problem; it's one of the symptoms.


Paged pool is a categorization for kernel mode code. Kernel mode code would use paged or non-paged pool for operations and certain operation mandates certain type. This may or may not be backed by the pagefile. It is up to the Operating System to allocate and use paging. Indeed Paging costs you I/O hence OS would prefer to keep as much it can in Physical. 24 GB physical for an x64 bit OS is the config as I see. The OS can very well manage most of the operations in primary memory.


The above reference will help to understand about the cached size.

I do not think this is a problem. I also cannot probably elaborate beyond what the obvious metrics in the tools, you have used, show up.

Edit:- After all the analysis "See ~40 comments" the culprit is found to be a third party driver. Analysis done with the help of the first-class analysis/indication that this is indeed a problem (credit: Jamie Hanrahan) and Paged Pool analysis (credit:Magicandre). Further analysis required to answer the actual question.

  • This may or may not be backed by the pagefile. All memory categories except "non-paged pool" will be backed by the page file. Note that being backed by the PF is distinct from actually being written to it. Being backed in the PF simply means that the OS has reserved space in the PF. – Twisty Impersonator Feb 11 '18 at 13:21
  • I meant that it will still be getting a chance to use the page file. I did say that clearly when I said, it is up to the OS to use it! When I said it may not be backed by PF I meant it may not be swapped out frequently. I understand "backed" should have been used carefully and thanks for making it semantically right Twisty! – Sreejith. D. Menon Feb 11 '18 at 13:23
  • To add to that - for memory mapping this is a choice that it be backed by paging file or by an actual file that will be mapped to file system cache. So in that case it will not be backed by paging file but by the actual file based on which the section object is made. So you may want to look into that aspect too Twisty. I know talking about memory management isn't that easy :) – Sreejith. D. Menon Feb 11 '18 at 13:32
  • "All memory categories except "non-paged pool" will be backed by the page file. " Sorry but that is not true. As SDM said, memory allocations backed by mapped files are backed by the files themselves. This may indeed be the pagefile (call CreateFileMapping with NULL for the file handle, and you get a pagefile-backed section) but much more commonly it is a specific file. All executable code (exe's, dll's, etc.) is handled this way, so you can see that there must be quite a bit of this going on. Look at the "DLL" pane of Process Explorer to see the files that a process is mapped to. – Jamie Hanrahan Feb 12 '18 at 5:51
  • Jamie Hanrahan as in Jamie Hanrahan of Windows internals :O. If yes, then it is some learning time for me now and nice to see you around :) – Sreejith. D. Menon Feb 12 '18 at 6:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.