Return to

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 I will also try the network adapter driver tips, but again, these tips seem most applicable for server scenarios.

Thanks in advance.