Help!! Got stuck debugging this panic

I am writing a sample driver that sends IOCTLS to another test driver for
processing. The IRP for the IOCTL is created using
*IoBuildDeviceIoControlRequest.
*The Test driver is receiving and processing the IRP successfully. However
the system panics when the test driver completes the IRP.

Some information from the dump…

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: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fcf7f, address which referenced memory

1: kd> kv
ChildEBP RetAddr Args to Child
f96ef744 80533fc1 0000000a 00000016 0000001c nt!KeBugCheckEx+0x19 (FPO:
[Non-Fpo])
f96ef744 804fcf7f 0000000a 00000016 0000001c nt!KiTrap0E+0x2b5 (FPO: [0,0]
TrapFrame @ f96ef760)
f96ef7f0 804f582a 00000000 00000000 867a0868 nt!KiWaitTest+0x31 (FPO:
[Non-Fpo])
f96ef800 804f0855 f96efa68 00000000 00000000 nt!KeSetEvent+0x58 (FPO:
[3,0,3])
f96ef858 804f9caf 867a08a8 f96ef8a4 f96ef898 nt!IopCompleteRequest+0x22f
(FPO: [Non-Fpo])
f96ef8a8 806bdd40 00000000 00000000 f96ef8c0 nt!KiDeliverApc+0xb1 (FPO:
[Non-Fpo])
f96ef8a8 806bd964 00000000 00000000 f96ef8c0 HAL_I0!HalpApcInterrupt+0xb0
(FPO: [0,2] TrapFrame @ f96ef8c0)
f96ef930 804f753d 867a08a8 867a0868 00000000
HAL_I0!KeReleaseQueuedSpinLock+0x3c (FPO: [0,0,0])
f96ef950 804ed6e5 867a08a8 00000000 00000000 nt!KeInsertQueueApc+0x6b (FPO:
[Non-Fpo])
f96ef984 80635738 fe7bdb84 867a0868 00000000 nt!IopfCompleteRequest+0x1d7
(FPO: [Non-Fpo])
f96ef9ec f9ce1bcf 804f8584 deadbeef 88878788 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])

1: kd> !irp 867a0868
Irp is active with 1 stacks 3 is current (= 00000000)
No Mdl: System buffer=89578638: Thread 86a283d4: Irp is completed.
cmd flg cl Device File Completion-Context
[e, 0] 0 10 88878788 00000000 00000000-00000000
\Driver\Test
Args: 00000000 00000000 00000000 00000000

1: kd> dt _KEVENT f96efa68
+0x000 Header : _DISPATCHER_HEADER

1: kd> dt _DISPATCHER_HEADER f96efa68
+0x000 Type : 0 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 1
+0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]

All the data looks good. Can somebody tell me the reason behind the panic?

Thanks,
Jing

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jing Bing[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, July 03, 2007 11:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help!! Got stuck debugging this panic

I am writing a sample driver that sends IOCTLS to another test driver for processing. The IRP for the IOCTL is created using IoBuildDeviceIoControlRequest. The Test driver is receiving and processing the IRP successfully. However the system panics when the test driver completes the IRP.

1: kd> dt _KEVENT f96efa68
+0x000 Header : _DISPATCHER_HEADER

1: kd> dt _DISPATCHER_HEADER f96efa68
+0x000 Type : 0 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 1
+0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]

All the data looks good. Can somebody tell me the reason behind the panic?

No, they don’t. A guess – you aren’t initializing Event before passing it to IoBuildDeviceIoControlRequest().

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal, you’ve been quiet for a while.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, July 03, 2007 18:41
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help!! Got stuck debugging this panic


From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Jing Bing[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, July 03, 2007 11:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help!! Got stuck debugging this panic

I am writing a sample driver that sends IOCTLS to another test driver
for processing. The IRP for the IOCTL is created using
IoBuildDeviceIoControlRequest. The Test driver is receiving and
processing the IRP successfully. However the system panics when the test
driver completes the IRP.

1: kd> dt _KEVENT f96efa68
+0x000 Header : _DISPATCHER_HEADER

1: kd> dt _DISPATCHER_HEADER f96efa68
+0x000 Type : 0 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 1
+0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]

All the data looks good. Can somebody tell me the reason behind the
panic?

No, they don’t. A guess – you aren’t initializing Event before passing
it to IoBuildDeviceIoControlRequest().

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Read the output. The exception says that an error occurred during a memory reference, at address 00000016. That’s clearly a bogus address; it’s NULL plus a field offset of 0x16. If you look at the stack, KeSetEvent has been called with a NULL pointer, and then KiWaitTest tried to use that NULL pointer.

You’ll have to investigate where that null pointer is coming from. Show more of the stack. Use “kv 50” to show more stack frames.

Are you sure you’re passing a non-NULL event to IoBuildDeviceIoControlRequest? It looks like the driver completed the request, an APC was scheduled to handle its completion, and then things explode when trying to set that event.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jing Bing
Sent: Tuesday, July 03, 2007 2:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help!! Got stuck debugging this panic

I am writing a sample driver that sends IOCTLS to another test driver for processing. The IRP for the IOCTL is created using IoBuildDeviceIoControlRequest. The Test driver is receiving and processing the IRP successfully. However the system panics when the test driver completes the IRP.

Some information from the dump…

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: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fcf7f, address which referenced memory

1: kd> kv
ChildEBP RetAddr Args to Child
f96ef744 80533fc1 0000000a 00000016 0000001c nt!KeBugCheckEx+0x19 (FPO: [Non-Fpo])
f96ef744 804fcf7f 0000000a 00000016 0000001c nt!KiTrap0E+0x2b5 (FPO: [0,0] TrapFrame @ f96ef760)
f96ef7f0 804f582a 00000000 00000000 867a0868 nt!KiWaitTest+0x31 (FPO: [Non-Fpo])
f96ef800 804f0855 f96efa68 00000000 00000000 nt!KeSetEvent+0x58 (FPO: [3,0,3])
f96ef858 804f9caf 867a08a8 f96ef8a4 f96ef898 nt!IopCompleteRequest+0x22f (FPO: [Non-Fpo])
f96ef8a8 806bdd40 00000000 00000000 f96ef8c0 nt!KiDeliverApc+0xb1 (FPO: [Non-Fpo])
f96ef8a8 806bd964 00000000 00000000 f96ef8c0 HAL_I0!HalpApcInterrupt+0xb0 (FPO: [0,2] TrapFrame @ f96ef8c0)
f96ef930 804f753d 867a08a8 867a0868 00000000 HAL_I0!KeReleaseQueuedSpinLock+0x3c (FPO: [0,0,0])
f96ef950 804ed6e5 867a08a8 00000000 00000000 nt!KeInsertQueueApc+0x6b (FPO: [Non-Fpo])
f96ef984 80635738 fe7bdb84 867a0868 00000000 nt!IopfCompleteRequest+0x1d7 (FPO: [Non-Fpo])
f96ef9ec f9ce1bcf 804f8584 deadbeef 88878788 nt!IovCompleteRequest+0x90 (FPO: [Non-Fpo])

1: kd> !irp 867a0868
Irp is active with 1 stacks 3 is current (= 00000000)
No Mdl: System buffer=89578638: Thread 86a283d4: Irp is completed.
cmd flg cl Device File Completion-Context
[e, 0] 0 10 88878788 00000000 00000000-00000000
\Driver\Test
Args: 00000000 00000000 00000000 00000000

1: kd> dt _KEVENT f96efa68
+0x000 Header : _DISPATCHER_HEADER

1: kd> dt _DISPATCHER_HEADER f96efa68
+0x000 Type : 0 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 1
+0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]

All the data looks good. Can somebody tell me the reason behind the panic?

Thanks,
Jing
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Yeah. I would also have to take issue with the statement that the
_KEVENT data “looks good.” Are you sure you called KeInitializeEvent?
It looks like whatever it is pointing to has not been initialized, as
basically all of it is zeroed, including the size, which is clearly
incorrect.

mm


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, July 03, 2007 19:44
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Help!! Got stuck debugging this panic

Read the output. The exception says that an error occurred during a
memory reference, at address 00000016. That’s clearly a bogus address;
it’s NULL plus a field offset of 0x16. If you look at the stack,
KeSetEvent has been called with a NULL pointer, and then KiWaitTest
tried to use that NULL pointer.

You’ll have to investigate where that null pointer is coming from. Show
more of the stack. Use “kv 50” to show more stack frames.

Are you sure you’re passing a non-NULL event to
IoBuildDeviceIoControlRequest? It looks like the driver completed the
request, an APC was scheduled to handle its completion, and then things
explode when trying to set that event.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jing Bing
Sent: Tuesday, July 03, 2007 2:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help!! Got stuck debugging this panic

I am writing a sample driver that sends IOCTLS to another test driver
for processing. The IRP for the IOCTL is created using
IoBuildDeviceIoControlRequest. The Test driver is receiving and
processing the IRP successfully. However the system panics when the test
driver completes the IRP.

Some information from the dump…

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: 00000016, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fcf7f, address which referenced memory

1: kd> kv
ChildEBP RetAddr Args to Child
f96ef744 80533fc1 0000000a 00000016 0000001c nt!KeBugCheckEx+0x19 (FPO:
[Non-Fpo])
f96ef744 804fcf7f 0000000a 00000016 0000001c nt!KiTrap0E+0x2b5 (FPO:
[0,0] TrapFrame @ f96ef760)
f96ef7f0 804f582a 00000000 00000000 867a0868 nt!KiWaitTest+0x31 (FPO:
[Non-Fpo])
f96ef800 804f0855 f96efa68 00000000 00000000 nt!KeSetEvent+0x58 (FPO:
[3,0,3])
f96ef858 804f9caf 867a08a8 f96ef8a4 f96ef898 nt!IopCompleteRequest+0x22f
(FPO: [Non-Fpo])
f96ef8a8 806bdd40 00000000 00000000 f96ef8c0 nt!KiDeliverApc+0xb1 (FPO:
[Non-Fpo])
f96ef8a8 806bd964 00000000 00000000 f96ef8c0
HAL_I0!HalpApcInterrupt+0xb0 (FPO: [0,2] TrapFrame @ f96ef8c0)
f96ef930 804f753d 867a08a8 867a0868 00000000
HAL_I0!KeReleaseQueuedSpinLock+0x3c (FPO: [0,0,0])
f96ef950 804ed6e5 867a08a8 00000000 00000000 nt!KeInsertQueueApc+0x6b
(FPO: [Non-Fpo])
f96ef984 80635738 fe7bdb84 867a0868 00000000
nt!IopfCompleteRequest+0x1d7 (FPO: [Non-Fpo])
f96ef9ec f9ce1bcf 804f8584 deadbeef 88878788 nt!IovCompleteRequest+0x90
(FPO: [Non-Fpo])

1: kd> !irp 867a0868
Irp is active with 1 stacks 3 is current (= 00000000)
No Mdl: System buffer=89578638: Thread 86a283d4: Irp is completed.
cmd flg cl Device File Completion-Context
[e, 0] 0 10 88878788 00000000 00000000-00000000
\Driver\Test
Args: 00000000 00000000 00000000 00000000

1: kd> dt _KEVENT f96efa68
+0x000 Header : _DISPATCHER_HEADER

1: kd> dt _DISPATCHER_HEADER f96efa68
+0x000 Type : 0 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 1
+0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]

All the data looks good. Can somebody tell me the reason behind the
panic?

Thanks,
Jing
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Do you wait for the event to be signalled after sending the IOCTL in your sample code? If you are not, are you allocating the event object on the stack (looking at the ebp above and the event object pointer, I am willing to guess that might be the case)? If you are allocating the event object on the stack and if you are not waiting for the event to be signalled (after sending the IOCTL), there is a good chance your event object would get corrupted because of stack unwinding.

  • Kamala

Thanks a lot everyone for your help. I initialized the event and everything
works fine now.

Regards,
Jing

On 7/3/07, Michal Vodicka wrote:
>
> > ----------
> > From: xxxxx@lists.osr.com[
> SMTP:xxxxx@lists.osr.com] on behalf of Jing Bing[
> SMTP:xxxxx@gmail.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Tuesday, July 03, 2007 11:19 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Help!! Got stuck debugging this panic
> >
> > I am writing a sample driver that sends IOCTLS to another test driver
> for processing. The IRP for the IOCTL is created using
> IoBuildDeviceIoControlRequest. The Test driver is receiving and processing
> the IRP successfully. However the system panics when the test driver
> completes the IRP.
> >
> > 1: kd> dt _KEVENT f96efa68
> > +0x000 Header : _DISPATCHER_HEADER
> >
> > 1: kd> dt _DISPATCHER_HEADER f96efa68
> > +0x000 Type : 0 ‘’
> > +0x001 Absolute : 0 ‘’
> > +0x002 Size : 0 ‘’
> > +0x003 Inserted : 0 ‘’
> > +0x004 SignalState : 1
> > +0x008 WaitListHead : _LIST_ENTRY [0x0 - 0x0]
> >
> > All the data looks good. Can somebody tell me the reason behind the
> panic?
> >
> No, they don’t. A guess – you aren’t initializing Event before passing it
> to IoBuildDeviceIoControlRequest().
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>