DRIVER_IRQL_NOT_LESS_OR_EQUAL

NTDEV
1

Weird …

I’m beginning the process of developing a network filter driver. In my NdisFRegisterFilterDriver function, if I set the FilterCharacteristics.ReceiveNetBufferListsHandler to NULL, everything works fine. However, if I set this to my handler function, I get the BSOD with an error of DRIVER_IRQL_NOT_LESS_OR_EQUAL.

This is my ReceiveNetBufferListsHandler function:

VOID FilterReceiveNetBufferLists(
IN NDIS_HANDLE FilterModuleContext,
IN PNET_BUFFER_LIST NetBufferLists,
IN NDIS_PORT_NUMBER PortNumber,
IN ULONG NumberOfNetBufferLIsts,
IN ULONG ReceiveFlags)
{
PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;

NdisFIndicateReceiveNetBufferLists(
pFilter->FilterHandle,
NetBufferLIsts,
PortNumber,
NumberOfNetBufferLists,
ReceiveFlags);
}

So all my receive function is doing is indicating that it received something. According to MSDN, this function can be called from IRQL <= DISPATCH_LEVEL.

Of course this makes me think that some memory is screwed up somewhere, but everything looks good. Here’s what I see with the crash dump …

Arguments:
Arg1: 00a40400, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 81e9fd59, address which referenced memory

00a40400 is the pFilter->FilterHandle. Does anybody have any idea why this would crash with this error, and if so, what should I do to fix it?

Thanks,
– Jim

2

Is FilterModuleContext allocated from PagedPool? If so make it NonPagedPool

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Weird …
>
> I’m beginning the process of developing a network filter driver. In my
> NdisFRegisterFilterDriver function, if I set the
> FilterCharacteristics.ReceiveNetBufferListsHandler to NULL, everything
> works fine. However, if I set this to my handler function, I get the BSOD
> with an error of DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> This is my ReceiveNetBufferListsHandler function:
>
> VOID FilterReceiveNetBufferLists(
> IN NDIS_HANDLE FilterModuleContext,
> IN PNET_BUFFER_LIST NetBufferLists,
> IN NDIS_PORT_NUMBER PortNumber,
> IN ULONG NumberOfNetBufferLIsts,
> IN ULONG ReceiveFlags)
> {
> PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;
>
> NdisFIndicateReceiveNetBufferLists(
>
> pFilter->FilterHandle,
> NetBufferLIsts,
> PortNumber,
>
> NumberOfNetBufferLists,
> ReceiveFlags);
> }
>
> So all my receive function is doing is indicating that it received
> something. According to MSDN, this function can be called from IRQL <=
> DISPATCH_LEVEL.
>
> Of course this makes me think that some memory is screwed up somewhere,
> but everything looks good. Here’s what I see with the crash dump …
>
> Arguments:
> Arg1: 00a40400, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 81e9fd59, address which referenced memory
>
> 00a40400 is the pFilter->FilterHandle. Does anybody have any idea why
> this would crash with this error, and if so, what should I do to fix it?
>
> Thanks,
> – Jim
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4308 (20090805)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4308 (20090805)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

3

Thanks Don. I thought that would have been it, but it didn’t work. I
added the following code to my function:

VOID FilterReceiveNetBufferLists(
IN NDIS_HANDLE FilterModuleContext,
IN PNET_BUFFER_LIST NetBufferLists,
IN NDIS_PORT_NUMBER PortNumber,
IN ULONG NumberOfNetBufferLIsts,
IN ULONG ReceiveFlags)
{
PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;

Status = NdisAllocateMemory (
(PVOID) &newFIlter,
sizeof (MS_FILTER),
0,
Neg);

NdisZeroMemory(&newFilter, sizeof(MS_FILTER));
memcpy(&newFilter, FilterModuleContext, sizeof(MS_FILTER));
pFilter = (PMS_FILTER) &newFilter;

NdisFIndicateReceiveNetBufferLists(

pFilter->FilterHandle,
NetBufferLIsts,
PortNumber,

NumberOfNetBufferLists,
ReceiveFlags);
}

That should have made pFilter point to nonpaged memory, but I’m still
getting the BSOD on NdisFIndicateReceiveNetBufferLists. Any other
ideas? I’ll keep checking it out. This seems like it should be simple
though.

Thanks again.
– Jim

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, August 05, 2009 11:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

Is FilterModuleContext allocated from PagedPool? If so make it
NonPagedPool

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Weird …
>
> I’m beginning the process of developing a network filter driver. In
my
> NdisFRegisterFilterDriver function, if I set the
> FilterCharacteristics.ReceiveNetBufferListsHandler to NULL, everything

> works fine. However, if I set this to my handler function, I get the
BSOD
> with an error of DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> This is my ReceiveNetBufferListsHandler function:
>
> VOID FilterReceiveNetBufferLists(
> IN NDIS_HANDLE FilterModuleContext,
> IN PNET_BUFFER_LIST NetBufferLists,
> IN NDIS_PORT_NUMBER PortNumber,
> IN ULONG NumberOfNetBufferLIsts,
> IN ULONG ReceiveFlags)
> {
> PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;
>
> NdisFIndicateReceiveNetBufferLists(
>
> pFilter->FilterHandle,
> NetBufferLIsts,
> PortNumber,
>
> NumberOfNetBufferLists,
> ReceiveFlags);
> }
>
> So all my receive function is doing is indicating that it received
> something. According to MSDN, this function can be called from IRQL
<=
> DISPATCH_LEVEL.
>
> Of course this makes me think that some memory is screwed up
somewhere,
> but everything looks good. Here’s what I see with the crash dump …
>
> Arguments:
> Arg1: 00a40400, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 81e9fd59, address which referenced memory
>
> 00a40400 is the pFilter->FilterHandle. Does anybody have any idea why

> this would crash with this error, and if so, what should I do to fix
it?
>
> Thanks,
> – Jim
>
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4308 (20090805)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus
signature database 4308 (20090805)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Munafo, Jim (Xetron) wrote:

Thanks Don. I thought that would have been it, but it didn’t work. I
added the following code to my function:

> VOID FilterReceiveNetBufferLists(
> IN NDIS_HANDLE FilterModuleContext,
> IN PNET_BUFFER_LIST NetBufferLists,
> IN NDIS_PORT_NUMBER PortNumber,
> IN ULONG NumberOfNetBufferLIsts,
> IN ULONG ReceiveFlags)
> {
> PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;
>

Status = NdisAllocateMemory (
(PVOID) &newFIlter,
sizeof (MS_FILTER),
0,
Neg);

NdisZeroMemory(&newFilter, sizeof(MS_FILTER));
memcpy(&newFilter, FilterModuleContext, sizeof(MS_FILTER));
pFilter = (PMS_FILTER) &newFilter;

This is a C problem. You don’t show us the declaration of newFilter,
but it’s clear that you have too many &s in there at some point. If you
have this:
PMS_FILTER newFilter;

then you want newFilter instead of &newFilter in both NdisZeroMemory and
memcpy. Remember, after the NdisAllocateMemory call, newFilter contains
a POINTER, not a structure. Assuming MS_FILTER is longer than 4 bytes,
the NdisZeroMemory call is going to trash the memory following it.

By the way, the call to NdisZeroMemory is pointless there, since the
memcpy fills up the exact same size.

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

5

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, August 05, 2009 12:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

Munafo, Jim (Xetron) wrote:

Thanks Don. I thought that would have been it, but it didn’t work. I
added the following code to my function:

> VOID FilterReceiveNetBufferLists(
> IN NDIS_HANDLE FilterModuleContext,
> IN PNET_BUFFER_LIST NetBufferLists,
> IN NDIS_PORT_NUMBER PortNumber,
> IN ULONG NumberOfNetBufferLIsts,
> IN ULONG ReceiveFlags)
> {
> PMS_FILTER pFilter = (PMS_FILTER) FilterModuleContext;
>

Status = NdisAllocateMemory (
(PVOID) &newFIlter,
sizeof (MS_FILTER),
0,
Neg);

NdisZeroMemory(&newFilter, sizeof(MS_FILTER));
memcpy(&newFilter, FilterModuleContext, sizeof(MS_FILTER));
pFilter = (PMS_FILTER) &newFilter;

This is a C problem. You don’t show us the declaration of newFilter,
but it’s clear that you have too many &s in there at some point. If you
have this:
PMS_FILTER newFilter;

then you want newFilter instead of &newFilter in both NdisZeroMemory and
memcpy. Remember, after the NdisAllocateMemory call, newFilter contains
a POINTER, not a structure. Assuming MS_FILTER is longer than 4 bytes,
the NdisZeroMemory call is going to trash the memory following it.

By the way, the call to NdisZeroMemory is pointless there, since the
memcpy fills up the exact same size.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks Tim. Sorry I didn’t show everything. newFilter is declared as:

MS_FILTER newFilter;

You’re also correct that the zero memory call really doesn’t do
anything, I really just did that to check if my pointers are correct.
The memory does get zeroed (is that a word?) out and the memcpy is
successful. I’ll look into it more just to double check, but for now
it’s still crashing.

Thanks again.

6

Jim Munafo wrote:

Thanks Tim. Sorry I didn’t show everything. newFilter is declared as:

MS_FILTER newFilter;

That’s equally wrong, but in the opposite direction. NdisAllocateMemory
returns a POINTER to the new memory. You are allocating a structure on
the stack there. After the allocate call, the location of newFilter
will not have changed, but the first four bytes of it will now contain
an address.

Change that to
PMS_FILTER newFilter;

then make the other changes I suggested.

You’re also correct that the zero memory call really doesn’t do
anything, I really just did that to check if my pointers are correct.
The memory does get zeroed (is that a word?) out and the memcpy is
successful. I’ll look into it more just to double check, but for now
it’s still crashing.

No doubt.

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

7

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, August 05, 2009 2:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

Jim Munafo wrote:

Thanks Tim. Sorry I didn’t show everything. newFilter is declared
as:

MS_FILTER newFilter;

That’s equally wrong, but in the opposite direction. NdisAllocateMemory
returns a POINTER to the new memory. You are allocating a structure on
the stack there. After the allocate call, the location of newFilter
will not have changed, but the first four bytes of it will now contain
an address.

Change that to
PMS_FILTER newFilter;

then make the other changes I suggested.

You’re also correct that the zero memory call really doesn’t do
anything, I really just did that to check if my pointers are correct.
The memory does get zeroed (is that a word?) out and the memcpy is
successful. I’ll look into it more just to double check, but for now
it’s still crashing.

No doubt.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks everyone for the help. It appears as though I was just
registering properly.
– Jim