Aha, so you are saying that driver #1 deletes a lookaside list, then driver #2 deletes a completely separate lookaside list, but at that time the data structures are screwed up?
((sigh)) I think Iām going to stick with my startup slab allocator ā¦ get a big lump at boot when the system memory isnāt too fragmented, pin and lock the lump then slice it up and use it as needed ā¦ LookAsideLists appears to be like a Red Velvet cake, nice to look at but oh so much trouble when you start taking bites ā¦ 
1 Like
going to stick with my startup slab allocator
Thatās what we do.
Lookaside lists have their place. Use them if what you want is to keep the OS running with every driver having an even chance of accessing scarce resources. That might make sense for a general purpose driver on a general purpose server or workstation machine. But in a system with a dedicated, specific, function? Nope.
Itās a laudable and highly egalitarian goal: To each according to their need, and nobody gets to accumulate limited resources to the detriment of others.
The problem, of course, is that itās a fantasy. Every driver isnāt equally valued. Your disk driver or your file system are simply more valuable, and thus deserve more of the scarce resource, than your Bluetooth controller or your sound driver.
In the real world, in the 21st Century, where memory is cheap, the real answer is āDonāt make memory a scarce resource, and then this isnāt an issue.ā We thus avoid the entire debate. I put 96GB of memory on a test machine recently. ECC memory at thatā¦
Peter
1 Like
So what I see in dump is,
when another driver tries to delete its looksasidelist node in the system wide lookaside list using ExDeleteNPagedLookasideList it tries to check its Flink and Blink entry. when we dump Flink , it has 0 values as seen below.
what does this 0 value mean in its flink and blink entries in systemwide lookasidelist?
kd> dx -id 0,0,ffffd4869ed98200 -r1 ((nt!_LIST_ENTRY *)0xffffd4869e90a860)
((xxxxx!_LIST_ENTRY *)0xffffd4869e90a860) : 0xffffd4869e90a860 [Type: _LIST_ENTRY *]
[+0x000] Flink : 0x0 [Type: _LIST_ENTRY *]
[+0x008] Blink : 0x0 [Type: _LIST_ENTRY *]
Does this mean whoever linked it before didnāt call ExDeleteNPagedLookasideList to remove the entries from the systemwide list.
I see this in my dump
(_LIST_ENTRY*) 0xffffc1048dda68e0 : 0xffffc1048dda68e0 [Type: _LIST_ENTRY *]
[+0x000] Flink : 0xffffc1048fc40640 [Type: _LIST_ENTRY *]
[+0x008] Blink : 0xffffc1048dda6860 [Type: _LIST_ENTRY *]
Here 0xffffc1048dda68e0 is the list entry created by my driver.
After some time I see 0 in the same address.
(_LIST_ENTRY*) 0xffffc1048dda68e0 : 0xffffc1048dda68e0 [Type: _LIST_ENTRY *]
[+0x000] Flink : 0x0 [Type: _LIST_ENTRY *]
[+0x008] Blink : 0x0 [Type: _LIST_ENTRY *]
call stack says the below when a memory access breakpoint is put.
I believe this flink and blink pointers donāt point the memory location allocated by the driver thru Exallocatefromlookasidelist. It points the next node and previous node in that system wide lookaside list. Source of this corruption is because of the below calls
00 nt!memset
01 nt!IopXxxControlFile
02 nt!NtDeviceIoControlFile
03 nt!KiSystemServiceCopyEnd
04 ntdll
Any pointers?
These days, a much more important consideration than the scarcity of memory is its locality. On a system with 1 or 10 TB of RAM not all of it is equal from the point of view of the core that your thread happens to be executing on