DRIVER_IRQL_NOT_LESS_OR_EQUAL

NTDEV
1

I am developing a Win2k Device Driver for a PCI NIC.

I have a case wherein one of my routines… waits on a waitobject… This is
signalled in my DpcForIsr() which is called when interrupt is generated
for my device.

But I face the following problem… my initial routines goes into wait
state sucessfully… & there is no problem until the interrupt is
generated. however … as soon as interrupt is generated…
I get following bug check

MM:**PAGE FAULT AT IRQL > 1 Va ED0646E0, IRQL 9

***Fatal System Error: 0x000000d1
(0xED0646E0,0x0000009,0x0000000,0xED0646E0)
Hard Coded Break Point.

I’ve compared the address …is not of by wait_object or wait_time
variable. I’am using KeWaitForSingleObject(…,UserMode…)… Using in
Kernelmode… seems to work sometimes but again it also causes same bug
check at times…

I feel this error occurs even before… ISR is called… I checked it with
DbgPrints… or adding breakPoint…

*************************

Moreover, i had one doubt… is Driver-Code by default Pageable… or
Locked… mean the ISR routine… & my other routines too…

******************

Any inputs are welcome,

Thanx in advance.

SP.

2

You should give us a stack trace from WinDbg and a checked version
of the HAL and kernel.That said, this could be several things.

Your wait object can’t be in pageable memory, if it is, and its paged out
when you try to signal it you will get this error.

If you are trying to signal with KeSetEvent in your DPC you need to set
the wait to FALSE since you aren’t allowed to wait at elevated IRQL.

You should be running your driver with verifier. Verifier will catch
you trying to access pageable memory at elevated IRQL by paging out
all your memory.

With a stack trace we can probably point out the problem quickly…

-Jeff

-----Original Message-----
From: Shailesh [mailto:xxxxx@hotmail.com]
Sent: Wednesday, September 04, 2002 7:48 AM
To: NT Developers Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I am developing a Win2k Device Driver for a PCI NIC.

I have a case wherein one of my routines… waits on a waitobject… This is
signalled in my DpcForIsr() which is called when interrupt is generated
for my device.

But I face the following problem… my initial routines goes into wait
state sucessfully… & there is no problem until the interrupt is
generated. however … as soon as interrupt is generated…
I get following bug check

MM:**PAGE FAULT AT IRQL > 1 Va ED0646E0, IRQL 9

***Fatal System Error: 0x000000d1
(0xED0646E0,0x0000009,0x0000000,0xED0646E0)
Hard Coded Break Point.

I’ve compared the address …is not of by wait_object or wait_time
variable. I’am using KeWaitForSingleObject(…,UserMode…)… Using in
Kernelmode… seems to work sometimes but again it also causes same bug
check at times…

I feel this error occurs even before… ISR is called… I checked it with
DbgPrints… or adding breakPoint…

*************************

Moreover, i had one doubt… is Driver-Code by default Pageable… or
Locked… mean the ISR routine… & my other routines too…

******************

Any inputs are welcome,

Thanx in advance.

SP.

You are currently subscribed to ntdev as: xxxxx@concord.com
To unsubscribe send a blank email to %%email.unsub%%

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
the latest virus scan software available for the presence of computer
viruses.
**********************************************************************

3

By default driver code and static data objects are non-pageable. The
stack is another story. In general, but not always, it is effectively
non-paged. Heap allocations are obviously from either the paged heap
pool or the non-paged heap pool.

The pageable mode of the kernel stack is a bit obscure. It is not
pageable until a wait occurs in kernel mode. Then it may or may not be
pageable depending on how the wait is specified. This is critical if you
are allocating and waiting on stack based event objects, as I suspect
you are:

“If the WaitMode parameter is UserMode, the kernel stack can be swapped
out during the wait. Consequently, a caller must never attempt to pass
parameters on the stack when calling KeWaitForSingleObject using the
UserMode argument. If you allocate the event on the stack, you must set
the WaitMode parameter to KernelMode.”

I think this fits the description of your problem. Use KernelMode as the
waitmode and Executive as the waitreason, and your stack-based event
object will be effectively non-pageable.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Shailesh”
To: “NT Developers Interest List”
Date: Wed, 4 Sep 2002 07:47:53 -0400
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

> I am developing a Win2k Device Driver for a PCI NIC.
>
> I have a case wherein one of my routines… waits on a waitobject… This
> is
> signalled in my DpcForIsr() which is called when interrupt is generated
> for my device.
>
> But I face the following problem… my initial routines goes into wait
> state sucessfully… & there is no problem until the interrupt is
> generated. however … as soon as interrupt is generated…
> I get following bug check
>
> MM: PAGE FAULT AT IRQL > 1 Va ED0646E0, IRQL 9
>
>* Fatal System Error: 0x000000d1
> (0xED0646E0,0x0000009,0x0000000,0xED0646E0)
> Hard Coded Break Point.
>
> I’ve compared the address …is not of by wait_object or wait_time
> variable. I’am using KeWaitForSingleObject(…,UserMode…)… Using in
> Kernelmode… seems to work sometimes but again it also causes same bug
> check at times…
>
> I feel this error occurs even before… ISR is called… I checked it
> with
> DbgPrints… or adding breakPoint…
>
> *******
>
> Moreover, i had one doubt… is Driver-Code by default Pageable… or
> Locked… mean the ISR routine… & my other routines too…
>
>
>
> Any inputs are welcome,
>
> Thanx in advance.
>
> SP.
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%

4

is the event on the kernel stack of the waiting thread? If so you
CANNOT do a user-mode wait as the thread stack may get swapped out in
that case. You can just do a kernel-mode wait.

if you are going to do a user-mode wait you also need to be aware that
thread termination will cause the wait to abort with STATUS_USER_APC
(which is a successful completion code) … you need to check for this
case and make sure the event won’t get set after your thread returns.

-p

-----Original Message-----
From: Shailesh [mailto:xxxxx@hotmail.com]
Sent: Wednesday, September 04, 2002 4:48 AM
To: NT Developers Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I am developing a Win2k Device Driver for a PCI NIC.

I have a case wherein one of my routines… waits on a waitobject… This
is signalled in my DpcForIsr() which is called when interrupt is
generated for my device.

But I face the following problem… my initial routines goes into wait
state sucessfully… & there is no problem until the interrupt is
generated. however … as soon as interrupt is generated… I get
following bug check

MM:**PAGE FAULT AT IRQL > 1 Va ED0646E0, IRQL 9

***Fatal System Error: 0x000000d1
(0xED0646E0,0x0000009,0x0000000,0xED0646E0)
Hard Coded Break Point.

I’ve compared the address …is not of by wait_object or wait_time
variable. I’am using KeWaitForSingleObject(…,UserMode…)… Using in
Kernelmode… seems to work sometimes but again it also causes same bug
check at times…

I feel this error occurs even before… ISR is called… I checked it with
DbgPrints… or adding breakPoint…

*************************

Moreover, i had one doubt… is Driver-Code by default Pageable… or
Locked… mean the ISR routine… & my other routines too…

******************

Any inputs are welcome,

Thanx in advance.

SP.

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

5

… NO No… my wait object is not on stack… it’s in the Device Extension
of the device object my driver created… i just take the addr of it in my
local variable in my first routine… & pass it to the call
KeWaitForSingleObject… that’s why i guessed, i sould be able to work
specifying “UserMode”.

I guess i’ve created another confusion here… The system crashes even
before entering the ISR… or for that reason DPC… I’ve checked it with
DbgPrints… & ASSERT macros… but also the system doesn’t crash the moment
I call KeWaitForSingleObject()… infact it crashes only after my device
gives interrupt… that’s for sure too… (also the IRQL is 9… i.e. my
device’s)

Thanx,

S.P.

6

OK, then it would appear that your events and waits are probably not the
problem. Perhaps you should show us the stack from the crash, the
bugcheck code, the output from analyze -v, your ISR, etc.

However, I do have to ask if you have tried using both Executive and
KernelMode for your wait.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Shailesh”
To: “NT Developers Interest List”
Date: Thu, 5 Sep 2002 01:17:08 -0400
Subject: [ntdev] RE: DRIVER_IRQL_NOT_LESS_OR_EQUAL

> … NO No… my wait object is not on stack… it’s in the Device
> Extension
> of the device object my driver created… i just take the addr of it in
> my
> local variable in my first routine… & pass it to the call
> KeWaitForSingleObject… that’s why i guessed, i sould be able to work
> specifying “UserMode”.
>
> I guess i’ve created another confusion here… The system crashes even
> before entering the ISR… or for that reason DPC… I’ve checked it with
> DbgPrints… & ASSERT macros… but also the system doesn’t crash the
> moment
> I call KeWaitForSingleObject()… infact it crashes only after my device
> gives interrupt… that’s for sure too… (also the IRQL is 9… i.e. my
> device’s)
>
> Thanx,
>
> ------
> S.P.
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%

7

==> I’ve tried using UserMode… but at that time second parameter was
anyways… UserRequest… & not Executive… will that matter… ==========
**** Yes but that really had changed the behaviour a lot… i mean the
system didn’t crash that frequently… as it is with UserMode… but the
problem though not consistent… used to occur at times…(& at the same
place!!) so i thought… i would better pin-point it.

Regarding stack trace => if i try running !analyze Dbg displays some
module missing so i’ll first try & load it from somewhere… & then run the
command to get the stack trace…

Thanx, & ==>i’ll try now giving Executive & KernelMode

S.P.

8

Hi all,

I was using functions:

ExInterlockedRemoveHeadList
and
IoGetCurrentIrpStackLocation

in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this should be
ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.

Any comments?

Thanks!
Yuanhui

9

are you at dispatch_level when the crash occurs? Is the routine
touching paged memory while at dispatch level?

-p

-----Original Message-----
From: Yuanhui Zhao [mailto:xxxxx@nexland.com]
Sent: Thursday, September 05, 2002 7:04 AM
To: NT Developers Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi all,

I was using functions:

ExInterlockedRemoveHeadList
and
IoGetCurrentIrpStackLocation

in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this should
be ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.

Any comments?

Thanks!
Yuanhui

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

10

“Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
>
> I was using functions:
>
> ExInterlockedRemoveHeadList
> and
> IoGetCurrentIrpStackLocation
>
> in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this should
be
> ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> Any comments?
>

Yes: It’s not either of these functions that’s causing the problem, though
the problem could be with the POINTERS you’re passing in to these functions,
obviously.

I’d recommend you get in the debugger, and discover what’s causing the
crash… Sorry, nobody on the list can read minds. At least, not as far as
I know.

Peter
OSR

11

Peter,

Yes, it’s at dispatch_level. It’s touching paged memory. Now
MmGetSystemAddressForMdlSafe(irp->MdlAddress, NormalPagePriority)
and
NdisMoveMappedMemory
Also give me this problem.

I was porting some code from NDIS packet sample to my driver(PCAUSA indeed).
This is the start part of DeviceInit:

NTSTATUS DeviceInit

IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
UNICODE_STRING DeviceName;
UNICODE_STRING SymbolicLinkName;
PDEVICE_OBJECT DeviceObject = NULL;
UINT Counter = 0;
NTSTATUS Status = STATUS_SUCCESS;

POPEN_INSTANCE open = NULL;

Globals.DriverObject = DriverObject;

// Initialize device name string
RtlInitUnicodeString ( &DeviceName, L"\Device\Ndishk" );

// Create new device
Status = IoCreateDevice (
DriverObject,
sizeof(OPEN_INSTANCE),
&DeviceName,
FILE_DEVICE_NETWORK,
0,
FALSE,
&DeviceObject
);

open = (POPEN_INSTANCE) DeviceObject->DeviceExtension;
open->DeviceObject = DeviceObject;

The OPEN_INSTANCE I just copied from packet. Now I am suspicious the open
instance is not initialized successfully.

This is the debug information: Thank you for any comments!

kd> !analyze -v

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pagable (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: 00000008, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: fc699ee8, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000008

CURRENT_IRQL: 2

FAULTING_IP:

ndishk!TCPIP_ReceiveHandler+1d7

fc699ee8 8b4240 mov eax,[edx+0x40]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Thursday, September 05, 2002 11:54 AM
Subject: [ntdev] RE: DRIVER_IRQL_NOT_LESS_OR_EQUAL

are you at dispatch_level when the crash occurs? Is the routine
touching paged memory while at dispatch level?

-p

-----Original Message-----
From: Yuanhui Zhao [mailto:xxxxx@nexland.com]
Sent: Thursday, September 05, 2002 7:04 AM
To: NT Developers Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi all,

I was using functions:

ExInterlockedRemoveHeadList
and
IoGetCurrentIrpStackLocation

in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this should
be ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.

Any comments?

Thanks!
Yuanhui

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@nexland.com
To unsubscribe send a blank email to %%email.unsub%%

12

The crash is a result of a null pointer reference.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Yuanhui Zhao”
To: “NT Developers Interest List”
Date: Thu, 5 Sep 2002 15:48:25 -0400
Subject: [ntdev] RE: DRIVER_IRQL_NOT_LESS_OR_EQUAL

> Peter,
>
> Yes, it’s at dispatch_level. It’s touching paged memory. Now
> MmGetSystemAddressForMdlSafe(irp->MdlAddress, NormalPagePriority)
> and
> NdisMoveMappedMemory
> Also give me this problem.
>
> I was porting some code from NDIS packet sample to my driver(PCAUSA
> indeed).
> This is the start part of DeviceInit:
> -----------------------------------------------------------------------
> -----
> ---------------
> NTSTATUS DeviceInit
>
> IN PDRIVER_OBJECT DriverObject,
> IN PUNICODE_STRING RegistryPath
> )
> {
> UNICODE_STRING DeviceName;
> UNICODE_STRING SymbolicLinkName;
> PDEVICE_OBJECT DeviceObject = NULL;
> UINT Counter = 0;
> NTSTATUS Status = STATUS_SUCCESS;
>
> POPEN_INSTANCE open = NULL;
>
> Globals.DriverObject = DriverObject;
>
> // Initialize device name string
> RtlInitUnicodeString ( &DeviceName, L"\Device\Ndishk" );
>
> // Create new device
> Status = IoCreateDevice (
> DriverObject,
> sizeof(OPEN_INSTANCE),
> &DeviceName,
> FILE_DEVICE_NETWORK,
> 0,
> FALSE,
> &DeviceObject
> );
>
> open = (POPEN_INSTANCE) DeviceObject->DeviceExtension;
> open->DeviceObject = DeviceObject;
> -----------------------------------------------------------------------
> -----
> ---------
> The OPEN_INSTANCE I just copied from packet. Now I am suspicious the
> open
> instance is not initialized successfully.
>
> This is the debug information: Thank you for any comments!
>
> kd> !analyze -v
>
> *
>
>
>
> *
>
> * Bugcheck Analysis
>
> *
>
>
> **
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
>
> An attempt was made to access a pagable (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: 00000008, memory referenced
>
> Arg2: 00000002, IRQL
>
> Arg3: 00000000, value 0 = read operation, 1 = write operation
>
> Arg4: fc699ee8, address which referenced memory
>
> Debugging Details:
>
> ------------------
>
>
>
> READ_ADDRESS: 00000008
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
>
> ndishk!TCPIP_ReceiveHandler+1d7
>
> fc699ee8 8b4240 mov eax,[edx+0x40]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
>
>
>
>
>
> ----- Original Message -----
> From: “Peter Wieland”
> To: “NT Developers Interest List”
> Sent: Thursday, September 05, 2002 11:54 AM
> Subject: [ntdev] RE: DRIVER_IRQL_NOT_LESS_OR_EQUAL
>
>
> are you at dispatch_level when the crash occurs? Is the routine
> touching paged memory while at dispatch level?
>
> -p
>
> -----Original Message-----
> From: Yuanhui Zhao [mailto:xxxxx@nexland.com]
> Sent: Thursday, September 05, 2002 7:04 AM
> To: NT Developers Interest List
> Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL
>
>
> Hi all,
>
> I was using functions:
>
> ExInterlockedRemoveHeadList
> and
> IoGetCurrentIrpStackLocation
>
> in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this
> should
> be ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> Any comments?
>
> Thanks!
> Yuanhui
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nexland.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%

13

“Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
>
> This is all the information from my winDbg:
>

As Mr. Roddy said, it’s a NULL pointer deref. Look at the code in your
driver around:

ndishk!TCPIP_ReceiveHandler+0x1d7 [C:\NDISPIM\BASE\NTPIMEB\mstcpip.c @ 856]

I’m thinkin’ that’s where you’ll find the problem…

Peter
OSR

14

Thanks Peter and Mark,

Yes. It’s this problem. I guess this is because I used DeviceExtension,
which in DDK is just PVOID. From samples in Oney’s book, I find
DEVICE_EXTENSION could include a variety of stuffs. Can any of you give me
an idea of what should be included generally in DEVICE_EXTENSION struct?

Thanks a lot!
Yuanhui

----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Thursday, September 05, 2002 1:57 PM
Subject: [ntdev] Re: DRIVER_IRQL_NOT_LESS_OR_EQUAL

> “Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
> >
> > I was using functions:
> >
> > ExInterlockedRemoveHeadList
> > and
> > IoGetCurrentIrpStackLocation
> >
> > in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this should
> be
> > ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.
> >
> > Any comments?
> >
>
> Yes: It’s not either of these functions that’s causing the problem, though
> the problem could be with the POINTERS you’re passing in to these
functions,
> obviously.
>
> I’d recommend you get in the debugger, and discover what’s causing the
> crash… Sorry, nobody on the list can read minds. At least, not as far
as
> I know.
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nexland.com
> To unsubscribe send a blank email to %%email.unsub%%
>

15

Anything you need or would normally sock away into global memory. Since you
want to keep global memory usage to those times when you absolutely can’t
get away from it, nearly all of your storage will be either contained or
pointed to by pointers in your device extension.

Gary G. Little
909-551-2105
909-698-3191

“Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
>
> Thanks Peter and Mark,
>
> Yes. It’s this problem. I guess this is because I used DeviceExtension,
> which in DDK is just PVOID. From samples in Oney’s book, I find
> DEVICE_EXTENSION could include a variety of stuffs. Can any of you give me
> an idea of what should be included generally in DEVICE_EXTENSION struct?
>
> Thanks a lot!
> Yuanhui
>
> ----- Original Message -----
> From: “Peter Viscarola”
> Newsgroups: ntdev
> To: “NT Developers Interest List”
> Sent: Thursday, September 05, 2002 1:57 PM
> Subject: [ntdev] Re: DRIVER_IRQL_NOT_LESS_OR_EQUAL
>
>
> > “Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
> > >
> > > I was using functions:
> > >
> > > ExInterlockedRemoveHeadList
> > > and
> > > IoGetCurrentIrpStackLocation
> > >
> > > in a routine whose IRQL <= DISPATCH_LEVEL, accordint to DDK, this
should
> > be
> > > ok. But my system crashes with error DRIVER_IRQL_NOT_LESS_OR_EQUAL.
> > >
> > > Any comments?
> > >
> >
> > Yes: It’s not either of these functions that’s causing the problem,
though
> > the problem could be with the POINTERS you’re passing in to these
> functions,
> > obviously.
> >
> > I’d recommend you get in the debugger, and discover what’s causing the
> > crash… Sorry, nobody on the list can read minds. At least, not as
far
> as
> > I know.
> >
> > Peter
> > OSR
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@nexland.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>