Prev: Bug Check While Unloading Driver
Next: someone smarter than Dave Cutler
From: Don Burn on 30 Mar 2010 08:55
The standard rule for BSOD questions: "If you are going to post a query
about a BSOD, be sure to have the "!analyze -v" output in the query so
people can help you". IRQL_NOT_LESS_OR_EQUAL is probably the most
generic bug check in windows, if you don't give us more info you will
never get a useful answer, and even if you get a suggestion that stops
the bug check it is probable you are fixing a symptom not the cause. So
come back when you have the information.


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




> -----Original Message-----
> From: uba [mailto:kid07.uba(a)gmail.com]
> Posted At: Tuesday, March 30, 2010 8:40 AM
> Posted To: microsoft.public.development.device.drivers
> Conversation: Bug Check While Unloading Driver
> Subject: Bug Check While Unloading Driver
>
> Hi All,
>
> I had used KeWaitForMultipleObjects, waiting for events to occur
> (indefinitely). So, I had used a WDFWORKITEM and from workitem, I'm
creating a
> system thread using PsCreateSystemThread where I used
> KeWaitForMultipleObjects.
>
> I get a BSOD (IRQL_NOT_LESS_OR_EQUAL (a)) when verifier is turned on
and PnP
> driver test is run when driver is unloaded. In ReleaseHardware I set
the
> event object to signalled state and there by causing a bugcheck at
> KeWaitForMultipleObjects.
>
> As the thread is running at passive level, can't I use
> KeWaitForMultipleObjects in the system thread.
>
> Thanks nd Regards,
> Kid
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 4984 (20100330) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

From: uba on 30 Mar 2010 09:03
I have bug check analysis but I'm not able to trace the problem. Here
is the output.

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

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: 00000000, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation
(only on chips which support this level of status)
Arg4: 81cbf188, address which referenced memory

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


WRITE_ADDRESS: 00000000

CURRENT_IRQL: 1b

FAULTING_IP:
nt!KeWaitForMultipleObjects+396
81cbf188 8902 mov dword ptr [edx],eax

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: 8f1e4c54 -- (.trap 0xffffffff8f1e4c54)
ErrCode = 00000002
eax=8dc09270 ebx=8dc09240 ecx=8dc17f30 edx=00000000 esi=805d1120
edi=8dc091b8
eip=81cbf188 esp=8f1e4cc8 ebp=8f1e4d14 iopl=0 nv up ei ng nz
ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010296
nt!KeWaitForMultipleObjects+0x396:
81cbf188 8902 mov dword ptr [edx],eax ds:
0023:00000000=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 81cd8257 to 81cc3464

STACK_TEXT:
8f1e4814 81cd8257 00000003 46af2106 00000000 nt!
RtlpBreakWithStatusInstruction
8f1e4864 81cd8d3d 00000003 00000000 81cbf188 nt!KiBugCheckDebugBreak
+0x1c
8f1e4c34 81c65d24 0000000a 00000000 0000001b nt!KeBugCheck2+0x66d
8f1e4c34 81cbf188 0000000a 00000000 0000001b nt!KiTrap0E+0x2ac
8f1e4d14 81efa336 00000002 8f1e4d6c 00000000 nt!
KeWaitForMultipleObjects+0x396
8f1e4d44 8efacb8a 00000002 8f1e4d6c 00000000 nt!
VerifierKeWaitForMultipleObjects+0x3f
8f1e4d7c 81de0b18 8dc17e80 46af24a2 00000000 usbfilter!StartRWThread
+0x6a
8f1e4dc0 81c39a2e 8efacb20 8dc17e80 00000000 nt!PspSystemThreadStartup
+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
usbfilter!StartRWThread+6a
8efacb8a 8945f8 mov dword ptr [ebp-8],eax
From: Don Burn on 30 Mar 2010 09:13
Well in all likely hood one of your pointers to KeWaitForMultipleObjects
is NULL or is pointing to an object which has been deleted or had its
memory freed.


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




> -----Original Message-----
> From: uba [mailto:kid07.uba(a)gmail.com]
> Posted At: Tuesday, March 30, 2010 9:04 AM
> Posted To: microsoft.public.development.device.drivers
> Conversation: Bug Check While Unloading Driver
> Subject: Re: Check While Unloading Driver
>
> I have bug check analysis but I'm not able to trace the problem. Here
is the
> output.
>
>
************************************************************************
******
> *
> *
> *
> * Bugcheck
> Analysis *
> *
> *
>
************************************************************************
******
> *
>
> 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: 00000000, memory referenced
> Arg2: 0000001b, IRQL
> Arg3: 00000001, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute
operation (only
> on chips which support this level of status)
> Arg4: 81cbf188, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> WRITE_ADDRESS: 00000000
>
> CURRENT_IRQL: 1b
>
> FAULTING_IP:
> nt!KeWaitForMultipleObjects+396
> 81cbf188 8902 mov dword ptr [edx],eax
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: System
>
> TRAP_FRAME: 8f1e4c54 -- (.trap 0xffffffff8f1e4c54) ErrCode = 00000002
> eax=8dc09270 ebx=8dc09240 ecx=8dc17f30 edx=00000000 esi=805d1120
> edi=8dc091b8
> eip=81cbf188 esp=8f1e4cc8 ebp=8f1e4d14 iopl=0 nv up ei ng nz
> ac pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010296
> nt!KeWaitForMultipleObjects+0x396:
> 81cbf188 8902 mov dword ptr [edx],eax ds:
> 0023:00000000=????????
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 81cd8257 to 81cc3464
>
> STACK_TEXT:
> 8f1e4814 81cd8257 00000003 46af2106 00000000 nt!
> RtlpBreakWithStatusInstruction
> 8f1e4864 81cd8d3d 00000003 00000000 81cbf188 nt!KiBugCheckDebugBreak
> +0x1c
> 8f1e4c34 81c65d24 0000000a 00000000 0000001b nt!KeBugCheck2+0x66d
> 8f1e4c34 81cbf188 0000000a 00000000 0000001b nt!KiTrap0E+0x2ac
> 8f1e4d14 81efa336 00000002 8f1e4d6c 00000000 nt!
> KeWaitForMultipleObjects+0x396
> 8f1e4d44 8efacb8a 00000002 8f1e4d6c 00000000 nt!
> VerifierKeWaitForMultipleObjects+0x3f
> 8f1e4d7c 81de0b18 8dc17e80 46af24a2 00000000 usbfilter!StartRWThread
> +0x6a
> 8f1e4dc0 81c39a2e 8efacb20 8dc17e80 00000000 nt!PspSystemThreadStartup
> +0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> usbfilter!StartRWThread+6a
> 8efacb8a 8945f8 mov dword ptr [ebp-8],eax
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 4984 (20100330) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

From: uba on 30 Mar 2010 11:17

> Well in all likely hood one of your pointers to KeWaitForMultipleObjects
> is NULL or is pointing to an object which has been deleted or had its
> memory freed.
>

Thanks for the reply. You were correct, one of the event object was
NULL. Now it is working fine. But how did the log help in finding that
one of the pointer was NULL. How can I do this kind of analysis.

Thanks nd Regards,
Kid
From: Kalle Olavi Niemitalo on 31 Mar 2010 01:33
uba <kid07.uba(a)gmail.com> writes:

> But how did the log help in finding that one of the pointer was
> NULL. How can I do this kind of analysis.

The log had:

> Arguments:
> Arg1: 00000000, memory referenced

This shows the bug check was because of a null pointer.

> eax=8dc09270 ebx=8dc09240 ecx=8dc17f30 edx=00000000 esi=805d1120 edi=8dc091b8
> eip=81cbf188 esp=8f1e4cc8 ebp=8f1e4d14 iopl=0 nv up ei ng nz ac pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010296
> nt!KeWaitForMultipleObjects+0x396:
> 81cbf188 8902 mov dword ptr [edx],eax ds:0023:00000000=????????

So does this. The instruction "mov dword ptr [edx],eax" tries to
write the value of the eax register to the address given in the
edx register. But "edx=00000000" indicates the value in edx is
zero, i.e. a null pointer. The debugger also shows the null
address in "ds:0023:00000000".

(Diversion:
In other cases, the instruction that causes the exception might
add a constant to the address, e.g. "mov cx, word ptr [esi+6]".
Then, if esi were 00000000 (the null pointer), this instruction
would try to read from address 00000006, which is not itself null
but is pretty close anyway. Instructions like that typically
appear where the source code accesses members of structures.

There are also addressing modes that involve two registers,
as in [ecx+8*ebx+0x12], but those are less frequent. An address
expression like that might appear if the source code is like:

struct Element {
WORD x; /* bytes 0x0 to 0x1 */
WORD y; /* bytes 0x2 to 0x3 */
DWORD z; /* bytes 0x4 to 0x7 */
};
struct Thing {
DWORD a; /* bytes 0x0 to 0x3 */
DWORD b; /* bytes 0x4 to 0x7 */
LARGE_INTEGER c; /* bytes 0x8 to 0xf */
struct Element e[5];
};
struct Thing *p = ...;
DWORD i = ...;
WORD j = p->e[i].y;

If the compiler places struct Thing *p in ecx and DWORD i in ebx,
then the p->e[i].y access can become [ecx+8*ebx+0x12], where the
0x12 is offsetof(struct Thing, e) + offsetof(struct Element, y),
and the 8 is sizeof(struct Element). In addressing modes that
involve multiplication like this, the thing being multiplied is
never a pointer, so don't look for a null pointer there; look
in the other register (if any) instead.
End of diversion.)

I'm not sure how Don Burn knew the null pointer came to
KeWaitForMultipleObjects via the parameters of the individual
call, rather than via corrupted dispatcher data structures.
(A bug in that function itself seems rather unlikely because it
is called very often and Microsoft would have noticed and fixed
the bug already.)
 |  Next  |  Last
Pages: 1 2
Prev: Bug Check While Unloading Driver
Next: someone smarter than Dave Cutler