Here are two more screenshots...
OK, so this looks to be almost all used in Nonpaged pool (a region of kernel memory used mostly for driver use). Now that we know it is almost all nonpaged pool, we can figure out what's going on. However, I'm going to need for you to get a rather detailed trace of your machine to figure this out using the Windows Performance Toolkit. I'll update a tutorial on this in the future, but here are the instructions on how to gather a trace tracking pool allocations.
First, you need to run the web installer for the Assessment and Deployment Kit for Windows 8.1 (even if you're on Windows 7 or Windows 8, this is the version you will want to use):
Once you click the "Download" button and run the installer, you will see a download box to specify a location - just click the "Next" button:
The only option you need to select is the "Windows Performance Toolkit", and then click the "Install" button:
It will download and install the WPT component at this point:
Once installed, you should have some new icons in your modern start screen (if you're using 8.1, you'll have to go down to the all applications list, or just type "wpr" to find it). In this screenshot, it's the icon on the bottom-left of this group:
Once you've got the Windows Performance Recorder open, uncheck the "First level triage" box, and check the "Pool Usage" box, and then click the "Start" button to start tracing:
You should see the trace window change slightly to notify you that it's started tracing the system:
Let the reproduction of the memory consumption issue run for at least a few hours, up to a day or so if necessary - however, if you notice any large spikes in memory usage during this time, you can save the trace earlier (this is going to generate a LARGE file, so the less time traced and still capture the data, the better).
Once you're comfortable memory usage has increased steadily to the point you'd consider it an obvious issue, please click the "Save" button, where you'll then be presented the ability to save the trace file:
Make sure you save it somewhere where you have LOTS of disk space available (preferably a few GB), and then click the "Save" button - it will start writing the file out to the location you specified here:
Once the file has saved successfully, click the "OK" button:
I will need you to zip up the resulting .ETL file that was saved, and upload it to a file hoster (or PM me and I'll give you an FTP location to upload) so I can download and analyze the behavior:
It's hard to say from the data gathered, as the issue has pretty much 100% occured in each trace, but the two tags most in use are Wfpn and NBNB, which translate back to netio.sys (network I/O subsystem) and ndu.sys (network data usage monitor). Since these tags in and of themselves aren't called by the OS to this level, something running on the machine is likely hammering the network stack. Also, since I don't see any indication of which process, it's likely going through typical OS binaries (like wininet.dll or winhttp.sys) to make it's network calls. I can see you have quite a bit of networking software on the box - mDNS, probably from iTunes or other Apple software, No-IP, a torrent client, and something called the Qualcomm Atheros Killer Network Monitor (remember one of the tags was the network monitoring one?). That last one is a major suspect, as is the torrent client. I would recommend disabling ALL of these applications, especially the Qualcomm software and the torrent client, and reboot and monitor. If the problem persists, get more data - otherwise, re-enable things one at a time until the problem comes back.
Given the tags and binaries called out by the trace, I'd wager it's either the Qualcomm software directly, or it's behavior with the torrent client running, that's causing this. However, anyone can guess, and I prefer data. Let's see what happens with the recommendations I made.
Yes, it's still the same tags. Did you make the changes recommended? (hint - rhetorical question, I can see from the traces you did not). I still need for you to actually attempt to do what I asked in my previous post. If the problem persists after making the changes I requested, we will need to discuss trace strategy - by the time the trace is stopped, almost all of the allocs against that tag have already transpired. We would need to catch them happening to have a smoking gun, so to speak.
I heard around that the problem relies on the Bigfoot Killer with some sort of bug that drivers still doesn't solve it, and there was a solution of disabling Windows 8 Network Monitoring... How to do it and what do i lose by doing it.
Hi Guy's, I dont want to jeopardize your discussion here, but just to inform you I'm following this post with interest as I have recently got a very similar problem on my new installation W8.1 64 bits. It happens only when I'm playing a few hours with BF4, never when I work for twice this length with typical office type of apps
Symptom is simple, when the memory jam occurs, my game start to lag then I cannot play anymore even to a point I cannot kill it and when I'm looking at tasks and space meory occupation, nothing special to the size of all tasks but memory shows 99% occupancy like if if was reserved or lost zombie memory
I though initially it was a memory problem as I have just installed a stack of 32 gb at the same time of install 8.1, but why would it be HW if all the day it is working fine? So I'm now more looking same direction as you do
hoping you come to a conclusion
I found also this post Windows 8 Extremely High Memory Usage ~8GB!!!!! [Solved] - disk usage - Windows 8
where a"lot" of people are having similar behavior than mine...good thing is...we are not alone, bad thing is it's there since a year...