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.
You spot the faulty process in poolmon.exe (sort by bytes by pressing B ) than use that command in cmd.exe : findstr /sIt comes in the Windows Drivers Kit (you need to download it). 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. If that can help anybody, I used poolmon.exe to find out what was going on.
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. 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.
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. 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. With the 32-bit version, when I Parse a Driver For Memory Tags and browse to a file, click OK, the process crashes. Even with pooltag.txt the pool tag column is meaningless without some kind of readme.txt or help or web page. NPP is consumed by certain parts of the system, and by drivers. Both AMD64 files crash when loading on Server 2008 64-bit.
0 kommentar(er)
