On 4/7/2011 2:09 PM, Ziots, Edward wrote: > http://blogs.msdn.com/b/ntdebugging/archive/2006/12/18/understanding-poo > l-consumption-and-event-id_3a00_--2020-or-2019.aspx
Great! Thanks. > > MmSt > > So if we see MmSt as the top tag for instance consuming far and away the > largest amount, we can look at pooltag.txt and know that it's the memory > manager and also using that tag in a search engine query we might get > the more popular KB304101 which may resolve the issue! > > You can also use Ken's Article > http://www.adopenstatic.com/cs/blogs/ken/archive/2006/07/10/Using-PoolMo > n-_2800_Pool-Monitor_2900_-to-debug-kernel-memory-leaks.aspx > > findstr /l /m Sbap*.sys > > From this article it looks like Kaspersky AV filter which is the SBAP > Poolmon tag. > http://forum.kaspersky.com/lofiversion/index.php/t152765.html Does not surprise me. We've had a couple servers blue screen, and the memory dump pointed to KLIF.SYS in one of them. > Note that the SbAp module is occupying 165577272 bytes of nonpaged > memory. > Performing a string search inside the WINDIR\system32\drivers\ folder > shows that its the klif driver. My Kaspersky guy tells me that (for this specific system, at least) we are a bit behind on revision patches. I'll have him check the other ones we've seen go 2019 recently. Thanks! > > HTH > Z > > > Edward E. Ziots > CISSP, Network +, Security + > Network Engineer > Lifespan Organization > Email:ezi...@lifespan.org > Cell:401-639-3505 > > -----Original Message----- > From: Mike Leone [mailto:oozerd...@gmail.com] > Sent: Thursday, April 07, 2011 1:54 PM > To: NT System Admin Issues > Subject: Troubleshooting Event ID 2019, using memsnap > > Lately, we;ve had a number of systems exhibit event ID 2019, "server was > unable to allocate from the system non-paged pool because the pool was > empty". The system eventually becomes unresponsive, and I have to > reboot, to clear it. Something is causing a memory leak, but I'm having > trouble figuring out what. > > I ran "memsnap -p memsnp.txt", to capture kernel pool information. > Later, I went back and ran it again, and then did a "memsnap -a", to > analyze. And the lines with the biggest change are something with a tag > of "MmSt", with a change of ~2M bytes, and "SbAp" with a change of > almost 9M. > > But what am I to make of this info? Where do I look to figure out what > "MmSt: and "SbAp" are? And what program/process they belong to, so I can > track down the culprit? > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
