ExFreeToNPagedLookasideList giving BSOD

Hi All,
the ExFreeToNPagedLookasideList is driving me crazy. I have writtem a
volume filter driver in which I am using lookaside list for allocating
structure objects which nedds to be passed to the worker routines. The
problem arise when I try to free the memory allocated by
ExAllocateFromNPagedLookasideList. I tried to free the allocated memory by
passing my own function to lookaside list initialise function as a function
to free the allocations. But whenever I go to free the memory using
ExFreePool the bug check 0xA occurs. Same is the case if I don't pass the
free function to the initialize call, ExFreeToNPagedLookasideList gives the
same BSOD. Can anybody tell me what nt!ExpCheckForResource function does?
Every time I get the bug check the stack trace shows that the same function
on top of stack.
I checked that the memory I am passing to ExFreePool is the same that I
have allocated using ExAllocateFromNPagedLookasideList. Even I debugged
thruogh the code for ExFreeToNPagedLookasideList, the passed pointer is same
which is received from allocation.

The dump shows that the bug check is due to access to NULL memory at IRQL
2. But I am executing the code in the worker routine and the irql is Passive
during call to ExFreeToNPagedLookasideList. The bug check is always
reproducible if I do some Local disk manager operations like creat new
partitions or delete existing if no Disk Manager operations are carried out
the code works fine.

Is this due to Verifier. I have enable all the verifier option except low
resource simulation. Without verifier the bug check is not reproduced.

Can anybody help me in this.

============================
//Global varible for lookaside list
NPAGED_LOOKASIDE_LIST __CjVFWORKQCONTEXTLookAside

// CODE for initializing look aside list in another function
ExInitializeNPagedLookasideList(&__CjVFWORKQCONTEXTLookAside,
NULL,
__CjFree,//NULL,
0,
sizeof(CjVFWORKQCONTEXT),
'QWjC',
0);

=============================
//code for freeing the lookaside list allocation in worker routine

ExFreeToNPagedLookasideList(&__CjVFWORKQCONTEXTLookAside,pCjVFWorkQContext);

//Free function
VOID
__CjFree (
PVOID Buffer
)
{
ASSERT(Buffer);
if(DISPATCH_LEVEL>KeGetCurrentIrql())
ExFreePool(Buffer);
}

=============================

Following is the dump.

kd> !analyze -v
The call to LoadLibrary(kext) failed, Win32 error 193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
ERROR: FindPlugIns 8007007b
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8088d613, address which referenced memory

Debugging Details:

The call to LoadLibrary(kext) failed, Win32 error 193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kext) failed, Win32 error 193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kext) failed, Win32 error 193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.

READ_ADDRESS: The call to LoadLibrary(kext) failed, Win32 error 193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
00000000

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExpCheckForResource+64
8088d613 8b36 mov esi,[esi]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80874ad9 to 8081d97e

STACK_TEXT:
fa056870 80874ad9 00000003 00000000 00000000
nt!RtlpBreakWithStatusInstruction
fa0568bc 808758f6 00000003 00000000 8088d613 nt!KiBugCheckDebugBreak+0x19
fa056c54 80826493 0000000a 00000000 00000002 nt!KeBugCheck2+0x5b2
fa056c54 8088d613 0000000a 00000000 00000002 nt!KiTrap0E+0x2a1
fa056d08 809dfdf9 ffb7f050 00000028 81822db0 nt!ExpCheckForResource+0x64
fa056d24 809cd0eb 00000000 fa056d44 f9a9312b nt!ExFreePoolSanityChecks+0x161
fa056d30 f9a9312b ffb7f058 00000000 00000001
nt!VerifierExFreePoolWithTag+0x1c
fa056d44 f9a9188d ffb7f058 fa056d6c f9a91840 BexWinCj!__CjFree+0x4b
[f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
fa056d50 f9a91840 f9a97060 ffb7f058 00000000
BexWinCj!ExFreeToNPagedLookasideList+0x3d
[d:\winddk\3790\inc\ifs\wnet\ntifs.h @ 19690]
fa056d6c 8092393d 817bd480 ffb7f058 808b0560
BexWinCj!__CjVFLogChangesWorkerRoutine+0x100
[f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 920]
fa056d80 808203bd 813b9618 00000000 81822db0 nt!IopProcessWorkItem+0x13
fa056dac 80905d2c 813b9618 00000000 00000000 nt!ExpWorkerThread+0xeb
fa056ddc 80828499 80820300 00000000 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
BexWinCj!__CjFree+4b
[f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
f9a9312b 8be5 mov esp,ebp

FAULTING_SOURCE_CODE:
1535: {
1536: ASSERT(Buffer);
1537: if(DISPATCH_LEVEL>KeGetCurrentIrql())
1538: ExFreePool(Buffer);

1539: }
1540:
1541:
1542:
1543:
1544:

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: BexWinCj!__CjFree+4b

MODULE_NAME: BexWinCj

IMAGE_NAME: BexWinCj.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4550a4a8

FAILURE_BUCKET_ID: 0xA_VRF_BexWinCj!__CjFree+4b

BUCKET_ID: 0xA_VRF_BexWinCj!__CjFree+4b

Followup: MachineOwner

kd> kv
ChildEBP RetAddr Args to Child
fa056870 80874ad9 00000003 00000000 00000000
nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
fa0568bc 808758f6 00000003 00000000 8088d613 nt!KiBugCheckDebugBreak+0x19
(FPO: [Non-Fpo])
fa056c54 80826493 0000000a 00000000 00000002 nt!KeBugCheck2+0x5b2 (FPO:
[Non-Fpo])
fa056c54 8088d613 0000000a 00000000 00000002 nt!KiTrap0E+0x2a1 (FPO: [0,0]
TrapFrame @ fa056c74)
fa056d08 809dfdf9 ffb7f050 00000028 81822db0 nt!ExpCheckForResource+0x64
(FPO: [Non-Fpo])
fa056d24 809cd0eb 00000000 fa056d44 f9a9312b nt!ExFreePoolSanityChecks+0x161
(FPO: [Non-Fpo])
fa056d30 f9a9312b ffb7f058 00000000 00000001
nt!VerifierExFreePoolWithTag+0x1c (FPO: [Non-Fpo])
fa056d44 f9a9188d ffb7f058 fa056d6c f9a91840 BexWinCj!__CjFree+0x4b (FPO:
[Non-Fpo]) (CONV: stdcall)
[f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
fa056d50 f9a91840 f9a97060 ffb7f058 00000000
BexWinCj!ExFreeToNPagedLookasideList+0x3d (FPO: [Non-Fpo]) (CONV: stdcall)
[d:\winddk\3790\inc\ifs\wnet\ntifs.h @ 19690]
fa056d6c 8092393d 817bd480 ffb7f058 808b0560
BexWinCj!__CjVFLogChangesWorkerRoutine+0x100 (FPO: [Non-Fpo]) (CONV:
stdcall) [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @
920]
fa056d80 808203bd 813b9618 00000000 81822db0 nt!IopProcessWorkItem+0x13
(FPO: [Non-Fpo])
fa056dac 80905d2c 813b9618 00000000 00000000 nt!ExpWorkerThread+0xeb (FPO:
[Non-Fpo])
fa056ddc 80828499 80820300 00000000 00000000 nt!PspSystemThreadStartup+0x2e
(FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
kd> .trap fa056c74
ErrCode = 00000000
eax=808b1b50 ebx=00000028 ecx=ffa5faf8 edx=fa056cf4 esi=00000000
edi=ffb7f050
eip=8088d613 esp=fa056ce8 ebp=fa056d08 iopl=0 nv up ei pl nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010203
nt!ExpCheckForResource+0x64:
8088d613 8b36 mov esi,[esi]
ds:0023:00000000=????????

Thanks,
Girish.

ExpCheckForResource checks for a ERESOURCE in the memory being freed, the
most likely problem here is that something in the system (probably your
driver) has corrupted the system resource list.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Giri” wrote in message news:xxxxx@ntdev…
> Hi All,
> the ExFreeToNPagedLookasideList is driving me crazy. I have writtem a
> volume filter driver in which I am using lookaside list for allocating
> structure objects which nedds to be passed to the worker routines. The
> problem arise when I try to free the memory allocated by
> ExAllocateFromNPagedLookasideList. I tried to free the allocated memory
> by
> passing my own function to lookaside list initialise function as a
> function
> to free the allocations. But whenever I go to free the memory using
> ExFreePool the bug check 0xA occurs. Same is the case if I don’t pass the
> free function to the initialize call, ExFreeToNPagedLookasideList gives
> the
> same BSOD. Can anybody tell me what nt!ExpCheckForResource function does?
> Every time I get the bug check the stack trace shows that the same
> function
> on top of stack.
> I checked that the memory I am passing to ExFreePool is the same that I
> have allocated using ExAllocateFromNPagedLookasideList. Even I debugged
> thruogh the code for ExFreeToNPagedLookasideList, the passed pointer is
> same
> which is received from allocation.
>
> The dump shows that the bug check is due to access to NULL memory at IRQL
> 2. But I am executing the code in the worker routine and the irql is
> Passive
> during call to ExFreeToNPagedLookasideList. The bug check is always
> reproducible if I do some Local disk manager operations like creat new
> partitions or delete existing if no Disk Manager operations are carried
> out
> the code works fine.
>
> Is this due to Verifier. I have enable all the verifier option except low
> resource simulation. Without verifier the bug check is not reproduced.
>
> Can anybody help me in this.
>
> ============================
> //Global varible for lookaside list
> NPAGED_LOOKASIDE_LIST __CjVFWORKQCONTEXTLookAside
> ============================
> // CODE for initializing look aside list in another function
> ExInitializeNPagedLookasideList(&__CjVFWORKQCONTEXTLookAside,
> NULL,
> __CjFree,//NULL,
> 0,
> sizeof(CjVFWORKQCONTEXT),
> ‘QWjC’,
> 0);
>
> =============================
> //code for freeing the lookaside list allocation in worker routine
>
> ExFreeToNPagedLookasideList(&__CjVFWORKQCONTEXTLookAside,pCjVFWorkQContext);
> =============================
> //Free function
> VOID
> __CjFree (
> PVOID Buffer
> )
> {
> ASSERT(Buffer);
> if(DISPATCH_LEVEL>KeGetCurrentIrql())
> ExFreePool(Buffer);
> }
>
> =============================
>
>
> Following is the dump.
>
> kd> !analyze -v
> The call to LoadLibrary(kext) failed, Win32 error 193
> “%1 is not a valid Win32 application.”
> Please check your debugger configuration and/or network access.
> ERROR: FindPlugIns 8007007b
> *****
>
>
> * Bugcheck
> Analysis
>
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> 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 a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 8088d613, address which referenced memory
>
> Debugging Details:
> ------------------
>
> The call to LoadLibrary(kext) failed, Win32 error 193
> “%1 is not a valid Win32 application.”
> Please check your debugger configuration and/or network access.
> The call to LoadLibrary(kext) failed, Win32 error 193
> “%1 is not a valid Win32 application.”
> Please check your debugger configuration and/or network access.
> The call to LoadLibrary(kext) failed, Win32 error 193
> “%1 is not a valid Win32 application.”
> Please check your debugger configuration and/or network access.
>
> READ_ADDRESS: The call to LoadLibrary(kext) failed, Win32 error 193
> “%1 is not a valid Win32 application.”
> Please check your debugger configuration and/or network access.
> 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!ExpCheckForResource+64
> 8088d613 8b36 mov esi,[esi]
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0xA
>
> LAST_CONTROL_TRANSFER: from 80874ad9 to 8081d97e
>
> STACK_TEXT:
> fa056870 80874ad9 00000003 00000000 00000000
> nt!RtlpBreakWithStatusInstruction
> fa0568bc 808758f6 00000003 00000000 8088d613 nt!KiBugCheckDebugBreak+0x19
> fa056c54 80826493 0000000a 00000000 00000002 nt!KeBugCheck2+0x5b2
> fa056c54 8088d613 0000000a 00000000 00000002 nt!KiTrap0E+0x2a1
> fa056d08 809dfdf9 ffb7f050 00000028 81822db0 nt!ExpCheckForResource+0x64
> fa056d24 809cd0eb 00000000 fa056d44 f9a9312b
> nt!ExFreePoolSanityChecks+0x161
> fa056d30 f9a9312b ffb7f058 00000000 00000001
> nt!VerifierExFreePoolWithTag+0x1c
> fa056d44 f9a9188d ffb7f058 fa056d6c f9a91840 BexWinCj!__CjFree+0x4b
> [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
> fa056d50 f9a91840 f9a97060 ffb7f058 00000000
> BexWinCj!ExFreeToNPagedLookasideList+0x3d
> [d:\winddk\3790\inc\ifs\wnet\ntifs.h @ 19690]
> fa056d6c 8092393d 817bd480 ffb7f058 808b0560
> BexWinCj!__CjVFLogChangesWorkerRoutine+0x100
> [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 920]
> fa056d80 808203bd 813b9618 00000000 81822db0 nt!IopProcessWorkItem+0x13
> fa056dac 80905d2c 813b9618 00000000 00000000 nt!ExpWorkerThread+0xeb
> fa056ddc 80828499 80820300 00000000 00000000
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> BexWinCj!__CjFree+4b
> [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
> f9a9312b 8be5 mov esp,ebp
>
> FAULTING_SOURCE_CODE:
> 1535: {
> 1536: ASSERT(Buffer);
> 1537: if(DISPATCH_LEVEL>KeGetCurrentIrql())
> 1538: ExFreePool(Buffer);
>> 1539: }
> 1540:
> 1541:
> 1542:
> 1543:
> 1544:
>
>
> SYMBOL_STACK_INDEX: 7
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: BexWinCj! CjFree+4b
>
> MODULE_NAME: BexWinCj
>
> IMAGE_NAME: BexWinCj.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4550a4a8
>
> FAILURE_BUCKET_ID: 0xA_VRF_BexWinCj!
CjFree+4b
>
> BUCKET_ID: 0xA_VRF_BexWinCj!__CjFree+4b
>
> Followup: MachineOwner
> ---------
>
> kd> kv
> ChildEBP RetAddr Args to Child
> fa056870 80874ad9 00000003 00000000 00000000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> fa0568bc 808758f6 00000003 00000000 8088d613 nt!KiBugCheckDebugBreak+0x19
> (FPO: [Non-Fpo])
> fa056c54 80826493 0000000a 00000000 00000002 nt!KeBugCheck2+0x5b2 (FPO:
> [Non-Fpo])
> fa056c54 8088d613 0000000a 00000000 00000002 nt!KiTrap0E+0x2a1 (FPO:
> [0,0]
> TrapFrame @ fa056c74)
> fa056d08 809dfdf9 ffb7f050 00000028 81822db0 nt!ExpCheckForResource+0x64
> (FPO: [Non-Fpo])
> fa056d24 809cd0eb 00000000 fa056d44 f9a9312b
> nt!ExFreePoolSanityChecks+0x161
> (FPO: [Non-Fpo])
> fa056d30 f9a9312b ffb7f058 00000000 00000001
> nt!VerifierExFreePoolWithTag+0x1c (FPO: [Non-Fpo])
> fa056d44 f9a9188d ffb7f058 fa056d6c f9a91840 BexWinCj!__CjFree+0x4b (FPO:
> [Non-Fpo]) (CONV: stdcall)
> [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @ 1539]
> fa056d50 f9a91840 f9a97060 ffb7f058 00000000
> BexWinCj!ExFreeToNPagedLookasideList+0x3d (FPO: [Non-Fpo]) (CONV:
> stdcall)
> [d:\winddk\3790\inc\ifs\wnet\ntifs.h @ 19690]
> fa056d6c 8092393d 817bd480 ffb7f058 808b0560
> BexWinCj!__CjVFLogChangesWorkerRoutine+0x100 (FPO: [Non-Fpo]) (CONV:
> stdcall) [f:\drop\sources\winchangejournal\journaldriver\cjvolfilter.c @
> 920]
> fa056d80 808203bd 813b9618 00000000 81822db0 nt!IopProcessWorkItem+0x13
> (FPO: [Non-Fpo])
> fa056dac 80905d2c 813b9618 00000000 00000000 nt!ExpWorkerThread+0xeb
> (FPO:
> [Non-Fpo])
> fa056ddc 80828499 80820300 00000000 00000000
> nt!PspSystemThreadStartup+0x2e
> (FPO: [Non-Fpo])
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> kd> .trap fa056c74
> ErrCode = 00000000
> eax=808b1b50 ebx=00000028 ecx=ffa5faf8 edx=fa056cf4 esi=00000000
> edi=ffb7f050
> eip=8088d613 esp=fa056ce8 ebp=fa056d08 iopl=0 nv up ei pl nz na
> pe
> cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010203
> nt!ExpCheckForResource+0x64:
> 8088d613 8b36 mov esi,[esi]
> ds:0023:00000000=???
>
>
>
>
> Thanks,
> Girish.
>

“Don Burn” wrote:

> ExpCheckForResource checks for a ERESOURCE in the memory being freed, the
> most likely problem here is that something in the system (probably your
> driver) has corrupted the system resource list.

Or is simply paged out? Is the fact that this is occurring at
dispatch level perhaps the unexpected part.

Alan Adams

Giri wrote:

Can anybody help me in this.

============================
//Global varible for lookaside list
NPAGED_LOOKASIDE_LIST __CjVFWORKQCONTEXTLookAside

// CODE for initializing look aside list in another function
ExInitializeNPagedLookasideList(&__CjVFWORKQCONTEXTLookAside,
NULL,
__CjFree,//NULL,
0,
sizeof(CjVFWORKQCONTEXT),
‘QWjC’,
0);

It’s not related to your current problem, but you should not use
identifiers that begin with two underscores. Such identifiers are
specifically reserved for use by the compiler in the ISO C and C++
standards.


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

“Alan Adams” wrote in message news:xxxxx@ntdev…
> “Don Burn” wrote:
>
>> ExpCheckForResource checks for a ERESOURCE in the memory being freed,
>> the
>> most likely problem here is that something in the system (probably your
>> driver) has corrupted the system resource list.
>
> Or is simply paged out? Is the fact that this is occurring at
> dispatch level perhaps the unexpected part.
>

No, the list is designed to checked while holding a spinlock and the
pointer is NULL, so somebody stepped on some memory they should not have.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

Alan Adams wrote:

“Don Burn” wrote:
>
>> ExpCheckForResource checks for a ERESOURCE in the memory being freed, the
>> most likely problem here is that something in the system (probably your
>> driver) has corrupted the system resource list.
>>
>
> Or is simply paged out? Is the fact that this is occurring at
> dispatch level perhaps the unexpected part.
>

Not with an address of 0. That’s invalid no matter WHAT the IRQL.


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

Tim Roberts wrote:

> > Or is simply paged out? Is the fact that this is occurring at
> > dispatch level perhaps the unexpected part.
>
> Not with an address of 0. That’s invalid no matter WHAT the IRQL.

Thanks. Hurriedly mis-read EIP as the address being referenced, and
it was a lightening-quick ride downhill from there…

Alan Adams

Hi Tim,
the addres that I pass to the ExFreePool or ExFreeToNPagedLookasideList
is not NULL. The memory even don’t caontain any ERESORUCE. SO can anybody
tell me why the bug check states that the address refernced is NULL & it
contains the ERESOURCE wich is yet not deleted. How can it be possible thet
the NULL pointer contais ERESOURCE? Can anybody tell me how to find the
ERESOURCE address for which ExpCheckForResource is giving me bug check?

On 11/7/06, Alan Adams wrote:
>
> Tim Roberts wrote:
>
> > > Or is simply paged out? Is the fact that this is occurring at
> > > dispatch level perhaps the unexpected part.
> >
> > Not with an address of 0. That’s invalid no matter WHAT the IRQL.
>
> Thanks. Hurriedly mis-read EIP as the address being referenced, and
> it was a lightening-quick ride downhill from there…
>
> Alan Adams
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

“Giri” wrote in message news:xxxxx@ntdev…
> the addres that I pass to the ExFreePool or
> ExFreeToNPagedLookasideList
> is not NULL. The memory even don’t caontain any ERESORUCE. SO can anybody
> tell me why the bug check states that the address refernced is NULL & it
> contains the ERESOURCE wich is yet not deleted. How can it be possible
> thet
> the NULL pointer contais ERESOURCE? Can anybody tell me how to find the
> ERESOURCE address for which ExpCheckForResource is giving me bug check?

The reported bug does not have anything to do directly with the current
call to free memory. At some point your driver zeroed some memory, could
have been another piece you allocated that did have an ERESOURCE or else it
could be you have an invalid pointer, and it turns out there was an
ERESOURCE there. Basically you left a timebomb that the freeing of memory
is now detecting and reporting.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

Hi Don,
is that possible? If I have zeroed the memory or freed which may contain
the ERESOURCE, then why not verifier gives the bug check at that point? The
problem is reproducible if I do some partition deletion or addition
operation. On such calls I have code which adds or delets the volume
information to my list of the structures. This structure contains the
ERESOURCE but I checked it, no where it contains code to delete the memory
whith reseting the all its contains.
I’ll check it again.
Can you please tell me why the Irql is raise to dispatch, because the
bug check states that the irql at time og bug check was 2 and the memory
refernced was NULL. I am not getting why this is happening, if I have
somewhere the code which deleted memory containing ERESOURCE then this
should not have happended instead it should state that I am releasing the
memory containing ERESOURCE. I am getting bug check 0xA.

Thanks,
Giri.

On 11/8/06, Don Burn wrote:
>
>
> “Giri” wrote in message news:xxxxx@ntdev…
> > the addres that I pass to the ExFreePool or
> > ExFreeToNPagedLookasideList
> > is not NULL. The memory even don’t caontain any ERESORUCE. SO can
> anybody
> > tell me why the bug check states that the address refernced is NULL & it
> > contains the ERESOURCE wich is yet not deleted. How can it be possible
> > thet
> > the NULL pointer contais ERESOURCE? Can anybody tell me how to find the
> > ERESOURCE address for which ExpCheckForResource is giving me bug check?
>
> The reported bug does not have anything to do directly with the current
> call to free memory. At some point your driver zeroed some memory, could
> have been another piece you allocated that did have an ERESOURCE or else
> it
> could be you have an invalid pointer, and it turns out there was an
> ERESOURCE there. Basically you left a timebomb that the freeing of memory
> is now detecting and reporting.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

The ExpCheckForResource routine walks a list of ERESOURCE structures while
holding a spinlock. So the IRQL is 2 since the lock is held, and the
memory was zeroed by someone since the reference was NULL.

The verifier doesn’t catch this when it happens since memset and its
wrappers such as RtlZeroMemory are intrinsic functions that lay down inline
code. Even if that was monitored you can have your own code store a zero,
you could by accident use the pointer in an initialization call that zeros
memory or similar mistake.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Giri” wrote in message news:xxxxx@ntdev…
> Hi Don,
> is that possible? If I have zeroed the memory or freed which may
> contain
> the ERESOURCE, then why not verifier gives the bug check at that point?
> The
> problem is reproducible if I do some partition deletion or addition
> operation. On such calls I have code which adds or delets the volume
> information to my list of the structures. This structure contains the
> ERESOURCE but I checked it, no where it contains code to delete the
> memory
> whith reseting the all its contains.
> I’ll check it again.
> Can you please tell me why the Irql is raise to dispatch, because the
> bug check states that the irql at time og bug check was 2 and the memory
> refernced was NULL. I am not getting why this is happening, if I have
> somewhere the code which deleted memory containing ERESOURCE then this
> should not have happended instead it should state that I am releasing the
> memory containing ERESOURCE. I am getting bug check 0xA.
>
> Thanks,
> Giri.
>
> On 11/8/06, Don Burn wrote:
>>
>>
>> “Giri” wrote in message news:xxxxx@ntdev…
>> > the addres that I pass to the ExFreePool or
>> > ExFreeToNPagedLookasideList
>> > is not NULL. The memory even don’t caontain any ERESORUCE. SO can
>> anybody
>> > tell me why the bug check states that the address refernced is NULL &
>> > it
>> > contains the ERESOURCE wich is yet not deleted. How can it be possible
>> > thet
>> > the NULL pointer contais ERESOURCE? Can anybody tell me how to find
>> > the
>> > ERESOURCE address for which ExpCheckForResource is giving me bug
>> > check?
>>
>> The reported bug does not have anything to do directly with the current
>> call to free memory. At some point your driver zeroed some memory,
>> could
>> have been another piece you allocated that did have an ERESOURCE or else
>> it
>> could be you have an invalid pointer, and it turns out there was an
>> ERESOURCE there. Basically you left a timebomb that the freeing of
>> memory
>> is now detecting and reporting.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>

Thanks Don,
I found the bug. Our device extension is stroing one ERESOURCE
and in the remove_device routine the ExDeleteResourceL was not called. This
solved the problem.
Thanks once again for your help.

Regards,
Giri.

On 11/8/06, Don Burn wrote:
>
> The ExpCheckForResource routine walks a list of ERESOURCE structures while
> holding a spinlock. So the IRQL is 2 since the lock is held, and the
> memory was zeroed by someone since the reference was NULL.
>
> The verifier doesn’t catch this when it happens since memset and its
> wrappers such as RtlZeroMemory are intrinsic functions that lay down
> inline
> code. Even if that was monitored you can have your own code store a zero,
> you could by accident use the pointer in an initialization call that zeros
> memory or similar mistake.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “Giri” wrote in message news:xxxxx@ntdev…
> > Hi Don,
> > is that possible? If I have zeroed the memory or freed which may
> > contain
> > the ERESOURCE, then why not verifier gives the bug check at that point?
> > The
> > problem is reproducible if I do some partition deletion or addition
> > operation. On such calls I have code which adds or delets the volume
> > information to my list of the structures. This structure contains the
> > ERESOURCE but I checked it, no where it contains code to delete the
> > memory
> > whith reseting the all its contains.
> > I’ll check it again.
> > Can you please tell me why the Irql is raise to dispatch, because the
> > bug check states that the irql at time og bug check was 2 and the memory
> > refernced was NULL. I am not getting why this is happening, if I have
> > somewhere the code which deleted memory containing ERESOURCE then this
> > should not have happended instead it should state that I am releasing
> the
> > memory containing ERESOURCE. I am getting bug check 0xA.
> >
> > Thanks,
> > Giri.
> >
> > On 11/8/06, Don Burn wrote:
> >>
> >>
> >> “Giri” wrote in message news:xxxxx@ntdev…
> >> > the addres that I pass to the ExFreePool or
> >> > ExFreeToNPagedLookasideList
> >> > is not NULL. The memory even don’t caontain any ERESORUCE. SO can
> >> anybody
> >> > tell me why the bug check states that the address refernced is NULL &
> >> > it
> >> > contains the ERESOURCE wich is yet not deleted. How can it be
> possible
> >> > thet
> >> > the NULL pointer contais ERESOURCE? Can anybody tell me how to find
> >> > the
> >> > ERESOURCE address for which ExpCheckForResource is giving me bug
> >> > check?
> >>
> >> The reported bug does not have anything to do directly with the current
> >> call to free memory. At some point your driver zeroed some memory,
> >> could
> >> have been another piece you allocated that did have an ERESOURCE or
> else
> >> it
> >> could be you have an invalid pointer, and it turns out there was an
> >> ERESOURCE there. Basically you left a timebomb that the freeing of
> >> memory
> >> is now detecting and reporting.
> >>
> >>
> >> –
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> http://www.windrvr.com
> >> Remove StopSpam from the email to reply
> >>
> >>
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Giri wrote:

Hi Tim,
the addres that I pass to the ExFreePool or
ExFreeToNPagedLookasideList is not NULL. The memory even don’t
caontain any ERESORUCE. SO can anybody tell me why the bug check
states that the address refernced is NULL & it contains the ERESOURCE
wich is yet not deleted. How can it be possible thet the NULL pointer
contais ERESOURCE? Can anybody tell me how to find the ERESOURCE
address for which ExpCheckForResource is giving me bug check?

What this probably means is that you are overwriting the end of a buffer
somewhere, writing zeros into the linkage words in the pool. I’ve
forgotten the original specs; have you tried running this with the
driver verifier on?


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