Tech Support > Microsoft Windows > Drivers > IRQL_NOT_LESS_OR_EQUAL at KeWaitForMultipleObjects
IRQL_NOT_LESS_OR_EQUAL at KeWaitForMultipleObjects
Posted by Min Wang on September 10th, 2004


Hi all,

My file system filter driver has worked well for several months, but my PC
got a sudden crash yesterday. Following is the crash minidump:

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 83a46f8c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e5037, address which referenced memory

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

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


READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MiSessionPoolStart
unable to get nt!MiSessionPoolEnd
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
83a46f8c

CURRENT_IRQL: 2

FAULTING_IP:
nt+d037
804e5037 803f02 cmp byte ptr [edi],0x2

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from f872f721 to 804e5037

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f5577948 f872f721 00000003 f557797c 00000001 nt+0xd037
f557799c f872fd37 82254bf8 83a46f7c 83a46f8c fortimon+0x721
f55779e0 804e4d77 82254b40 83a6ae28 806ef2e8 fortimon+0xd37
f5577a14 80571f9c 822d1e18 81e0afd4 f5577bbc nt+0xcd77
f5577af4 8056486c 822d1e30 00000000 81e0af30 nt+0x99f9c
f5577b7c 80568c63 00000000 f5577bbc 00000040 nt+0x8c86c
f5577bd0 80572fbc 00000000 00000000 804e4c01 nt+0x90c63
f5577d54 804e006b 01dae63c 01dae614 01dae668 nt+0x9afbc
f5577d64 7c92eb94 badb0d00 01dae600 00000000 nt+0x806b
01dae668 00000000 00000000 00000000 00000000 0x7c92eb94


FOLLOWUP_IP:
fortimon+721
f872f721 ?? ???

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fortimon+721

MODULE_NAME: fortimon

IMAGE_NAME: fortimon.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 413e6813

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

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


It seems the crash is caused by a call before fortimon+721. I use w32dasm to
see what is it:

* Reference To: ntoskrnl.KeWaitForMultipleObjects, Ord:0212h
:0001071B FF15A8360100 Call dword ptr [000136A8]
:00010721 8BF8 mov edi, eax

It seems it's caused by KeWaitForMultipleObjects. Here is my code:

PVOID objects[3];
__int64 TimeOut = -(__int64)(15 * 10000000); // 15 seconds

WaitStatus = KeWaitForMultipleObjects(
3,
objects,
WaitAny,
Executive,
KernelMode,
FALSE,
(LARGE_INTEGER *)&TimeOut,
NULL
);

In which _objects_ is an array of pointers to 3 event objects which are
allocated from paged pool. Would this be the problem of the BSOD?

And why the code at fortimon+721 is '??'?

Thanks,
Min


Posted by Maxim S. Shatskih on September 10th, 2004


Reproduce with correct kernel symbols. Use Symbol Server for simplicity if you
have good (DSL quality) Internet.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Posted by Min Wang on September 11th, 2004


The BSOD is very hard to reproduce. I hadn't have this problem for over 6
months until yesterday.

The only thing I have is a minidump file. I opened it with windbg, connect
to symbol server and it turned out that the crash is from
nt!KeWaitForMultipleObjects+0xd4 which is called by my routine. And the only
suspectable parameter is the array of pointers of event object which is
allocated from paged pool.

Thanks,
Min

"Maxim S. Shatskih" <maxim@storagecraft.com> дÈëÓʼþ
news:eEObDD4lEHA.748@TK2MSFTNGP15.phx.gbl...


Posted by Doron Holan [MS] on September 11th, 2004


you are waiting at dispatch level and blocking on that wait. You can only
block at passive or APC level.

From the debugger:
d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Min Wang" <minwang_2003@hotmail.com> wrote in message
news:Fro0d.175494$X12.173758@edtnps84...


Posted by Min Wang on September 11th, 2004


I block in IRP_MJ_CREATE of my file system filter driver. It is passive
level.


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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 83a46f8c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e5037, address which referenced memory

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

Unable to load image fortimon.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for fortimon.sys

READ_ADDRESS: 83a46f8c

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeWaitForMultipleObjects+d4
804e5037 803f02 cmp byte ptr [edi],0x2

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from f872f721 to 804e5037

STACK_TEXT:
f5577948 f872f721 00000003 f557797c 00000001
nt!KeWaitForMultipleObjects+0xd4
f557799c f872fd37 82254bf8 83a46f7c 83a46f8c fortimon!BlockAndScan+0x6d
[c:\projects\fortimon\fortimon.c @ 278]
f55779e0 804e4d77 82254b40 83a6ae28 806ef2e8
fortimon!FortiMonCreateDispatch+0x23f [c:\projects\fortimon\fortimon.c @
772]
f55779f0 8066b2c5 83a6ae38 83a6ae28 f5577cc0 nt!IopfCallDriver+0x31
f5577a14 80571f9c 822d1e18 81e0afd4 f5577bbc nt!IovCallDriver+0xa0
f5577af4 8056486c 822d1e30 00000000 81e0af30 nt!IopParseDevice+0xa58
f5577b7c 80568c63 00000000 f5577bbc 00000040 nt!ObpLookupObjectName+0x56a
f5577bd0 80572fbc 00000000 00000000 804e4c01 nt!ObOpenObjectByName+0xeb
f5577d54 804e006b 01dae63c 01dae614 01dae668 nt!NtQueryAttributesFile+0xf1
f5577d54 7c92eb94 01dae63c 01dae614 01dae668 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
01dae5f4 00000000 00000000 00000000 00000000 0x7c92eb94


FOLLOWUP_IP:
fortimon!BlockAndScan+6d [c:\projects\fortimon\fortimon.c @ 278]
f872f721 ?? ???

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fortimon!BlockAndScan+6d

MODULE_NAME: fortimon

IMAGE_NAME: fortimon.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 413e6813

STACK_COMMAND: kb

BUCKET_ID: 0xA_fortimon!BlockAndScan+6d

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

"Doron Holan [MS]" <doronh@nospam.microsoft.com> дÈëÓʼþ
news:O3TUGg5lEHA.2680@TK2MSFTNGP15.phx.gbl...


Posted by Alexander Grigoriev on September 11th, 2004


IRQL at the crash moment is not the same as at Wait call.

I think the crash is because the array of object pointers is allocated from
pageable memory. The wait array in the thread object is filled at
DISPATCH_LEVEL.

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:O3TUGg5lEHA.2680@TK2MSFTNGP15.phx.gbl...


Posted by Mark Roddy on September 11th, 2004


In article <1tr0d.175531$X12.17105@edtnps84>, minwang_2003@hotmail.com
says...

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com

Posted by on September 11th, 2004




"Min Wang" <minwang_2003@hotmail.com> wrote in message
news:Fro0d.175494$X12.173758@edtnps84...


Posted by Tim Roberts on September 13th, 2004


"Min Wang" <minwang_2003@hotmail.com> wrote:
It starts out passive, but you're raising it somehow.

But KeWaitForMultipleObjects was called from BlockAndScan, which IS your
code. Something in either FortimonCreateDispatch or BlockAndScan is
raising the IRQL. Do you acquire a spinlock in either routine? Acquiring
a spinlock raises your IRQL to DISPATCH_LEVEL. You can't wait with a
spinlock.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc


Similar Posts