Sorry for the very delayed response. I had to shelve this for some time.
I’ve attached details on irp below.
What puzzles me even more now is, why is this IRP not being shown as active
in my driver. It is instead active in ‘\Driver\scfdriver’. How could this
happen?
This IRP was a TDI connect IRP that came to me. I marked the IRP as
pending, created a new IRP and sent it down. The IRP I sent down never got
completed, so I couldn’t complete this IRP either (I am waiting). Shouldn’t
this IRP be active in my driver when cancellation is called? How could it
be active in some driver above me? Wondering if this could be the root
cause.
BTW, if I completed this IRP before, there will be logs - I am not seeing
any. So, I’m quite sure I didn’t complete this IRP earlier.
1: kd> !irp 0xfffffa8003e0f870 1
Irp is active with 4 stacks 3 is current (= 0xfffffa8003e0f9d0)
No Mdl: No System Buffer: Thread fffffa80081b6b60: Irp stack trace.
Flags = 00062000
ThreadListEntry.Flink = fffffa8003ae3f20
ThreadListEntry.Blink = fffffa8003ae3f20
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000001
Cancel = 01
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 01b3c660
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = fffffa8003ebb344
Overlay.AsynchronousParameters.UserApcContext = 01b3c660
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffffa8003e0f8e8
Tail.Overlay.Thread = fffffa80081b6b60
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffffa8003e0f9d0
Tail.Overlay.OriginalFileObject = fffffa8003ae3e60
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
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
[f, 3] 0 e0 fffffa8006435040 fffffa8008492d30
fffff88001267f00-fffffa8007854f80 Success Error Cancel
\Driver\scfdriver afd!AfdRestartSuperConnect
Args: 00000000 fffffa8007854f80 fffffa8007854e70 fffff880012165e0
[e,31] 5 0 fffffa800613d060 fffffa8003ae3e60 00000000-00000000
\Driver\AFD
Args: 00000000 0000001a 000120c7 034ff790
1: kd> ?? ((PIRP)0xfffffa8003e0f870)
PIRP 0xfffffa8003e0f870 +0x000 Type : 6 +0x002 Size : 0x2c8 +0x008 MdlAddress : (null) +0x010 Flags : 0x62000 +0x018 AssociatedIrp : <unnamed-tag><br> +0x020 ThreadListEntry : _LIST_ENTRY [0xfffffa8003ae3f20 -
0xfffffa8003ae3f20]<br> +0x030 IoStatus : _IO_STATUS_BLOCK<br> +0x040 RequestorMode : 1 ''<br> +0x041 PendingReturned : 0 ''<br> +0x042 StackCount : 4 ''<br> +0x043 CurrentLocation : 3 ''<br> +0x044 Cancel : 0x1 ''<br> +0x045 CancelIrql : 0 ''<br> +0x046 ApcEnvironment : 0 ''<br> +0x047 AllocationFlags : 0x14 ''<br> +0x048 UserIosb : 0x0000000001b3c660 _IO_STATUS_BLOCK
+0x050 UserEvent : (null)
+0x058 Overlay :
+0x068 CancelRoutine : (null)
+0x070 UserBuffer : (null)
+0x078 Tail :
On Fri, Sep 23, 2011 at 3:08 AM, wrote:
> Also, what you print as DEVICE_OBJECT is actually FILE_OBJECT (type 5).
>
> PFILE_OBJECT goes after PDEVICE_OBJECT in IO_STACK_LOCATION. It’s also
> stored near the end of IRP.
>
> Do !Irp debugger command on the IRP you get in your cancel routine and see
> what’s in there.
>
> CurrentStackLocation may point to a tail of IRP, and this is where
> FILE_OBJECT instead of DEVICE_OBJECT is taken from. This is consistent with
> the IRP already completed. Also, because it was not overwritten by KAPC,
> that means the APC was not scheduled.
>
> Post what !irp will give
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>