BSOD in NDIS!ndisDummyIrpHandler, is this function pageable?

WINDBG
1

Hi.

I have encountered strange issue on our driver and I’m looking for some help to investigate the issue. The driver was working fine (more or less) for years. Lately after update to new Symantec antivirus the BSODs on some old PCs (with 256 MB RAM) started to happen.

Crash dump analysis shows that the issue is always related to address of the NDIS!ndisDummyIrpHandler function. It looks like the function is paged out because new antivirus is using a lot of memory.

I enabled Driver Verifier for the driver and was able to reproduce the issue on PCs with lots of mem and antivirus soft installed. The issue is reproducible on Vista and 2003 OS (these I tried). When I uninstall antivirus the issue goes away.

The issue seems strange because NDIS!ndisDummyIrpHandler is used to handle IRPs and it may be used from Dispatch level, why is it pageable code than? Or am I misunderstanding this, and the driver is doing something wrong?

If someone got some advices what to do next and how to fix that, I will be glad to hear from you.

Thanks,
Mirek

Some info from WinDbg:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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

Debugging Details:

READ_ADDRESS: f9a14198

CURRENT_IRQL: 2

FAULTING_IP:
NDIS!ndisDummyIrpHandler+0
f9a14198 8bff mov edi,edi

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: XXX.exe

TRAP_FRAME: f8804b38 – (.trap 0xfffffffff8804b38)
ErrCode = 00000000
eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90 edi=00000000
eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010296
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi
Resetting default scope

LAST_CONTROL_TRANSFER: from f9a14198 to 80826693

FAILED_INSTRUCTION_ADDRESS:
NDIS!ndisDummyIrpHandler+0
f9a14198 8bff mov edi,edi

STACK_TEXT:
f8804b38 f9a14198 badb0d00 81255208 816256a0 nt!KiTrap0E+0x2a1
f8804ba8 80828ec3 81650ab0 81255208 812f0960 NDIS!ndisDummyIrpHandler
f8804bbc f8c00de8 812f0960 81466398 812f08a8 nt!IofCallDriver+0x45
f8804bcc f8c018e5 812f08a8 81466398 812f08a8 MyDriver!HoldDeviceInReset+0x90
f8804bec 8081b473 812f0802 01466398 81466398 MyDriver!StartIo_gendspk+0x12b
f8804c10 f8bff531 812f08a8 81466398 00000000 nt!IoStartPacket+0xa6
f8804c24 f8bff7b3 812f08a8 81466398 81466398 MyDriver!HandleGetKmdRxNonVirtualDescTableContents_gendspk+0x1d
f8804c3c 80828ec3 812f08a8 81466398 8161f780 MyDriver!DispatchIoControl_gendspk+0x97
f8804c50 8090b6e3 81466408 814262e8 81466398 nt!IofCallDriver+0x45
f8804c64 8090e95f 812f08a8 81466398 814262e8 nt!IopSynchronousServiceTail+0x10b
f8804d00 8092e5f0 00000290 000002ac 00000000 nt!IopXxxControlFile+0x60f
f8804d34 8082350b 00000290 000002ac 00000000 nt!NtDeviceIoControlFile+0x2a
f8804d34 7c8285ec 00000290 000002ac 00000000 nt!KiFastCallEntry+0xf8
0759ea54 7c826fcb 77e417e5 00000290 000002ac ntdll!KiFastSystemCallRet
0759ea58 77e417e5 00000290 000002ac 00000000 ntdll!NtDeviceIoControlFile+0xc
0759eabc 00404f65 00000290 800f2008 00000000 kernel32!DeviceIoControl+0xd2
0759ead4 00000000 0759eaf0 0759eafc 00000001 XXX!BeginApplication+0x15

STACK_COMMAND: kb

FOLLOWUP_IP:
MyDriver!HoldDeviceInReset+90
f8c00de8 0fb74618 movzx eax,word ptr [esi+18h]

kd> .trap 0xfffffffff8804b38
ErrCode = 00000000
eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90 edi=00000000
eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010296
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi

kd> u NDIS!ndisDummyIrpHandler
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi
f9a1419a 55 push ebp
f9a1419b 8bec mov ebp,esp
f9a1419d 8b4d0c mov ecx,dword ptr [ebp+0Ch]
f9a141a0 8b5160 mov edx,dword ptr [ecx+60h]
f9a141a3 56 push esi
f9a141a4 57 push edi
f9a141a5 8b7d08 mov edi,dword ptr [ebp+8]
kd> !address NDIS!ndisDummyIrpHandler
f8136000 - 02229000
Usage KernelSpaceUsageNonPagedSystem

kd> !pte NDIS!ndisDummyIrpHandler
VA f9a14198
PDE at C0300F98 PTE at C03E6850
contains 00AA5163 contains 0FDD6860
pfn aa5 -G-DA–KWEV not valid
Transition: fdd6
Protect: 3 - ExecuteRead

kd> !pool NDIS!ndisDummyIrpHandler
Pool page f9a14198 region is Unknown
f9a14000 is not a valid large pool allocation, checking large session pool…
f9a14000 is freed (or corrupt) pool
Bad previous allocation size @f9a14000, last size was 0

***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFFFFFF9A14000)
***
*** Use !poolval f9a14000 for more details.
***

2

wrote in message news:xxxxx@windbg…
>The issue seems strange because NDIS!ndisDummyIrpHandler is used to handle
>IRPs and it may be used from Dispatch level, >why is it pageable code than?
>Or am I misunderstanding this, and the driver is doing something wrong?

Your analysis is correct, the routine is paged out (the !pte output confirms
it).

So, NDIS is not expecting this dispatch entry point to be called at IRQL >=
DISPATCH_LEVEL. This is entirely reasonable, unless there’s an implicit
contract between cooperating drivers a driver expects its dispatch entry
points to be called at PASSIVE_LEVEL.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
> Hi.
>
> I have encountered strange issue on our driver and I’m looking for some
> help to investigate the issue. The driver was working fine (more or less)
> for years. Lately after update to new Symantec antivirus the BSODs on some
> old PCs (with 256 MB RAM) started to happen.
>
> Crash dump analysis shows that the issue is always related to address of
> the NDIS!ndisDummyIrpHandler function. It looks like the function is
> paged out because new antivirus is using a lot of memory.
>
> I enabled Driver Verifier for the driver and was able to reproduce the
> issue on PCs with lots of mem and antivirus soft installed. The issue is
> reproducible on Vista and 2003 OS (these I tried). When I uninstall
> antivirus the issue goes away.
>
> The issue seems strange because NDIS!ndisDummyIrpHandler is used to handle
> IRPs and it may be used from Dispatch level, why is it pageable code than?
> Or am I misunderstanding this, and the driver is doing something wrong?
>
> If someone got some advices what to do next and how to fix that, I will be
> glad to hear from you.
>
> Thanks,
> Mirek
>
>
> Some info from WinDbg:
>
> kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> 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: f9a14198, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f9a14198, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: f9a14198
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> NDIS!ndisDummyIrpHandler+0
> f9a14198 8bff mov edi,edi
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: XXX.exe
>
> TRAP_FRAME: f8804b38 – (.trap 0xfffffffff8804b38)
> ErrCode = 00000000
> eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90
> edi=00000000
> eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010296
> NDIS!ndisDummyIrpHandler:
> f9a14198 8bff mov edi,edi
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from f9a14198 to 80826693
>
> FAILED_INSTRUCTION_ADDRESS:
> NDIS!ndisDummyIrpHandler+0
> f9a14198 8bff mov edi,edi
>
> STACK_TEXT:
> f8804b38 f9a14198 badb0d00 81255208 816256a0 nt!KiTrap0E+0x2a1
> f8804ba8 80828ec3 81650ab0 81255208 812f0960 NDIS!ndisDummyIrpHandler
> f8804bbc f8c00de8 812f0960 81466398 812f08a8 nt!IofCallDriver+0x45
> f8804bcc f8c018e5 812f08a8 81466398 812f08a8
> MyDriver!HoldDeviceInReset+0x90
> f8804bec 8081b473 812f0802 01466398 81466398
> MyDriver!StartIo_gendspk+0x12b
> f8804c10 f8bff531 812f08a8 81466398 00000000 nt!IoStartPacket+0xa6
> f8804c24 f8bff7b3 812f08a8 81466398 81466398
> MyDriver!HandleGetKmdRxNonVirtualDescTableContents_gendspk+0x1d
> f8804c3c 80828ec3 812f08a8 81466398 8161f780
> MyDriver!DispatchIoControl_gendspk+0x97
> f8804c50 8090b6e3 81466408 814262e8 81466398 nt!IofCallDriver+0x45
> f8804c64 8090e95f 812f08a8 81466398 814262e8
> nt!IopSynchronousServiceTail+0x10b
> f8804d00 8092e5f0 00000290 000002ac 00000000 nt!IopXxxControlFile+0x60f
> f8804d34 8082350b 00000290 000002ac 00000000 nt!NtDeviceIoControlFile+0x2a
> f8804d34 7c8285ec 00000290 000002ac 00000000 nt!KiFastCallEntry+0xf8
> 0759ea54 7c826fcb 77e417e5 00000290 000002ac ntdll!KiFastSystemCallRet
> 0759ea58 77e417e5 00000290 000002ac 00000000
> ntdll!NtDeviceIoControlFile+0xc
> 0759eabc 00404f65 00000290 800f2008 00000000 kernel32!DeviceIoControl+0xd2
> 0759ead4 00000000 0759eaf0 0759eafc 00000001 XXX!BeginApplication+0x15
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> MyDriver!HoldDeviceInReset+90
> f8c00de8 0fb74618 movzx eax,word ptr [esi+18h]
>
>
> kd> .trap 0xfffffffff8804b38
> ErrCode = 00000000
> eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90
> edi=00000000
> eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010296
> NDIS!ndisDummyIrpHandler:
> f9a14198 8bff mov edi,edi
>
>
> kd> u NDIS!ndisDummyIrpHandler
> NDIS!ndisDummyIrpHandler:
> f9a14198 8bff mov edi,edi
> f9a1419a 55 push ebp
> f9a1419b 8bec mov ebp,esp
> f9a1419d 8b4d0c mov ecx,dword ptr [ebp+0Ch]
> f9a141a0 8b5160 mov edx,dword ptr [ecx+60h]
> f9a141a3 56 push esi
> f9a141a4 57 push edi
> f9a141a5 8b7d08 mov edi,dword ptr [ebp+8]
> kd> !address NDIS!ndisDummyIrpHandler
> f8136000 - 02229000
> Usage KernelSpaceUsageNonPagedSystem
>
> kd> !pte NDIS!ndisDummyIrpHandler
> VA f9a14198
> PDE at C0300F98 PTE at C03E6850
> contains 00AA5163 contains 0FDD6860
> pfn aa5 -G-DA–KWEV not valid
> Transition: fdd6
> Protect: 3 - ExecuteRead
>
> kd> !pool NDIS!ndisDummyIrpHandler
> Pool page f9a14198 region is Unknown
> f9a14000 is not a valid large pool allocation, checking large session
> pool…
> f9a14000 is freed (or corrupt) pool
> Bad previous allocation size @f9a14000, last size was 0
>
>
> An error (or corruption) in the pool was detected;
> Pool Region unknown (0xFFFFFFFFF9A14000)
>
> Use !poolval f9a14000 for more details.
>
>
>
>
>
>

3

Whenever I see the phrase “(more or less)” I tend to be highly suspicious of
“The driver was working fine”. It sounds like the driver had “issues” which
were simply being written off and/or ignored until a worse piece of crap,
Symantec Anything, was intstalled.

How do you use NDIS!ndisDummyIrpHandler from Dispatch? Do you use it via an
interrupt spinlock to synchronize access to the function, or blindly call
the function?

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ratmik@wp.pl
Sent: Wednesday, May 12, 2010 8:33 AM
To: Kernel Debugging Interest List
Subject: [windbg] BSOD in NDIS!ndisDummyIrpHandler, is this function
pageable?

Hi.

I have encountered strange issue on our driver and I’m looking for some help
to investigate the issue. The driver was working fine (more or less) for
years. Lately after update to new Symantec antivirus the BSODs on some old
PCs (with 256 MB RAM) started to happen.

Crash dump analysis shows that the issue is always related to address of the
NDIS!ndisDummyIrpHandler function. It looks like the function is paged out
because new antivirus is using a lot of memory.

I enabled Driver Verifier for the driver and was able to reproduce the issue
on PCs with lots of mem and antivirus soft installed. The issue is
reproducible on Vista and 2003 OS (these I tried). When I uninstall
antivirus the issue goes away.

The issue seems strange because NDIS!ndisDummyIrpHandler is used to handle
IRPs and it may be used from Dispatch level, why is it pageable code than?
Or am I misunderstanding this, and the driver is doing something wrong?

If someone got some advices what to do next and how to fix that, I will be
glad to hear from you.

Thanks,
Mirek

Some info from WinDbg:

kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

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

Debugging Details:

READ_ADDRESS: f9a14198

CURRENT_IRQL: 2

FAULTING_IP:
NDIS!ndisDummyIrpHandler+0
f9a14198 8bff mov edi,edi

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: XXX.exe

TRAP_FRAME: f8804b38 – (.trap 0xfffffffff8804b38)
ErrCode = 00000000
eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90
edi=00000000
eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010296
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi
Resetting default scope

LAST_CONTROL_TRANSFER: from f9a14198 to 80826693

FAILED_INSTRUCTION_ADDRESS:
NDIS!ndisDummyIrpHandler+0
f9a14198 8bff mov edi,edi

STACK_TEXT:
f8804b38 f9a14198 badb0d00 81255208 816256a0 nt!KiTrap0E+0x2a1
f8804ba8 80828ec3 81650ab0 81255208 812f0960 NDIS!ndisDummyIrpHandler
f8804bbc f8c00de8 812f0960 81466398 812f08a8 nt!IofCallDriver+0x45
f8804bcc f8c018e5 812f08a8 81466398 812f08a8 MyDriver!HoldDeviceInReset+0x90

f8804bec 8081b473 812f0802 01466398 81466398 MyDriver!StartIo_gendspk+0x12b
f8804c10 f8bff531 812f08a8 81466398 00000000 nt!IoStartPacket+0xa6
f8804c24 f8bff7b3 812f08a8 81466398 81466398
MyDriver!HandleGetKmdRxNonVirtualDescTableContents_gendspk+0x1d
f8804c3c 80828ec3 812f08a8 81466398 8161f780
MyDriver!DispatchIoControl_gendspk+0x97
f8804c50 8090b6e3 81466408 814262e8 81466398 nt!IofCallDriver+0x45
f8804c64 8090e95f 812f08a8 81466398 814262e8
nt!IopSynchronousServiceTail+0x10b
f8804d00 8092e5f0 00000290 000002ac 00000000 nt!IopXxxControlFile+0x60f
f8804d34 8082350b 00000290 000002ac 00000000 nt!NtDeviceIoControlFile+0x2a
f8804d34 7c8285ec 00000290 000002ac 00000000 nt!KiFastCallEntry+0xf8
0759ea54 7c826fcb 77e417e5 00000290 000002ac ntdll!KiFastSystemCallRet
0759ea58 77e417e5 00000290 000002ac 00000000 ntdll!NtDeviceIoControlFile+0xc
0759eabc 00404f65 00000290 800f2008 00000000 kernel32!DeviceIoControl+0xd2
0759ead4 00000000 0759eaf0 0759eafc 00000001 XXX!BeginApplication+0x15

STACK_COMMAND: kb

FOLLOWUP_IP:
MyDriver!HoldDeviceInReset+90
f8c00de8 0fb74618 movzx eax,word ptr [esi+18h]

kd> .trap 0xfffffffff8804b38
ErrCode = 00000000
eax=0000000f ebx=81650ab0 ecx=81650ab0 edx=81255208 esi=81690e90
edi=00000000
eip=f9a14198 esp=f8804bac ebp=f8804bbc iopl=0 nv up ei ng nz ac pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010296
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi

kd> u NDIS!ndisDummyIrpHandler
NDIS!ndisDummyIrpHandler:
f9a14198 8bff mov edi,edi
f9a1419a 55 push ebp
f9a1419b 8bec mov ebp,esp
f9a1419d 8b4d0c mov ecx,dword ptr [ebp+0Ch]
f9a141a0 8b5160 mov edx,dword ptr [ecx+60h]
f9a141a3 56 push esi
f9a141a4 57 push edi
f9a141a5 8b7d08 mov edi,dword ptr [ebp+8]
kd> !address NDIS!ndisDummyIrpHandler
f8136000 - 02229000
Usage KernelSpaceUsageNonPagedSystem

kd> !pte NDIS!ndisDummyIrpHandler
VA f9a14198
PDE at C0300F98 PTE at C03E6850
contains 00AA5163 contains 0FDD6860
pfn aa5 -G-DA–KWEV not valid
Transition: fdd6
Protect: 3 - ExecuteRead

kd> !pool NDIS!ndisDummyIrpHandler
Pool page f9a14198 region is Unknown
f9a14000 is not a valid large pool allocation, checking large session
pool…
f9a14000 is freed (or corrupt) pool
Bad previous allocation size @f9a14000, last size was 0

***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFFFFFF9A14000)
***
*** Use !poolval f9a14000 for more details.
***

WINDBG 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

__________ Information from ESET Smart Security, version of virus signature
database 5108 (20100512) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 5108 (20100512) __________

The message was checked by ESET Smart Security.

http://www.eset.com

4

Quick update:

The driver was written 10 years ago, and was not updated for 5 years. It’s working on thousands of customer PCs 24/7 without problems, so I think I may say “more or less”. Since Vista introduction there have been some rare issues with BSOD after installation of new soft, but after initial crash everything was working fine. So yes, there are some issues there, but give me example of non trivial soft that is bug free. Recently my team inherited this driver from another team that had ever less knowledge about it and they inherited it from team that no longer exists. Lately after update to new antivirus we are experiencing BSOD on old 256 MB PCs when installing our new soft.

About the issue itself:
I’m not calling NDIS!ndisDummyIrpHandler() directly. I’m calling IoCallDriver() which is supposed to send IRP to Ndisminiport driver that needs to process it. IoCallDriver() docs says that it’s OK to call it at DISPATCH level. So this is the strange thing. Why function that is supposed to process IRPs are marked pageable?

the code is included below:

function(
ULONG IoControlCode,
PDEVICE_OBJECT TargetDeviceObject,
PVOID InputBuffer OPTIONAL,
ULONG InputBufferLength,
PVOID OutputBuffer OPTIONAL,
ULONG OutputBufferLength)
{
NTSTATUS dwStatus;
PIRP pIrp;
PIO_STACK_LOCATION pIrpStack;

/* Check if this request needs to use both the input and output buffers.*/
if((0 == InputBufferLength) || (0 == OutputBufferLength)){
/* Allocate an IRP.*/
pIrp = IoAllocateIrp((CCHAR)(TargetDeviceObject->StackSize + 1), FALSE);
/*Check that the IRP was successfully created.*/
if(NULL != pIrp){
/* Obtain a pointer to the first stack location.*/
pIrpStack = IoGetNextIrpStackLocation(pIrp);
/* Initialize the IRP stack.*/
pIrpStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
pIrpStack->Parameters.DeviceIoControl.OutputBufferLength =
OutputBufferLength;
pIrpStack->Parameters.DeviceIoControl.InputBufferLength =
InputBufferLength;
pIrpStack->Parameters.DeviceIoControl.IoControlCode = IoControlCode;
pIrpStack->FileObject = GenDspDriverBlock.pstNdisFileObject;

/* Set IRP to use the buffer that was requested (in/out/neither).*/
if(InputBufferLength != 0) {
pIrp->AssociatedIrp.SystemBuffer = InputBuffer;
} else if(OutputBufferLength != 0) {
pIrp->AssociatedIrp.SystemBuffer = OutputBuffer;
}

/* Set completion routine.*/
IoSetCompletionRoutine(
pIrp,
GenDspInternalIoctlCompletionRoutine,
NULL,
TRUE,
TRUE,
TRUE);

/* Send IRP.*/
dwStatus = IoCallDriver(TargetDeviceObject, pIrp);
}
else {
/* Fail the request to send the IRP.*/
dwStatus = STATUS_INSUFFICIENT_RESOURCES;
}
}
else {
/* Fail the request to send the IRP.*/
dwStatus = STATUS_UNSUCCESSFUL;
}

return dwStatus;
}

5

IoCallDriver can be called at dispatch, but each stack can define the max IRQL that they can process IO under. I am guessing that ndis only accepts internal IOCTLs at passive and your driver needs to operate under that restriction .

d

sent from a phpne with no keynoard

-----Original Message-----
From: ratmik@wp.pl
Sent: May 13, 2010 12:32 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] BSOD in NDIS!ndisDummyIrpHandler, is this function pageable?

Quick update:

The driver was written 10 years ago, and was not updated for 5 years. It’s working on thousands of customer PCs 24/7 without problems, so I think I may say “more or less”. Since Vista introduction there have been some rare issues with BSOD after installation of new soft, but after initial crash everything was working fine. So yes, there are some issues there, but give me example of non trivial soft that is bug free. Recently my team inherited this driver from another team that had ever less knowledge about it and they inherited it from team that no longer exists. Lately after update to new antivirus we are experiencing BSOD on old 256 MB PCs when installing our new soft.

About the issue itself:
I’m not calling NDIS!ndisDummyIrpHandler() directly. I’m calling IoCallDriver() which is supposed to send IRP to Ndisminiport driver that needs to process it. IoCallDriver() docs says that it’s OK to call it at DISPATCH level. So this is the strange thing. Why function that is supposed to process IRPs are marked pageable?

the code is included below:

function(
ULONG IoControlCode,
PDEVICE_OBJECT TargetDeviceObject,
PVOID InputBuffer OPTIONAL,
ULONG InputBufferLength,
PVOID OutputBuffer OPTIONAL,
ULONG OutputBufferLength)
{
NTSTATUS dwStatus;
PIRP pIrp;
PIO_STACK_LOCATION pIrpStack;

/* Check if this request needs to use both the input and output buffers./
if((0 == InputBufferLength) || (0 == OutputBufferLength)){
/ Allocate an IRP./
pIrp = IoAllocateIrp((CCHAR)(TargetDeviceObject->StackSize + 1), FALSE);
/Check that the IRP was successfully created./
if(NULL != pIrp){
/ Obtain a pointer to the first stack location./
pIrpStack = IoGetNextIrpStackLocation(pIrp);
/ Initialize the IRP stack./
pIrpStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
pIrpStack->Parameters.DeviceIoControl.OutputBufferLength =
OutputBufferLength;
pIrpStack->Parameters.DeviceIoControl.InputBufferLength =
InputBufferLength;
pIrpStack->Parameters.DeviceIoControl.IoControlCode = IoControlCode;
pIrpStack->FileObject = GenDspDriverBlock.pstNdisFileObject;

/ Set IRP to use the buffer that was requested (in/out/neither)./
if(InputBufferLength != 0) {
pIrp->AssociatedIrp.SystemBuffer = InputBuffer;
} else if(OutputBufferLength != 0) {
pIrp->AssociatedIrp.SystemBuffer = OutputBuffer;
}

/ Set completion routine./
IoSetCompletionRoutine(
pIrp,
GenDspInternalIoctlCompletionRoutine,
NULL,
TRUE,
TRUE,
TRUE);

/ Send IRP./
dwStatus = IoCallDriver(TargetDeviceObject, pIrp);
}
else {
/ Fail the request to send the IRP./
dwStatus = STATUS_INSUFFICIENT_RESOURCES;
}
}
else {
/ Fail the request to send the IRP.*/
dwStatus = STATUS_UNSUCCESSFUL;
}

return dwStatus;
}

—
WINDBG 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

6

Thanks for reply.

Is this only your guess or is there a way to confirm (some documents)
that NDIS accepts IOCTLs at passive level?

Doron Holan wrote:

IoCallDriver can be called at dispatch, but each stack can define the max IRQL that they can process IO under. I am guessing that ndis only accepts internal IOCTLs at passive and your driver needs to operate under that restriction .

d

sent from a phpne with no keynoard

7

I’d say the fact that the dispatch entry point is marked as pageable is a
pretty good confirmation.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Miros?aw Gwiz.dz.” wrote in message news:xxxxx@windbg…
> Thanks for reply.
>
> Is this only your guess or is there a way to confirm (some documents) that
> NDIS accepts IOCTLs at passive level?
>
> Doron Holan wrote:
>> IoCallDriver can be called at dispatch, but each stack can define the max
>> IRQL that they can process IO under. I am guessing that ndis only accepts
>> internal IOCTLs at passive and your driver needs to operate under that
>> restriction .
>>
>> d
>>
>> sent from a phpne with no keynoard
>>
>>
>>
>