BugCheck c4 - Deleting uninitialized lookaside list.

Hello,

After reading through all the info available on this, I can’t tell why this is happening. In the driver we have a lookAsideList for our event queue, we use the non paged version of the function:

ExInitializeNPagedLookasideList

Then we call ExAllocateFromNPagedLookasideList to allocate, we got valid addresses.

After using that memory we called ExFreeToNPagedLookasideList to free the allocated.

Then finally call ExDeleteNPagedLookasideList. With the verifier enabled we get the

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

Arguments:
Arg1: 00000000000000cb, Deleting uninitialized lookaside list.
Arg2: ffff900fc84f9520, Lookaside list address.
Arg3: 0000000000000000
Arg4: 0000000000000000

Analyzing the dump I don’t see what could be the problem, the list was initialized:

It doesn’t look like it’s corrupted and I can’t find much info on this error: Deleting uninitialized lookaside list.

Clearly it was initialized and used. Any clue on how to follow. The number of total allocates matches the number of total frees.

Thanks in advance, I am out of ideas.

Is it possible you are deleting the list twice?

@Tim_Roberts said:
Is it possible you are deleting the list twice?

Hi Tim,

I don’t think so, we are setting to NULL the pointer after calling ExDeleteNPagedLookasideList, so next time it won’t do it again, as we just call the function if the pointer is not NULL.

If it were me, I suppose my next step would be to trace backwards into the routine that triggered the bugcheck and figure out which field it didn’t like. The structure looks normal to me, too.

That is not a guarantee that a race condition is not causing you to try
freeing it again, if that code could be ran twice. Unless you are using
atomic Exchange to NULL the value for othera before freeing it.

@Tim_Roberts said:
If it were me, I suppose my next step would be to trace backwards into the routine that triggered the bugcheck and figure out which field it didn’t like. The structure looks normal to me, too.

Yes, I wish Microsoft would offer more specific info about this bugcheck. I moved to use the Ex functions, suggested by the documentation, but still the same.

@Dejan_Maksimovic said:
That is not a guarantee that a race condition is not causing you to try
freeing it again, if that code could be ran twice. Unless you are using
atomic Exchange to NULL the value for othera before freeing it.

This is happening on the shutdown flow, is just one thread doing this, so we are pretty sure is not an issue with concurrency. Not sure what to do now.

Walk into the code (single step in the debugger). Set a breakpoint on the tear-down routine.

IIRC (and it’s been years since I’ve looked at the source code for this)… Verifier makes some sort of list entry when you initialize the lookaside list and removes that entry when you tear-down the lookaside list. But, walking into the code should make this clear.

I’m sorry, but that’s almost certainly the only way you’re going to solve this.

Peter