ExAllocatePoolWithTag always returns NULL.

Hi,

I am writing a WFP driver to monitor the network and for this purpose I am using various lists to store the packets.
A typical scenario is: Allocate memory from Non Paged Pool and add it to a list in the classify function, then read it from list, write to another list and delete the memory using ExFreePoolWithTag.
The coding is working fine for some time and then ExAllocatePoolWithTag always returns NULL indicating no Memory available :(, this happens very soon and I am not sure if there is some thing wrong with my code or Can i somehow increase the memory?

PS: My code is based on the inspect or msn monitor sample provided and they work fine.

Can someone please help me?

Thanks,
Ashwin Patti

Most likely you have a leak? Use tags and pollmon to track them.

Run !vm and see what the virtual memory picture is, you probably have a leak.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@gmail.com
Sent: October 29, 2010 2:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ExAllocatePoolWithTag always returns NULL.

Hi,

I am writing a WFP driver to monitor the network and for this purpose I am using various lists to store the packets.
A typical scenario is: Allocate memory from Non Paged Pool and add it to a list in the classify function, then read it from list, write to another list and delete the memory using ExFreePoolWithTag.
The coding is working fine for some time and then ExAllocatePoolWithTag always returns NULL indicating no Memory available :(, this happens very soon and I am not sure if there is some thing wrong with my code or Can i somehow increase the memory?

PS: My code is based on the inspect or msn monitor sample provided and they work fine.

Can someone please help me?

Thanks,
Ashwin Patti


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

for things that come and go you’re better off using lookaside lists. Eventually, ExAllocatePool can return NULL even if you don’t have a leak. See ExInitializeNPagedLookasideList for a starting point.

Lookaside lists are not magical either. They can return null too, just as likely to return null as exallocatepool.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@oracle.com
Sent: October 29, 2010 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ExAllocatePoolWithTag always returns NULL.

for things that come and go you’re better off using lookaside lists. Eventually, ExAllocatePool can return NULL even if you don’t have a leak. See ExInitializeNPagedLookasideList for a starting point.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

I didn’t realize that Doron - I mean - I realized they weren’t magical, but I didn’t realize that they are just as likely to return NULL.

There was a time when I had a network driver that would do a lot of dynamic alloc and free. In longevity tests, under load the driver would eventually assert that ExAllocatePool failed. I ‘fixed’ the problem by moving to lookaside lists. It was my understanding that there are times that the memory manager does some sort of rebalancing and a pool allocation could fail during that time, whereas a lookaside list tends to have memory already allocated to itself.

Please correct my misunderstandings if you would… I’d like to have that straight. What’s the point of lookaside lists then? Is it just that it’s more efficient when allocating small pieces?

xxxxx@oracle.com wrote:

Please correct my misunderstandings if you would… I’d like to have that straight. What’s the point of lookaside lists then? Is it just that it’s more efficient when allocating small pieces?

Think about it just a bit. If your lookaside list runs out of empty
chunks, then it will have to go allocate more memory. That can fail.

But, if you allocate 200 objects from your lookaside list, and that
succeeds, and from that point forward you never try to use more than 200
things at a time, then I would assert that ExAllocateFrom*LookasideList
should never fail.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim,

You assertion is incorrect since the lookaside list will free
elements on ExFreeTo*LookasideList, it keeps a certain number available
and the rest are freed using ExFreePool or the equivalent from the
initialization.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Tim Roberts” wrote in message news:xxxxx@ntdev:

> xxxxx@oracle.com wrote:
> > Please correct my misunderstandings if you would… I’d like to have that straight. What’s the point of lookaside lists then? Is it just that it’s more efficient when allocating small pieces?
>
> Think about it just a bit. If your lookaside list runs out of empty
> chunks, then it will have to go allocate more memory. That can fail.
>
> But, if you allocate 200 objects from your lookaside list, and that
> succeeds, and from that point forward you never try to use more than 200
> things at a time, then I would assert that ExAllocateFrom*LookasideList
> should never fail.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

Not answering for Doron of course.

The cost of allocating an idle entry from a look-aside list is very low - an
slist pop (a couple of instructions).

So for frequent alloc/dealoc cycles of fixed size blocks, the system
accumulates idle entries and makes the allocation and deallocation very
cheap.

Dave Cattley

I am having this issue only on my laptop (which is running 64bit Win7) whereas on my desktop (32bit Win7) machine it doesn’t give the no memory.

So I’m guessing its not the leak but more about having less memory.

I was wondering how the network monitoring tools work in such scenario? i mean they need to grab every packet rite?

Thanks,
ashwin patti

A lookaside list is not more effiecient than allocating small pieces b/c it allocats the same small pieces, where it is more efficient is that it caches these allocations and the cache lookup is less expensive than allocating the pool. When allocating from an empty lookaside, the lookaside still calls ExAllocatePool, so there is still a point of failure.

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@oracle.com
Sent: Friday, October 29, 2010 10:56 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ExAllocatePoolWithTag always returns NULL.

I didn’t realize that Doron - I mean - I realized they weren’t magical, but I didn’t realize that they are just as likely to return NULL.

There was a time when I had a network driver that would do a lot of dynamic alloc and free. In longevity tests, under load the driver would eventually assert that ExAllocatePool failed. I ‘fixed’ the problem by moving to lookaside lists. It was my understanding that there are times that the memory manager does some sort of rebalancing and a pool allocation could fail during that time, whereas a lookaside list tends to have memory already allocated to itself.

Please correct my misunderstandings if you would… I’d like to have that straight. What’s the point of lookaside lists then? Is it just that it’s more efficient when allocating small pieces?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

> But, if you allocate 200 objects from your lookaside list, and that succeeds, and from that point forward you never try to use more than 200 things at a time, then I would assert that ExAllocateFrom*LookasideList should never fail.

This is incorrect. The OS can scavenge the lookaside list when it is under memory pressure, that is why there is a public abstraction for allocation caches…so the OS knows about them and can trim them when it needs the memory

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, October 29, 2010 11:15 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ExAllocatePoolWithTag always returns NULL.

xxxxx@oracle.com wrote:

Please correct my misunderstandings if you would… I’d like to have that straight. What’s the point of lookaside lists then? Is it just that it’s more efficient when allocating small pieces?

Think about it just a bit. If your lookaside list runs out of empty chunks, then it will have to go allocate more memory. That can fail.

But, if you allocate 200 objects from your lookaside list, and that succeeds, and from that point forward you never try to use more than 200 things at a time, then I would assert that ExAllocateFrom*LookasideList should never fail.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi,

From the WinDbg tool, I have following when i give !VM. (this is when my driver code is not installed)

0: kd> !vm 1

*** Virtual Memory Usage ***
Physical Memory: 1032014 ( 4128056 Kb)
Page File: ??\C:\pagefile.sys
Current: 4128056 Kb Free Space: 3797872 Kb
Minimum: 4128056 Kb Maximum: 12384168 Kb
Unimplemented error for MiSystemVaTypeCount
Available Pages: 404829 ( 1619316 Kb)
ResAvail Pages: 899075 ( 3596300 Kb)
Locked IO Pages: 0 ( 0 Kb)
Free System PTEs: 33555663 ( 134222652 Kb)
Modified Pages: 16008 ( 64032 Kb)
Modified PF Pages: 16074 ( 64296 Kb)
NonPagedPool Usage: 196260345 ( 785041380 Kb)
NonPagedPoolNx Usage: 32584 ( 130336 Kb)
NonPagedPool Max: 762046 ( 3048184 Kb)
********** Excessive NonPaged Pool Usage *****
PagedPool 0 Usage: 40957 ( 163828 Kb)
PagedPool 1 Usage: 6391 ( 25564 Kb)
PagedPool 2 Usage: 2539 ( 10156 Kb)
PagedPool 3 Usage: 2446 ( 9784 Kb)
PagedPool 4 Usage: 2665 ( 10660 Kb)
PagedPool Usage: 54998 ( 219992 Kb)
PagedPool Maximum: 33554432 ( 134217728 Kb)
Session Commit: 14788 ( 59152 Kb)
Shared Commit: 83262 ( 333048 Kb)
Special Pool: 3674 ( 14696 Kb)
Shared Process: 15218 ( 60872 Kb)
PagedPool Commit: 55004 ( 220016 Kb)
Driver Commit: 11618 ( 46472 Kb)
Committed pages: 748073 ( 2992292 Kb)
Commit limit: 2064028 ( 8256112 Kb)

It mentions that there is an Excessive NonPaged Pool Usage! and its like that always so would any of the solution work in this case?

Thanks,
Ashwin Patti

xxxxx@gmail.com wrote:

Hi,

>From the WinDbg tool, I have following when i give !VM. (this is when my driver code is not installed)

0: kd> !vm 1

*** Virtual Memory Usage ***
NonPagedPool Usage: 196260345 ( 785041380 Kb)

It mentions that there is an Excessive NonPaged Pool Usage! and its like that always so would any of the solution work in this case?

The NonPaged pool usage is nonsense. 785GB? You can’t have more
non-paged pool than you have physical memory, and you only have 4GB of
physical memory. Some data structure has been damaged.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

This is a known bug in the !vm extension which will be fixed in the next debugger release. Per Pavel’s remarks on microsoft.public.windbg, the counts for NonPagedPoolNx are the real NP pool usage here.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, October 29, 2010 12:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ExAllocatePoolWithTag always returns NULL.

xxxxx@gmail.com wrote:

Hi,

>From the WinDbg tool, I have following when i give !VM. (this is when
>my driver code is not installed)

0: kd> !vm 1

*** Virtual Memory Usage ***
NonPagedPool Usage: 196260345 ( 785041380 Kb) …

It mentions that there is an Excessive NonPaged Pool Usage! and its like that always so would any of the solution work in this case?

The NonPaged pool usage is nonsense. 785GB? You can’t have more non-paged pool than you have physical memory, and you only have 4GB of physical memory. Some data structure has been damaged.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Ken,

Thanks for the information, that helped a lot.

Coming to my orginal problem, I have been using Driver Verifier Manager to check for my pool allocations and also I have been running DebugView to look at the DbgPrint messages when my driver is running.

I have noticed that on DbgGView I get many No Memory messages (i print these when ExAllocatePoolWithTag returns NULL) but the Pool allocations failed count to be 0 on the Driver Verifier Manager.
Also one more point to note is Lower Resources simulation is enabled on my machine for the driver and its count (Faults injected) is 3328.

My Question: Is this the reason for NULL return value from ExAllocatePoolWithTag? if not then why is Pool allocations failed is showing zero?

Sample values from the driver verifier Manger:

Global Counters:

Executions Synchronized : 0
Faults Injected : 3346
IRQL raises : 0
Pool allocations attempted: 12517715
Pool allocations failed: 0
Pool allocations not tracked: 12514942
Pool allocations succeeded: 12617514
Pool allocations succeeded in special pool: 12617514
Pool allocations without tag: 0
Spinlocks acquired: 106199
Trims: 687138

Counters Specifc to my driver:

Non paged pool - peak bytes allocated : 652064
Non paged pool - peak number of allocations : 568

Thanks
Ashwin Patti

Lookaside lists are not magical either. They can return null too, just as likely to return null as exallocatepool.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@oracle.com
Sent: October 29, 2010 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ExAllocatePoolWithTag always returns NULL.

for things that come and go you’re better off using lookaside lists. Eventually, ExAllocatePool can return NULL even if you don’t have a leak. See ExInitializeNPagedLookasideList for a starting point.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Actually, Doron, I’d say that they’re about equally likely to return NULL.
If the system runs out of memory, Mm will trim the working set, which will
reclaim any unused allocations from all the lookaside lists, in an effort to
free up as much memory as possible. Thus they’ll both return NULL.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.


“Doron Holan” wrote in message news:xxxxx@ntdev…

Lookaside lists are not magical either. They can return null too, just as
likely to return null as exallocatepool.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@oracle.com
Sent: October 29, 2010 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ExAllocatePoolWithTag always returns NULL.

for things that come and go you’re better off using lookaside lists.
Eventually, ExAllocatePool can return NULL even if you don’t have a leak.
See ExInitializeNPagedLookasideList for a starting point.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Agreed.

d

dent from a phpne with no keynoard

-----Original Message-----
From: Jake Oshins
Sent: October 30, 2010 3:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ExAllocatePoolWithTag always returns NULL.

Actually, Doron, I’d say that they’re about equally likely to return NULL.
If the system runs out of memory, Mm will trim the working set, which will
reclaim any unused allocations from all the lookaside lists, in an effort to
free up as much memory as possible. Thus they’ll both return NULL.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

--------------------------------------------------------------
“Doron Holan” wrote in message news:xxxxx@ntdev…

Lookaside lists are not magical either. They can return null too, just as
likely to return null as exallocatepool.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@oracle.com
Sent: October 29, 2010 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ExAllocatePoolWithTag always returns NULL.

for things that come and go you’re better off using lookaside lists.
Eventually, ExAllocatePool can return NULL even if you don’t have a leak.
See ExInitializeNPagedLookasideList for a starting point.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

… and the moral of the story is: Don’t use system lookaside lists. If you want a list of pre-allocated structures, ExAllocatePool a chunk of memory equal to the total size of the allocations you want, slice up that pool block into individual entry-size chunks, and queue those entries inside your driver for your own use.

Peter
OSR