Memory Leak, Windows 8.1, I think it's TCPIP.SYS

J

JeffM

Member
Joined
Jul 7, 2015
Posts
11
Task Manager shows the vast bulk of my 8 gigs of RAM is being consumed in non-paged pool memory (over 7.1 gigs of it). I ran poolmon.exe, and the tag indicates it is TCPIP.SYS.

Here is the log of scfFix:

SFCFix version 2.4.5.0 by niemiro.Start time: 2015-07-07 17:04:43.748
Microsoft Windows 8.1 Update 3 - amd64
Not using a script file.








AutoAnalysis::
SUMMARY: No corruptions were detected.
AutoAnalysis:: directive completed successfully.








Successfully processed all directives.
SFCFix version 2.4.5.0 by niemiro has completed.
Currently storing 0 datablocks.
Finish time: 2015-07-07 17:07:00.312
----------------------EOF-----------------------

I am not sure if the CBS.zip attached or not. I saw it upload twice, but there is no indication as to success or anything.
 
Admittedly possible - disabling drivers for antivirus rarely fixes anything, as they can continue to do things unless completely uninstalled - disabling drivers is not a valid test, for what it's worth. To the problem at hand, however, a memory leak in tcpip.sys directly seems unlikely, although anything is possible. Usually these leaks end up being triggered by network drivers, network traffic management software, or antivirus drivers that have network scanning or built-in firewalls.

It might be helpful to reboot, download the poolmon3vbs utility from here, extract the zip file to C:\Poolmon3, and then run _LogPool-as-a-service.cmd to start logging. Once you see the issue reproducing, run the _RemovePoolmon3Service.cmd file to stop the logging. Zip and upload the Poolmon-OUTPUT folder created in C:\Poolmon3 for analysis.
 
The RAM is consumed as quickly as boot-up. There would not be enough time to run a command prompt utility to get a log.
 
Hmmm - that doesn't seem right. That is definitely driver behavior. Can you configure your machine for a complete memory dump in safe mode, and then capture a memory dump when it occurs again via the keyboard?

Complete dump configuration:
Dump Files - Configure Windows to Create on BSOD - Windows 7 Help Forums

Keyboard BSOD configuration:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff545499(v=vs.85).aspx

If you do both of those, and reboot, you should be able to hold down the RIGHT-side CTRL key and press ScrLk or Scroll Lock twice and trigger a BSOD. The resulting memory.dmp file should show what's consuming the pool.
 
I have an HP Envy TS 17 laptop. There is no Scroll Lock button. When I access the on-screen keyboard, there is a Scroll Lock button. However, pressing <Right Control> lights up the on-screen key, but as I hold it down and press <Scroll Lock> on the on-screen keyboard, nothing happens. I pressed it twice as instructed. I tried most all of the other keys in the area as well, and still I was unable to produce a BSOD. I read the instructions in the 2nd link about as carefully as my limited skills allow me to absorb. If the answer on how to do this was in there, I apologize. Can you explain how I might get the dump with my laptop model/configuration? I have Windows 8.1 and a touchscreen, FYI.
 
I looks as if <ctrl> + <fn> + <pause> on the main keyboard toggles the scroll lock for the onscreen keyboard (osk). With that, I still have not been able to force the BSOD and dump. I confirmed that it is set to "complete dump" and my virtual file size is adequate (min. 10,000; max 12,000). It does say that just over 7,000 is "currently allocated."
 
Here is an interesting development. I researched and found that there is a utility called NotMyFault.exe which you can use from the command prompt to force a crash. I forced the crash. The Memory.DMP file was NOT updated/replaced. It retained a June 11, 2015 date stamp. However, I went into task manager, and now the memory usage is 43%, and the size of the non-paged pool is a mere 205 Megs. I have NO IDEA why this is. I shut down and re-started. Still, the non-paged pool is small, and the memory usage is no longer at 99%. Prior to this, the problem was there after probably 20 or more re-boots. I would be curious if anyone has any guesses as to how NotMyFault's forced crash could have fixed this problem.
 
It didn't - the reboot did. You want to leave the option to crash the system if it happens again...
 
cluberti said:
It didn't - the reboot did.
Click to expand...

Getting your help and doing some additional researching has led me to stuff I never had a clue existed as regards this low-level diagnosis and management. Can you explain what occurred within the reboot to fix an issue such as this? Was a driver fixed? If so, with the myriad driver configurations and possibilities, how could it anticipate a particular driver issue and correct it?
 
I forced the crash by downloading NotMyFault.exe and running it with a /crash parameter. notmyfault.exe - Sysinternals Forums

I do not know how it diagnosed or fixed anything. It crashed. It said it was gathering information. It gathered for maybe 10 seconds (not long), and then, it re-booted. That's all I know.
 
It looks like the crash parameter simulates the 0xD1 bug check, so it probably auto-defaults to too high of an IRQL for myfault.sys.

Anyway, as far as why crashing the system with NMF lowered your NPP usage by drastic amounts, cluberti's going to have to explain that one, because I'm honestly not too sure.
 
NPP is consumed by certain parts of the system, and by drivers. The reboot unloaded whatever was consuming the memory, but as to why that "fixed" it we would have to have had data from before the reboot. So, in essence, the reboot "fixed" it insomuch as the problem went away, but we don't know why or if the issue will return, hence leave the system the way it is and crash it again if it gets into the problem state again in the future.

Since consumption that high at boot is not indicative of a leak but more of a bad allocation scheme, it's almost always driver-related. It's not likely that the problem will return during the current boot unless the driver that caused it unloads and reloads, which is highly unlikely for something on the network stack. It might return after a few reboots, but given we don't really know anything about the problem other than the symptoms and what they generally indicate, it's hard to say with certainty how. I only know what I (believe to) know about what's happening based on my knowledge of how the system itself (Windows, the kernel, and kernel-mode drivers) works.
 
Last edited:
So far, so good. I am glad (and surprised) to find a forum like this with this level of knowledge and support. It's really pretty cool. Thank you for helping.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top