irp->Tail.Overlay.Thread

Sergei_Vorobiev · September 30, 2010, 4:03pm

I wonder if something wrong is going on here, or is this a behaviour that we should expect.

We decided that in our WDM driver (storage stack filter) we need to account for the IRP’s initiator. Hence we look at ->Tail.Overlay.Thread. THe mystery is that this thing changes right in the middle of our dispatch routine. Basically,

if (irp->Tail.Overlay.Thread != NULL)
{
ASSERT(irp->Tail.Overlay.Thread != NULL);
}

this assert fires. THe current state of the Irp in question is

0: kd> !irp 0x8e538e00
Irp is active with 11 stacks 6 is current (= 0x8e538f24)
Mdl=8cb77218: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
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
[4, 0] 0 10 8c743ac8 00000000 00000000-00000000
\Driver\Disk
Args: 00000000 00000000 00000000 00000023
[4, 0] 0 10 8c73e470 00000000 863474b0-8c5b0870
\DRIVER\VERIFIER_FILTER
Args: 00000000 00000000 00000000 00000023
>[4, 0] 12 0 8c744018 00000000 00000000-8c5930b0
\Driver<us>
Args: 00004000 56530701 3b2f0000 00000023
[4, 0] 12 e0 8c73c5a8 00000000 862ad24e-56530701 Success Error Cancel
\DRIVER\VERIFIER_FILTER partmgr!PmReadWriteCompletion
Args: 00004000 56530701 3b2f0000 00000023
[4, 0] 12 e0 8c7434d8 00000000 862be7a4-8ce35158 Success Error Cancel
\Driver\partmgr volmgr!VmpReadWriteCompletionRoutine
Args: 0ebac2a3 00000005 3b2f0000 00000023
[4, 0] 2 e0 8ce350a0 00000000 86a343e2-8ce41140 Success Error Cancel
\Driver\volmgr fvevol!FvePassThroughCompletion
Args: 00004000 56530701 0ebac288 00000005
[4, 0] 2 e0 8ce41088 00000000 869f5168-00000000 Success Error Cancel
\Driver\fvevol rdyboost!SmdReadWriteCompletion
Args: 00004000 56530701 3b1f0000 00000023
[4, 0] 2 e1 8c7f9490 00000000 869b8a88-8898a840 Success Error Cancel pending
\Driver\rdyboost volsnap!VspPerformanceWrapperCompletionRoutine
Args: 00004000 3fffffff 3b1f0000 00000023

I can state with absolute confidence that we haven’t called IoCallDriver for this IRP yet, and we’re in the dispatch routine.

Other Irps that are on the system that have the same number of stack locations (all that I looked at) are all threaded and point to either one of the system workers or to the worker volsnap!VspWorkerThread. THe thread that ths thing is occuring on is volsnap!VspWorkerThread.

Reiterating, is this normal, or not?

Doron_Holan · September 30, 2010, 4:07pm

Perhaps you are touching another field in the Overlay union which is overwriting Thread? Is Thread even a documented field for you to look at?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, September 30, 2010 1:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] irp->Tail.Overlay.Thread

I wonder if something wrong is going on here, or is this a behaviour that we should expect.

We decided that in our WDM driver (storage stack filter) we need to account for the IRP’s initiator. Hence we look at ->Tail.Overlay.Thread. THe mystery is that this thing changes right in the middle of our dispatch routine. Basically,

if (irp->Tail.Overlay.Thread != NULL)
{
ASSERT(irp->Tail.Overlay.Thread != NULL); }

this assert fires. THe current state of the Irp in question is

0: kd> !irp 0x8e538e00
Irp is active with 11 stacks 6 is current (= 0x8e538f24)
Mdl=8cb77218: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
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
[4, 0] 0 10 8c743ac8 00000000 00000000-00000000
\Driver\Disk
Args: 00000000 00000000 00000000 00000023
[4, 0] 0 10 8c73e470 00000000 863474b0-8c5b0870
\DRIVER\VERIFIER_FILTER
Args: 00000000 00000000 00000000 00000023
>[4, 0] 12 0 8c744018 00000000 00000000-8c5930b0
\Driver<us>
Args: 00004000 56530701 3b2f0000 00000023 [4, 0] 12 e0 8c73c5a8 00000000 862ad24e-56530701 Success Error Cancel
\DRIVER\VERIFIER_FILTER partmgr!PmReadWriteCompletion
Args: 00004000 56530701 3b2f0000 00000023 [4, 0] 12 e0 8c7434d8 00000000 862be7a4-8ce35158 Success Error Cancel
\Driver\partmgr volmgr!VmpReadWriteCompletionRoutine
Args: 0ebac2a3 00000005 3b2f0000 00000023
[4, 0] 2 e0 8ce350a0 00000000 86a343e2-8ce41140 Success Error Cancel
\Driver\volmgr fvevol!FvePassThroughCompletion
Args: 00004000 56530701 0ebac288 00000005
[4, 0] 2 e0 8ce41088 00000000 869f5168-00000000 Success Error Cancel
\Driver\fvevol rdyboost!SmdReadWriteCompletion
Args: 00004000 56530701 3b1f0000 00000023
[4, 0] 2 e1 8c7f9490 00000000 869b8a88-8898a840 Success Error Cancel pending
\Driver\rdyboost volsnap!VspPerformanceWrapperCompletionRoutine
Args: 00004000 3fffffff 3b1f0000 00000023

I can state with absolute confidence that we haven’t called IoCallDriver for this IRP yet, and we’re in the dispatch routine.

Other Irps that are on the system that have the same number of stack locations (all that I looked at) are all threaded and point to either one of the system workers or to the worker volsnap!VspWorkerThread. THe thread that ths thing is occuring on is volsnap!VspWorkerThread.

Reiterating, is this normal, or not?

—
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

Sergei_Vorobiev · September 30, 2010, 4:23pm

> Perhaps you are touching another field in the Overlay union which

is overwriting Thread? Is Thread even a documented field for you to look at?

No I am not touching anything. Yes it is documented.

But you made me thinking: technically, Tail.Overlay.THread is on the same place as Tail.Apc.ApcListEntry.Blink… but there is DriverContext right next to THread (Tail.Overlay.DriverContext[3] is where Tail.Apc.ApcListEntry.Flink is), and I can use it for read-write since the IRP is mine…