I have 16GB of system RAM. On startup with no applications open except the task-manager Windows is using about 3gb of RAM. I looked in the processes tab, but nothing seems to be out of the ordinary. How can I find out why my Windows is using so much RAM.

enter image description here

all processes from all users

enter image description here

Reading from the poolmon it seems that my wireless broadcom driver is using about 0.4GB of of RAM. Even if I remove it would still be using 2.6GB on start-up, which is still too much.

enter image description here

After reinstalling the wireless driver associated with the memory leak. I have a new screenshot and would like to confirm that it was indeed a memory leak.

enter image description here

  • 3
    First of all, you only have 12GB. Either one of your four 4GB sticks is bad or poorly seated, or your motherboard doesn’t support 16GB. Second, have you tried running any security programs to check for malware? Security Essentials is built-in, so make sure to update its definitions and run a scan. Also try some anti-rootkit programs since rootkits specifically hide (though they also usually try to keep a low profile to go unnoticed, and using up a couple of gigabytes of RAM is hardly blending in).
    – Synetech
    Nov 12, 2013 at 1:30
  • You might want to look at performance -> resource monitor
    – Journeyman Geek
    Nov 12, 2013 at 1:31
  • Try running the tasklist command redirecting its output to a file, C:\blah>tasklist >a.a, then open the file a.a, you see totals for each process e.g. 15,100K , remove the K after them, and sum the total with Excel. See if the total matches the used figure that task manager gives you near its graph for used. For me the total from tasklist is 4GB and task manager says 4.5GB. I can't explain the discrepancy I have but it's not huge. it'd be interesting if you have a huge discrepancy.
    – barlop
    Nov 12, 2013 at 1:42
  • I do not have excel
    – Vader
    Nov 12, 2013 at 1:45
  • 1
    The NDxx tags are ndis.sys. I'd guess BRCM was Broadcom. That would point to your network adapter being the problem. Nov 12, 2013 at 13:54

4 Answers 4


You have a memory leak caused by a driver. Look at the high value of nonpaged kernel memory. In your case this is over 3.7 GB. You can use poolmon to see which driver is causing the high usage.

Install the Windows WDK, run poolmon, sort it via P after pool type so that non paged is on top and via B after bytes to see the tag which uses most memory. Run poolmon by going to the folder where WDK is installed, go to Tools (or C:\Program Files (x86)\Windows Kits\10\Tools\x64) and click poolmon.exe.

Now look which pooltag uses most memory as shown here:

enter image description here

Now open a cmd prompt and run the findstr command. To do this, open cmd prompt and type "cd C:\Windows\System32\drivers", without quotes. Then type "findstr /s __ .", where __ is the tag (left-most name in poolmon). Do this to see which driver uses this tag:

enter image description here

Now, go to the drivers folder (C:\Windows\System32\drivers) and right-click the driver in question (intmsd.sys in the above image example). Click Properties, go to the details tab to find the Product Name. Look for an update for that product.

If the pooltag only shows Windows drivers or is listed in the pooltag.txt ("C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\triage\pooltag.txt")

you have use xperf to trace what causes the usage. Install the WPT from the Windows SDK, open a cmd.exe as admin and run this:

xperf -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree+PoolAllocSession+PoolFreeSession -BufferSize 2048 -MaxFile 1024 -FileMode Circular && timeout -1 && xperf -d C:\pool.etl

capture 30 -60s of the grow. Open the ETL with WPA.exe, add the Pool graphs to the analysis pane.

Put the pooltag column at first place and add the stack column. Now load the symbols inside WPA.exe and expand the stack of the tag that you saw in poolmon.

enter image description here

Now find other 3rd party drivers which you can see in the stack. Here the Thre tag (Thread) is used by AVKCl.exe from G-Data. Look for driver/program updates to fix it.

  • 1
    oh, sorry. @Jebediah Kerman have you run the findstr command? From the name it could be network card driver related. If you still have issues, run RAMMap, store the data as RMP, compress the RMP file and upload the zip. Nov 12, 2013 at 19:20
  • this may sound stupid. But how do I start poolmon. I used to be able to search for "poolmon.exe" and launch
    – Vader
    Nov 12, 2013 at 21:58
  • @JebediahKerman I think you already did this and found the tags. Is the picture from your post not your poolmon? Nov 13, 2013 at 4:46
  • The picture is mine. for some reason the search index was incomplete.
    – Vader
    Nov 13, 2013 at 13:07
  • @JebediahKerman have you looked what this NDFT is? YOu can also use xperf to trace the pool usage: channel9.msdn.com/Shows/Defrag-Tools/… Nov 13, 2013 at 17:58

Well, first thing, before I go into a more detailed answer. In your first screen shot, your Non-Paged Pool (a type of kernel memory usage) is at 1.3GB. That seems unusually high to me, especially for only 30 minutes after boot. I guess I could see NP Pool getting that high after an extended amount of use or with a program that was leaking like a sieve. To contrast, my NP Pool is usually between 100 and 200 megabytes, and my paged pool might be as high as 400 or 500 (and that is after having my system running without a reboot for weeks.)

You can enable a few additional columns in Task Manager by right-clicking the column headers, and choosing select columns. You should add Working Set (private), Working Set (shared), Commit, and NP Pool. I'd scan through all your processes from all users, and see if any of them have an NP Pool more than about 256KB. If you see any, especially any that are considerably higher, that might be the source of the problem, or at least part of it.

Your total working set, the amount of physical memory in use by a process, is the combination of the private and shared working sets (WS). Private is usually bigger for most processes, however there may be some that use a larger amount of shared WS. The two should normally sum to the total WS. Commit is the amount of your working set that has been committed to the backing store (in most cases, the Windows page file). Backgrounded applications will frequently have a greater Commit than WS, indicating that much of their paged pool has been swapped out of memory and into your paging file (which is pretty normal for desktop apps that have been minimized and not used for a while).

The Non-Paged Pool is memory that cannot, and never will, be swapped out of physical memory...that is effectively your permanent minimum physical memory usage. NP Pool memory often contains program code and critical sections that must be in physical memory to behave correctly or securely, special heaps, etc. Out of 60 processes, if all of them have 256KB of NP Pool memory, then your absolute minimum physical memory usage would be around 15,360KB. In most cases one or two apps may have a 256KB NP Pool, while most have less, often considerably less (or none). It is highly unlikely the system would ever page out the entirety of all processes working set, so don't ever expect memory usage to get that low.

Finally, the point of having more memory is to avoid having to page data to and from extended memory space (swap, page file) on a physical disk. Paging is a process that involves moving blocks of allocated physical memory around, pushing some to disk, and bringing others into physical memory from disk. Paging is, to keep it simple, highly undesirable. It isn't "bad" per-se, but it can be a real drag on performance when it occurs too frequently. The ultimate point of increasing the total physical RAM in a system is to allow more processes to keep more of their commit in physical memory (larger working set). Consuming memory is not a problem, and when more executing processes use more memory, total system performance and active process performance will usually be higher, as physical disk activity related to memory accesses (page faults, specifically) will be lower.

Windows manages memory for you, and automatically pages data in and out of memory to and from the page (swap) file for you. If you run a process that needs 9GB of memory and your system is already using 4GB (out of 12GB), then the system will automatically figure out which processes do not need immediate access to their entire working set, and it will page some or all of their paged pool out to swap in order to free up that extra 1GB. If your large process eventually needs more memory, windows will further reduce the working set of other processes until it has enough free space to allocate the newly requested block. Your large process could eventually consume all available memory except NP Pool and perhaps some additional minimal overhead for periodically executing processes that aren't allowing Windows to free up more of their working set (i.e. they have pending page faults that Windows would otherwise swap out of physical memory, but because they are being requested, they cannot be moved.)

If a process needs more memory than it is allowed to access (32bit processes can usually access 2Gb, and some a little less than 4Gb with enhanced techniques, while 64bit processes can usually access around 48Gb of memory, each), then windows will sometimes try to virtualize its memory with swap space. If a 32bit app wants to use its maximum allowed 2Gb of space, but only 1.2Gb are available, windows will reserve the full 2Gb in the page file, and move the processes own data in and out of the page file as needed in order to support the app's memory usage. Total "memory" usage in this case may appear to be greater than the available physical memory, when going by Total Commit. Total Commit will usually max out at the grand total page file size, which when managed by the system, is usually 2-3x the physical memory amount. In your case, Total Commit would be around 24Gb, or 2x your 12Gb physical memory (and this is indicated in your first screen shot, where it states: Commit (GB) 3 / 23).

One final point. You said in your answer that you had 16Gb of RAM, where as Task Manager only sees 12Gb of RAM. One of two things here. Either your system really does only have 12Gb of RAM, or one of your sticks is not registering properly. If a stick of ram (I am assuming 4x 4Gb sticks), it may be bad, may not be seated entirely properly in your motherboard, or your motherboard may have a memory detection issue.

To check if it is the latter, you should first update your motherboard BIOS to the latest version. I had a similar problem...my six Tripple-Channel DDR3 sticks of ram (6x 2Gb) were all good based on individually testing each one...but my motherboard randomly decided not to count one or two of them every so often, often leaving me with only 8Gb of ram. A BIOS update fixed the problem, and I have reliable access to all 12Gb of my memory now.

  • interesting..and I just noticed that re his non-paged memory being very large..mine is 539MB paged,139MB non-paged.U clearly know more than me about this.. But, you're wrong on total commit.U write "Total Commit will usually max out at the grand total page file size"My RAM is 12GB.I set my pagefile to 4000MB(3.8GB?) min and 1.5-2x memory as max.My max commit is 15GB(commit=7/15 currently),my pagefile isAbout 4GB or probably a bit less like 3.8GB.Max Commit is more like pagefile size+RAM size.When my pagefile was 12GB my max commit was about 24GB. Pagefile almost 3.8GB or 4GB max commit is 15GB
    – barlop
    Nov 12, 2013 at 15:12
  • @barlop: Well, you somewhat misunderstand what commit is. Technically speaking, commit charge is the total "virtually addressable memory space", including space supported by extended memory managers and large address awareness. Max commit would not be page file+RAM, rather it would be described as the total system managed virtual address space. Page file should generally cover, at the very least, the total physical memory size, and additionally extend it beyond the total physical memory size. In your case, I'd have expected commit to be at least 18Gb (1.5x) or 24Gb (2x), however that...
    – jrista
    Nov 12, 2013 at 18:03
  • ...would be the case for a system managed page file. It sounds like you have manually tweaked your page file settings, in which case I would have to know more about your specific configuration to tell you why your current commit is 15Gb (as 3.8/4Gb page file would indicate a commit of 16Gb, not 15Gb.) It is entirely possible to manually configure no page file, or a page file that is too small, and that can lead to odd performance issues and memory allocation issues. Best recommendation, unless you have a highly specific server (i.e. database) setup, is to allow windows to manage its page file.
    – jrista
    Nov 12, 2013 at 18:03
  • One final note. For maximal performance, it is best to let windows allocate the maximum page file size ahead of time. This is usually done on server setups like a SQL Server database, where you may preallocate 64Gb or more (usually 2x the physical ram size, so maybe even 128Gb or 256Gb) to a page file that is distributed evenly amongst multiple physical disks for maximum performance. Distributed page files, especially when preallocated to maximum size, allow interleaved reads/writes on all participating disks, thus allowing improved paging performance via parallel I/O.
    – jrista
    Nov 12, 2013 at 18:04
  • As an example of a heavy memory load, my system currently has: 7.5/12Gb physical memory usage; 14.7/23.3Gb commit; 491mb paged pool; 145mb np pool. This is for 146 processes, max paged pool 2276k max np pool 263k. Largest commit size 696,396k, and for the same process WS is 714,256k (an Opera tab process.) (My high process count is due to the web browser...they isolate tabs via process these days, and I'm a hypertabber...dozens open at once, so dozens of additional processes.)
    – jrista
    Nov 12, 2013 at 18:04

How can I find out why my Windows is using so much RAM.

It's using so much RAM because it is designed to do so. There is absolutely no cost associated with using RAM. In fact, used RAM is better than free RAM because the operating system doesn't have to do anything to use it. Using free RAM requires making it used which takes effort.

If you're thinking "I want my RAM free now so I can use it later", forget it. RAM does not have to be free now to use later. You can use it now and use it later. There is no tradeoff here -- there is absolutely no downside to using RAM.

RAM is kept used and directly switched from one use to another without having to go through the effort of making it free just to have to make it used again. Modern operating systems leave RAM free only when they have no other choice.

  • 13
    If my windows7 system is using 3gb of ram on startup, with no apps open, somethings gotta be wrong
    – Vader
    Nov 12, 2013 at 1:44
  • 5
    @JebediahKerman Why do you say that? I put some effort into trying to explain to you why that is not the case and why Windows is designed to do that. Did you not understand my explanation? Or, if you disagree with it, could you explain where you think I'm wrong? Nov 12, 2013 at 3:02
  • 11
    @DavidSchwartz totally wrong answer. He has a memory leak by a driver Nov 12, 2013 at 4:48
  • 10
    @DavidSchwartz: The behavior you describe (RAM allocations that can be reused) must necessarily be made from pageable memory. The worrying figure is 1.3 GB of nonpaged memory. You can't just free that for other resources, where would those 1.3 GBbyte go? Being "nonpaged" means that the ownser said "these bytes are so important, you can't even put them on disk, let alone discard them".
    – MSalters
    Nov 12, 2013 at 8:33
  • 26
    Why is this “answer” voted so high? It completely misses the point. Regardless of the specific words used (which were perfectly clear to begin with), the question is not “Why is Windows using RAM?”, the question is “Why do the RAM usage numbers not add up; why is one part reporting a higher usage than another part?” This post should be a comment at best because it does not address the actual question or even attempt to answer it; it only chimes in with a bit of advice, and bad advice at that since if the OP had ignored it as suggested, the memory leak would not be discovered.
    – Synetech
    Nov 18, 2013 at 21:03

A reason not mentioned above is Hyper-V.

I was able to identify it with the excellent utility RamMap:

enter image description here

The screenshot is from after. Before the "Driver Locked" memory was over 6GB, more than 80% of the RAM in this particular machine. I had to go into Hyper-V Manager and disable "Dynamic Memory". Curiously, even after re-enabling it, the "Driver Locked" memory stayed low - I can only presume prior instances increased it and that Hyper-V does not automatically reduce its allocated memory:

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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