Although I’m doing a mini-filter, I’m asking on NTDEV because I think this
question might be of interest to any kernel dev, not just FS jocks.
Apologies if I was wrong about that.
I have an FS Activity Monitor mini-filter that allows tracing boot, similar
in concept to Process Monitor’s boot trace capability. In order to be a
good citizen if the UM component never runs to drain the cached activity
records, I’m trying to use KeReadStateEvent() to test if
\KernelObjects\LowMemoryCondition is signaled in order to throttle my
memory allocation when the system is getting low on memory. However, on my
Windows 7 x64 text box, even when the system returns NULL from
ExAllocateFromNPagedLookasideList(), because *I* have (almost) all the
memory in the system, the KeReadStateEvent() call returns 0.
An aside: It’s pretty comical to see Resource Monitor’s Physical Memory
display bar graph all green in this condition. No Modified, no Standby, no
Free. Nothing but In Use.
As an alternative to the way I’ve done it, I could create a separate thread
to wait on this event and an exit event, and if this one is set, drop some
memory. But it was much simpler to just read the state before allocating
memory. Unless that doesn’t actually work .
Anyone know if this is supposed to work the way I’m attempting to use it?
Alternatively, does anyone know if it’s *not* supposed to work this way?
Another alternative: What is the best practice for caching as deeply as
possible while still allowing gracefully returning memory to the system when
the memory pressure is high? Has to work on XP and newer. I’d rather not
code it differently for OS versions, but I can if necessary.
Thanks,
Phil
Philip D. Barila (303) 776-1264
BTW, I think NETIO.sys has an unchecked allocation bug in it, because when I run the system out of memory, I get bugchecks with the same sequence at the top of the stack:
nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x12
nt!KeBugCheck2+0x71e
nt!KeBugCheckEx+0x104
nt!KiBugCheckDispatch+0x69
nt!KiPageFault+0x260
NETIO!StreamGetCalloutContext+0x115
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000168, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88001541755, address which referenced memory
Seems like that’s a NULL deref. Win 7 doesn’t seem to phone home crashes the same way XP did, or maybe it does, just less visibly. I hope the crash reports are showing up somewhere in Redmond.
ExAllocateFromNPagedLookasideList charges against nonpaged pool. You might
be depleting pool before hitting a “low memory condition”. On Win7 x64 the
NPP limit is 75% of availalable RAM while on older systems it is a very
scarce resource with a hard limit. Have you considered checking
\KernelObjects\LowNonPagedPoolCondition instead ?
//Daniel
“Philip D Barila” wrote in message news:xxxxx@ntdev…
> Although I’m doing a mini-filter, I’m asking on NTDEV because I think this
> question might be of interest to any kernel dev, not just FS jocks.
> Apologies if I was wrong about that.
>
>
>
> I have an FS Activity Monitor mini-filter that allows tracing boot,
> similar
> in concept to Process Monitor’s boot trace capability. In order to be a
> good citizen if the UM component never runs to drain the cached activity
> records, I’m trying to use KeReadStateEvent() to test if
> \KernelObjects\LowMemoryCondition is signaled in order to throttle my
> memory allocation when the system is getting low on memory. However, on
> my
> Windows 7 x64 text box, even when the system returns NULL from
> ExAllocateFromNPagedLookasideList(), because I have (almost) all the
> memory in the system, the KeReadStateEvent() call returns 0.
>
> An aside: It’s pretty comical to see Resource Monitor’s Physical Memory
> display bar graph all green in this condition. No Modified, no Standby,
> no
> Free. Nothing but In Use.
>
>
>
> As an alternative to the way I’ve done it, I could create a separate
> thread
> to wait on this event and an exit event, and if this one is set, drop some
> memory. But it was much simpler to just read the state before allocating
> memory. Unless that doesn’t actually work .
>
>
>
> Anyone know if this is supposed to work the way I’m attempting to use it?
> Alternatively, does anyone know if it’s not supposed to work this way?
>
>
>
> Another alternative: What is the best practice for caching as deeply as
> possible while still allowing gracefully returning memory to the system
> when
> the memory pressure is high? Has to work on XP and newer. I’d rather not
> code it differently for OS versions, but I can if necessary.
>
>
>
> Thanks,
>
>
>
> Phil
>
>
>
> Philip D. Barila (303) 776-1264
>
>
>
>
>
>
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-448231-
xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, April 05, 2011 6:09 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] \KernelObjects\LowMemoryCondition usage?
ExAllocateFromNPagedLookasideList charges against nonpaged pool. You
might
be depleting pool before hitting a “low memory condition”. On Win7 x64
the
NPP limit is 75% of availalable RAM while on older systems it is a
very
scarce resource with a hard limit. Have you considered checking
\KernelObjects\LowNonPagedPoolCondition instead ?
Actually, I have, and would have preferred to use that. It’s not documented
to exist in XP, and I don’t want to have to code against the OS version if I
don’t have to. I guess if I need to, I can just attempt to create
LowNonPagedPoolCondition, and if it doesn’t exist, create the
LowMemoryCondition. Oh wait, if I create an event with the name
L"\KernelObjects\LowNonPagedPoolCondtion", it’s probably going to create a
new event that only I am going to be using, so that’s probably not going to
work. I guess I can try it when I next get the chance.
Thanks,
Phil
Philip D. Barila (303) 776-1264