DIMM causing reserved RAM issue + memory leak(?)

TL;DR: physical DIMM is causing ‘hardware reserved’ issues, with the DIMM itself being 4GB and causing a 6GB reservation (50%) when slotted combined with 3 other DIMMs. Booting with that particular DIMM (solo) is unsuccessfull, but it is detected when slotted combined with the other 3 DIMMs. Windows Memory Diagnostic tool does not report any issues on any of the DIMMs. Futhermore, a re-occuring (related?) issue with non-paged pool ammount can take up to 75% of the available RAM, but does not always occur. Advice requested on next diagnostic steps.

Dear reader,

I have had the following problems for quite some time now, yet never had the time and energy to really solve it. One of the DIMMs is causing a 50% hardware reserved RAM problem, when taken out it is solved. However, a second problem of large non-paged pool memory can take up to 75% of the available RAM sometimes. They are probably related, yet the second issue still occurs without ‘faulty’ DIMM from the first issue. I would like understand the cause behind the first issue, and advice on how to solve the second issue.

System and Background

This is my old system, has run with W10 before. Is has been through many hardware changes, but always stable in its current configuration (excluding videocard, but I’m not supsecting that aspect to be the cause).

  • Phenom II X4 965 BE (stock)
  • MSI 970 gaming
  • 2x2GB GEIL DDR3-1300
  • 2x4GB Crucial Ballistix Sport DDR3-1600

The memory kits have been matched on voltages and timings, and I have never had any issues using these two kits together before (has been used for ±20 months with aforementioned configuration).

It is a clean install of W10 Pro (1803) on a brand new HDD (previous one failed), and is primarely used as a multimedia machine and webbrowsing.

Issue #1: DIMM causing 50% hardware reserved RAM

For quite a while this system is/was having a large RAM hardware reserved buffer, a total of 6GB reserved (50% of total). Initial moment of this problem starting is unknown. After some basic research and tests (Memory Diagnostic tool, checking processes etc.) I started playing around with the physical DIMMs themselves. With all 4 DIMMs in use, 6 out of 12GB is reserved. After testing all possible configurations of DIMMs (single, dual, triple, quad) in different DIMM slots (1-4), I found that one of the Ballistic DIMMs appeared to not work solo (no windows boot). Using it together with any of the other DIMMs, it caused a 50% RAM reservation (no matter the total slotted capacity). But when excluded from any other configuration possbile (2;2x2;4;4x2;2x4;2x4x2 etc.) only ±40MB is reserved. BOOT Advanced options > Maximum memory is (and was) off.

Meaning that I am currently using a DIMM configuration of 2x4x2, in DIMM 1-3, for a total of 8GB. In this case, removing a DIMM actually gives me more usable RAM…

This issue has been ‘solved’, but not quite understood how a 4GB stick can cause up to 6GB of hardware reserved RAM. I would like to know if I can somehow test if the particular DIMM is actually faulty/broken, even though it is detected (and accepted?) by Windows.

Issue #2: non-paged pool memory leak (?)

After taking out the ‘faulty’ DIMM from issue #1, I still noticed a suspected memory leak. RAM usage of processes in Task Manager and Resource Monitor did not add up to the reported total usage in both the Performance tab of Task Manager and CoreTemp RAM usage. I ran RAMMap, which drew my attention to a massive 4GB+ in non-paged pool memory (something I didn’t pay attention to in Task Manager). It has even reached 6GB (75% of total RAM). I can literally see it accumulate from after the first seconds after booting to desktop. For example, last time it started at ±100MB and stopped at ±440MB. I don’t know if this number is normal though. It appears that it does not always occur and/or continue accumulating linearly plotted against time passed, sometimes the non-paged pool memory stays at ±440MB. This issue also occurred during the initial 4-DIMM configuration from issue #1, but I thought it was related to the reserved RAM and therefore did not look at it more deeply.

My next step is to try and identify the leak with Poolmon, followed up with Kernal Debugger. I have, however, no experience using these tools, and it seems these are mostly used in server scenarios. I was wondering if someone with more Memory-related experiences has some input on my observations and the next steps I’ll be undertaking.

I have read through some articles, one of which is http://woshub.com/huge-memory-usage-non-paged-pool-windows/. I will also try the network adapter driver tips, but again, these tips seem most applicable for server scenarios.

Thanks in advance.



​Alright, so I’ve been able to identify and (presumably) fix the issue. Instead of the usual >1.5GB of non-paged memory it is now down to ±105MB when idle.

I had to figure some things out during this process, as I had no clue on how to execute certain steps and had to combine certain how-to’s to figure things out. Credit goes to the people and organisations that suggested these mentioned fixes in the first place. Sources cited at the end.

I used Poolmon to identify the pool tag that causes the leak, followed by Sigcheck. Poolmon indicated that tags “Wfpn” and “NDNB” were increasing in size after a while, and much larger than other non-paged pool memory used. Sigcheck says the following about these:

  • Wfpn = netio.sys = “Network I/O Subsystem”
  • NDNB = Ndu.sys = “Windows Network Data Usage Monitoring Driver”

Using these I searched online for issues related to “Network I/O Subsystem” and “memory leak”, and I found plenty of information. Turns out more people have had issues with these two pool tags/drivers (even back in Windows 8 days), and that there is more than one solution for it. I will list the ones I found most applicable to this situation.

  1. Killer network drivers (E2200 in my and most other cases) seems to be causing quite some issues, in general. Updating or re-installing this network driver may fix the issue.
  2. Disabling NDU (Network Data Usage) via command using the following line (OR Autoruns OR register edit (I prefer to stay clear of this option)), and then rebooting:

sc config NDU start= disabled

After a reboot, the non-paged pool remained 1.4GB (previous amount before reboot), but after a second reboot it was only 95MB. It now stays around that number, increasing depending on running processes of course. But it clears itself now and doesn’t increase to infinity anymore.

In case a/your memory leak non-paged pool tag refers to a different (third-party) driver, consider the aforementioned solutions non-applicable. In that case, try updating or re-installing the driver. Or, if the issue remains, consider uninstalling the driver/program if it serves no real/essential purpose.

Issue #1 still stands, but I suspect I won’t be receiving any tips.


Used sources and other information:


This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.