bugcheck during iocompleterequest

Jitesh_Krishnan · December 21, 2010, 6:42pm

fffff8000102e874 : 000000000000000a 0000000000000078 000000000000000c 0000000000000001 : nt!KeBugCheckEx fffff8000102d807 : 0000000000000000 fffffadfbf009d07 fffffadf746cf500 fffffadf74a20830 : nt!KiBugCheckDispatch+0x74
fffff80001030f86 : fffffadf00000000 fffffadf00000000 fffffadf74a20ad0 fffffadf74a20a50 : nt!KiPageFault+0x207 fffff80001025519 : 0000000000000000 0000000000000000 00000000a0000003 fffffadff54f26e0 : nt!KeInsertQueueApc+0x46
fffffadf7461b553 : fffffadf746b0254 0000000000000000 0000000000000000 fffffa8008394af8 : nt!IopfCompleteRequest+0xa26 fffffadf74658688 : fffffa8009ed2298 fffffadff54f26e0 0000000000000000 fffffa8009d06000 : mydriver!mydrivercompleterequest

Hi All,
The above stack is confusing me…
I get a bugcheck
IRQL_NOT_LESS_OR_EQUAL (a)

And the irql is c (12 synch level)
When can this happen…
I have a driver which is calling an iocompleterequest for an irp sent by a higher driver…
The irp from the dump shows complete…

Doron_Holan · December 21, 2010, 6:47pm

You get this type of bugcheck when a non threaded irp (ie one allocated IoAllocateIrp) is completed back to the io manager. are you sure you are not completing an irp you allocated in your driver?

d

Jitesh_Krishnan · December 21, 2010, 6:52pm

nope i dont allocate the irp… it is a driver layered above me that is sending me the irp!!!
I was thinking on the same lines as a non threaded irp… but I’m not sure about the irql where the irp meets it’s doom!

Doron_Holan · December 21, 2010, 6:58pm

ignore the IRQL being reported, that is not the root of anything, it is a side effect of referencing an invalid pointer. are you a filter driver? if so, does the driver above work when your driver is not installed? is your driver a KMDF driver? what type of irp is this?

d

Jitesh_Krishnan · December 21, 2010, 7:23pm

I am a layered driver… and the driver above me needs me always… I don’t know too much about the type of irp… will look at that next!!
This has worked fine for a long time and suddenly I see this…

Jitesh_Krishnan · January 14, 2011, 12:14pm

Hi,
This went on the back-burner for a while due to other critical issues… Looking back at it again…
Anyways Doron can you please help me with this…
The funny things I see with this is
Irp is active with 13 stacks 15 is current (= 0xfffffadff54f2ba0)
No Mdl: System buffer=fffffadfc2ec8d30: Thread fffff80001032fe0: Irp is completed. Pending has been returned
Flags = 00000000

See the stack… Is it because the same irp allocated with IOAllocateIrp has been completed twice…
I am a layered driver and the driver above uses ioallocateirp to allocate the irp which is non-threaded right?
I do an iocomplete request on the irp and I get that panic

Peter_Viscarola_OSR · January 14, 2011, 2:04pm

You’re not passing this request THROUGH to a driver BELOW you, are you?

Just checking and trying to help you narrow-down potential issues,

Peter
OSR

Jitesh_Krishnan · January 14, 2011, 2:22pm

No I am the target driver here… I fill up data requested by the upper driver and complete the irp… Now I read this link
http://blogs.msdn.com/b/doronh/archive/2006/07/27/681179.aspx

where it says if the completion routine of the driver that creates the irp(for a non threaded irp) passes anything but status_more_processing required then iomanager tries to complete the irp which shouldn’t be happening here… and the upper driver’s completion routine doesn’t show in the stack trace which is exactly the case here with me…

I was confused about the irql, which is the side effect of the invalid pointer access(so i ruled it out) and now the stack locations which shows the current stack 15 with 13 stack frames originally allocated to the irp.

1: kd> kb
RetAddr : Args to Child : Call Site
fffff8000102e874 : 000000000000000a 0000000000000078 000000000000000c 0000000000000001 : nt!KeBugCheckEx fffff8000102d807 : 0000000000000000 fffffadfbf009d07 fffffadf746cf500 fffffadf74a20830 : nt!KiBugCheckDispatch+0x74
fffff80001030f86 : fffffadf00000000 fffffadf00000000 fffffadf74a20ad0 fffffadf74a20a50 : nt!KiPageFault+0x207 fffff80001025519 : 0000000000000000 0000000000000000 00000000a0000003 fffffadff54f26e0 : nt!KeInsertQueueApc+0x46
fffffadf7461b553 : fffffadf746b0254 0000000000000000 0000000000000000 fffffa8008394af8 : nt!IopfCompleteRequest+0xa26 fffff8000124e922 : 0000000000000000 0000000000000000 0000000000000000 fffffa8009d05f80 : mydriver!mypassivethread+0x388
fffff80001020516 : fffff800011b4180 fffffadffe5fd040 fffffadfc29c1040 0000000000000000 : nt!PspSystemThreadStartup+0x3e 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

Peter_Viscarola_OSR · January 14, 2011, 2:54pm

Can we see the output from !irp, please?

Are you running under Driver Verifier? If not, enable driver verifier.

Peter
OSR

Jitesh_Krishnan · January 14, 2011, 3:05pm

1: kd> !irp 0xfffffadf`f54f26e0 v
Irp is active with 13 stacks 15 is current (= 0xfffffadff54f2ba0)
No Mdl: System buffer=fffffadfc2ec8d30: Thread fffff80001032fe0: Irp is completed. Pending has been returned
Flags = 00000000
ThreadListEntry.Flink = fffffadff54f2700
ThreadListEntry.Blink = fffffadff54f2700
IoStatus.Status = 00000000
IoStatus.Information = 00000004
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffffadff54f2758
Tail.Overlay.Thread = fffff80001032fe0
Tail.Overlay.AuxiliaryBuffer = fffff8000131bba0
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffffadff54f2ba0
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00580012
Tail.CompletionKey = 00580012
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[e, 0] 0 0 fffffadffe591060 00000000 fffffadf73d8a874-fffffadfc3bf4140
\Driver\mydriver upperdriver!CompletionRoutine
Args: 00000000 00000000 00000000 00000000

I cannot reproduce this issue all the time… I am currently working on replication… and I will use driver verifier!

Peter_Viscarola_OSR · January 14, 2011, 3:19pm

The IRP is certainly threaded.

Hmmm… it’s a device control. And this dump is AFTER your driver has called IoCompleteRequest on the IRP, I suppose?

IoStatus.Status is zero, which is odd if you’ve completed the IRP, IoStatus.Information is 4… can you account for that?

Did your driver complete this IRP asynchronously or synchronously? IOW, I assume you got the request, returned STATUS_PENDING, and then later called IoCompleteRequest?

Peter
OSR

Jitesh_Krishnan · January 14, 2011, 3:37pm

Yes… I completed the irp from an asynchronous context… returning status pending and queuing it to the thread where eventually I complete the request!

The dump is after I complete the irp, yes!

Status is zero because before completion(IoCompleteRequest( pIrp, IO_NO_INCREMENT ) I set the IoStatus.Status = STATUS_SUCCESS
IoStatus.Status = sizeof(ULONG) for the upper driver to do stuff that it does…

Peter_Viscarola_OSR · January 14, 2011, 3:49pm

I’m not exactly Mr. Debugging, to be honest. So my best advice would be to try it under verifier, as you said you were doing already.

Please report back… sorry I can’t be more help,

Peter
OSR

Alex_Grig · January 14, 2011, 4:00pm

Do you call IoMarkIrpPending before you queue it and return STATUS_PENDING?

Jitesh_Krishnan · January 17, 2011, 4:45pm

Yes I did… and I return STATUS_PENDING…
This is a very rarely occurring scenario…