DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi All,
When I developed netvmini,I have a question.I user a kernel thread to recv data from the Physical Network equipment,then Call the NdisMIndicateReceivePacket function to Submitted to the windows network protocol layer.
after calling NdisMIndicateReceivePacket function,Produce DRIVER_IRQL_NOT_LESS_OR_EQUAL exception!
the codes are the fllows(the test function is called in a kernel thread in loop):

VOID test(IN PVOID FunctionContext, PUCHAR buffer)
{
PMP_ADAPTER Adapter = (PMP_ADAPTER)FunctionContext;
UINT BytesToCopy = 0;
PUINT32 recvLength = NULL;
PUCHAR recvBase = NULL;

recvLength = (PUINT32)buffer;

if ((*recvLength == 0) || (*recvLength > ETH_MAX_PACKET_SIZE))
{
return;
}

recvBase = (PUCHAR)(buffer + 4);
BytesToCopy = *recvLength;

//
// Increment the ref count on the adapter to prevent the driver from
// unloding while the DPC is running. The Halt handler waits for the
// ref count to drop to zero before returning.
//
//MP_INC_REF(Adapter);

NdisMoveMemory(
rx_bufs,
recvBase,
BytesToCopy);

NdisAdjustBufferLength(
buf_desc,
BytesToCopy);

NDIS_SET_PACKET_STATUS(pkt_desc, NDIS_STATUS_RESOURCES);

NdisMIndicateReceivePacket(
Adapter->AdapterHandle,
&pkt_desc,
1);

//DbgPrint(“thread stack size :0x%x\n”, IoGetRemainingStackSize());
return;
}

The windbg logs:

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: 7ffdf051, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f75e3a4d, address which referenced memory

CURRENT_IRQL: 2

FAULTING_IP:
NDIS!FddiFilterDprIndicateReceive+956
f75e3a4d 640fb60551000000 movzx eax,byte ptr fs:[51h]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 80534256 to 804e45a2

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
edc938a8 80534256 00000003 7ffdf051 f75e3a4d nt!DbgBreakPointWithStatus+0x4
edc93c88 804e2892 0000000a 7ffdf051 00000002 nt!KeDeregisterBugCheckReasonCallback+0x6c7
edc93cc8 ee3b16ef 00000001 ee3ac99e ee3e0000 nt!Kei386EoiHelper+0x2836
edc93d60 ed8e9a09 865704c8 edc93d88 00000001 tcpip!ARPRcv+0x3a
edc93d8c ed8e9ae5 864f8d48 862382d8 00000000 CoretekVNIC!ReferPacket+0x109 [e:\lid\work0711\branches\windows\deltauniontool\coretekvnic\sendrcv.c @ 939]
edc93dac 8057a453 864f8d48 00000000 00000000 CoretekVNIC!RecvThreadHandler+0xb5 [e:\lid\work0711\branches\windows\deltauniontool\coretekvnic\sendrcv.c @ 992]
edc93ddc 804f98fa ed8e9a30 864f8d48 00000000 nt!PsCreateSystemThread+0x70
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

STACK_COMMAND: kb

FOLLOWUP_IP:
CoretekVNIC!ReferPacket+109 [e:vnic\sendrcv.c @ 939]
ed8e9a09 e872030000 call vnic!IoGetRemainingStackSize (ed8e9d80)

FAULTING_SOURCE_CODE:
935: Adapter->AdapterHandle,
936: &pkt_desc,
937: 1);
938:

939: DbgPrint(“thread stack size :0x%x\n”, IoGetRemainingStackSize());
940: return;
941: }
942:
943: #pragma LOCKEDCODE

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: vnic!ReferPacket+109

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vnic

IMAGE_NAME: vnic.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

I have confirmed the memories are in nonpaged system-space memory.But I do not know the Reason why Lead to:“DRIVER_IRQL_NOT_LESS_OR_EQUAL”!

Thanks for your time and help,lidong

Note your faulting address:

Arguments:
Arg1: 7ffdf051, memory referenced

As far as the page fault handler is concerned, this is a user mode address
(< 2GB on x86). Faulting on a user mode address at IRQL >= DISPATCH_LEVEL is
illegal, so you get an IRQL_NOT_LESS_OR_EQUAL bugcheck.

In your case, you simply have a bad address that happens to fall into the
user virtual address range. You would have received the same bugcheck if
this was a NULL pointer dereference (0 < 2GB). This is why the bugcheck
description says that you’ve referenced a “pageable **(or completely
invalid)** address”.

As for what’s wrong with your code, I’ll let the NDIS experts handle that.
The only other suggestion I have is to enable Driver Verifier, you might
have a corruption that can be caught earlier.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi All,
When I developed netvmini,I have a question.I user a kernel thread to recv
data from the Physical Network equipment,then Call the
NdisMIndicateReceivePacket function to Submitted to the windows network
protocol layer.
after calling NdisMIndicateReceivePacket function,Produce
DRIVER_IRQL_NOT_LESS_OR_EQUAL exception!
the codes are the fllows(the test function is called in a kernel thread in
loop):

VOID test(IN PVOID FunctionContext, PUCHAR buffer)
{
PMP_ADAPTER Adapter = (PMP_ADAPTER)FunctionContext;
UINT BytesToCopy = 0;
PUINT32 recvLength = NULL;
PUCHAR recvBase = NULL;

recvLength = (PUINT32)buffer;

if ((*recvLength == 0) || (*recvLength > ETH_MAX_PACKET_SIZE))
{
return;
}

recvBase = (PUCHAR)(buffer + 4);
BytesToCopy = *recvLength;

//
// Increment the ref count on the adapter to prevent the driver from
// unloding while the DPC is running. The Halt handler waits for the
// ref count to drop to zero before returning.
//
//MP_INC_REF(Adapter);

NdisMoveMemory(
rx_bufs,
recvBase,
BytesToCopy);

NdisAdjustBufferLength(
buf_desc,
BytesToCopy);

NDIS_SET_PACKET_STATUS(pkt_desc, NDIS_STATUS_RESOURCES);

NdisMIndicateReceivePacket(
Adapter->AdapterHandle,
&pkt_desc,
1);

//DbgPrint(“thread stack size :0x%x\n”, IoGetRemainingStackSize());
return;
}

The windbg logs:

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: 7ffdf051, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f75e3a4d, address which referenced memory

CURRENT_IRQL: 2

FAULTING_IP:
NDIS!FddiFilterDprIndicateReceive+956
f75e3a4d 640fb60551000000 movzx eax,byte ptr fs:[51h]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 80534256 to 804e45a2

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
edc938a8 80534256 00000003 7ffdf051 f75e3a4d nt!DbgBreakPointWithStatus+0x4
edc93c88 804e2892 0000000a 7ffdf051 00000002
nt!KeDeregisterBugCheckReasonCallback+0x6c7
edc93cc8 ee3b16ef 00000001 ee3ac99e ee3e0000 nt!Kei386EoiHelper+0x2836
edc93d60 ed8e9a09 865704c8 edc93d88 00000001 tcpip!ARPRcv+0x3a
edc93d8c ed8e9ae5 864f8d48 862382d8 00000000 CoretekVNIC!ReferPacket+0x109
[e:\lid\work0711\branches\windows\deltauniontool\coretekvnic\sendrcv.c @
939]
edc93dac 8057a453 864f8d48 00000000 00000000
CoretekVNIC!RecvThreadHandler+0xb5
[e:\lid\work0711\branches\windows\deltauniontool\coretekvnic\sendrcv.c @
992]
edc93ddc 804f98fa ed8e9a30 864f8d48 00000000 nt!PsCreateSystemThread+0x70
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

STACK_COMMAND: kb

FOLLOWUP_IP:
CoretekVNIC!ReferPacket+109 [e:vnic\sendrcv.c @ 939]
ed8e9a09 e872030000 call vnic!IoGetRemainingStackSize (ed8e9d80)

FAULTING_SOURCE_CODE:
935: Adapter->AdapterHandle,
936: &pkt_desc,
937: 1);
938:

939: DbgPrint(“thread stack size :0x%x\n”,
IoGetRemainingStackSize());
940: return;
941: }
942:
943: #pragma LOCKEDCODE

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: vnic!ReferPacket+109

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vnic

IMAGE_NAME: vnic.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

I have confirmed the memories are in nonpaged system-space memory.But I do
not know the Reason why Lead to:“DRIVER_IRQL_NOT_LESS_OR_EQUAL”!

Thanks for your time and help,lidong

Well, I’m waiting for your news
Thanks a million

Hi,

I think, you should be check the “Adapter” value should not be NULL.
Try this one, may be helpful for you.

if (Adapter == NULL)
return ;
else
{
NDIS_SET_PACKET_STATUS(pkt_desc, NDIS_STATUS_RESOURCES);
NdisMIndicateReceivePacket( Adapter->AdapterHandle, &pkt_desc, 1);
//DbgPrint(“thread stack size :0x%x\n”, IoGetRemainingStackSize());
return;

}

I have modified the codes as follows, it has the same trouble?
if (Adapter == NULL)
return ;
else
{
NDIS_SET_PACKET_STATUS(pkt_desc, NDIS_STATUS_RESOURCES);
NdisMIndicateReceivePacket( Adapter->AdapterHandle, &pkt_desc, 1);
//DbgPrint(“thread stack size :0x%x\n”, IoGetRemainingStackSize());
return;

}

Are you sure that you symbols are correct?

The instruction

NDIS!FddiFilterDprIndicateReceive+956 f75e3a4d 640fb60551000000 movzx eax,byte ptr fs:[51h]

actually looks like IoGetRemainingStackSize’s instruction.

IoGetRemainingStackSize (http://msdn.microsoft.com/en-us/library/windows/hardware/ff549286(v=vs.85).aspx) is restricted to IRQL_LEVEL == APC_LEVEL on some systems. Does the BSoD occur if you comment out IoGetRemainingStackSize call?

I am sure the symbols are Correct?
Call any other function after NdisMIndicateReceivePacket, The cursor Indicates an error is
the next line of NdisMIndicateReceivePacket function.
?nt!Kei386EoiHelper+0x2836?, I do’t know the function of “Kei386EoiHelper”,An exception has occurred or
an interrupt has handled ?