newbee DRIVER_IRQL_NOT_LESS_OR_EQUAL problem

P

Paul Mulholland

Hi All,

I am trying to write my first Windows driver, although I have written
Solaris drivers.

The problem is that when the device interrupts I get a
DRIVER_IRQL_NOT_LESS_OR_EQUAL error. The address quoted as the fault
address is in fact the address of the ISR. As far as I am aware all the
code is locked into memory.

I feel it must be something simple I am missing but I don't know what.

Cheers Paul.

Below is the WinDbg output.

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

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 0

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
f77886b0

CURRENT_IRQL: 7

FAULTING_IP:
LaserBus+16b0
f77886b0 ?? ???

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f77886b0 to 805436d0

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
8055031c f77886b0 badb0d00 00000002 00000000 nt!Kei386EoiHelper+0x2834
00000000 00000000 00000000 00000000 00000000 <Unloaded_LaserBus.sys>+0x16b0


STACK_COMMAND: kb

FOLLOWUP_IP:
LaserBus+16b0
f77886b0 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: LaserBus+16b0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: LaserBus

IMAGE_NAME: LaserBus.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
 
D

Don Burn

Without the correct symbols, you are not going to get anywhere. Get the
symbols (use the symbol server) and then put out the question again.
DRIVER_IRQL_NOT_LESS_OR_EQUAL is the most common BSOD a driver can do.


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

Paul Mulholland

Don said:
Without the correct symbols, you are not going to get anywhere. Get the
symbols (use the symbol server) and then put out the question again.
DRIVER_IRQL_NOT_LESS_OR_EQUAL is the most common BSOD a driver can do.
Click to expand...

Thanks Don,

I have done that and get more sensible output (see below).

I am concerned that it thinks it's an unloaded module does that perhaps
have something to do with it? Even though at the time of the crash the
device is open by a test program.

Paul.

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

Debugging Details:
------------------


WRITE_ADDRESS: f77886b0

CURRENT_IRQL: 7

FAULTING_IP:
LaserBus+16b0
f77886b0 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: 8055031c -- (.trap ffffffff8055031c)
ErrCode = 00000010
eax=8626e0e8 ebx=86166474 ecx=86125807 edx=00000002 esi=860fb91c
edi=860fb6b8
eip=f77886b0 esp=80550390 ebp=00000000 iopl=0 nv up ei pl zr na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
<Unloaded_LaserBus.sys>+0x16b0:
f77886b0 ?? ???
Resetting default scope

IP_MODULE_UNLOADED:
LaserBus+16b0
f77886b0 ?? ???

LAST_CONTROL_TRANSFER: from f77886b0 to 805436d0

STACK_TEXT:
8055031c f77886b0 badb0d00 00000002 00000000 nt!KiTrap0E+0x238
WARNING: Frame IP not in any known module. Following frames may be wrong.
8055038c 805444bc 860fb6b8 8626e0e8 804feef4 <Unloaded_LaserBus.sys>+0x16b0
805503b0 80544469 86391e02 00000183 80550450 nt!KiChainedDispatch2ndLvl+0x44
805503b0 f7579062 86391e02 00000183 80550450 nt!KiChainedDispatch+0x29
80550450 80544d2c 00000000 0000000e 00000000 intelppm!AcpiC1Idle+0x12
80550454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x10


STACK_COMMAND: kb

FOLLOWUP_IP:
LaserBus+16b0
f77886b0 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: LaserBus+16b0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: LaserBus

IMAGE_NAME: LaserBus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: 0xD1_W_VRF_LaserBus+16b0

BUCKET_ID: 0xD1_W_VRF_LaserBus+16b0

Followup: MachineOwner
---------
 
W

Will Denny

Hi

Please try the following link to Jim Eshelman's web page - right hand column
(D1)

http://aumha.org/win5/kbestop.htm

--

Will Denny
MS-MVP Shell/User
Please reply to the News Groups


Paul Mulholland said:
Thanks Don,

I have done that and get more sensible output (see below).

I am concerned that it thinks it's an unloaded module does that perhaps
have something to do with it? Even though at the time of the crash the
device is open by a test program.

Paul.
Click to expand...
<snipped>
 
D

Don Burn

Paul,

First use lm in the debugger when the crash occurs to see if your
driver is truly loaded. This looks like an unload without an
IoDisconnectInterupt call. Note: there are a number of bug code sites
such as another poster pointed out, most of them are pretty poor versus the
latest WinDBG documentation and !analyze.


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

Paul Mulholland

Don said:
Paul,

First use lm in the debugger when the crash occurs to see if your
driver is truly loaded. This looks like an unload without an
IoDisconnectInterupt call. Note: there are a number of bug code sites
such as another poster pointed out, most of them are pretty poor versus the
latest WinDBG documentation and !analyze.
Click to expand...

Thanks Don,

It does appear to be something like that, "lm" does report it as an
"Unloaded Module". In fact it always thinks it's unloaded even when I
have just installed the driver and start device has been called.

I can even open have the device and it still reports as an unloaded module.

Paul.
 
P

Paul Mulholland

Paul said:
Thanks Don,

It does appear to be something like that, "lm" does report it as an
"Unloaded Module". In fact it always thinks it's unloaded even when I
have just installed the driver and start device has been called.

I can even open have the device and it still reports as an unloaded module.

Paul.
Click to expand...

Thanks Don,

Your comment about IoDisconnectInterupt hit the nail on the head. I
didn't realise that the StopDevice pnp message was not sent but that I
had to remove the interrupt in the RemoveDevice instead/as well.

Paul.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

rebooted from bugcheck? 2
USB driver not working on windows 7 3
Blue screen: Probably caused by : ntoskrnl.exe ( nt+da947 ) 0
BSoD at Windows Vista during shutdown/restart! PLEASE HELP! 4
Using WinDebug 3
MULTIPLE_IRP_COMPLETE_REQUESTS (44) blue screens recently. 5
Windows TCPIP.SYS problem BLUESCREEN and reboot 8
mini dump analysis -> Probably caused by : hardware ( nt+4832 ) but what hardware??? 1

Top