BugCheck 0xB8 - IRQL and Completion Routine

Hi again,

So I’m seeing another issue similar to the spinlock being held while calling something else, but this time it’s different. First, this occurred on W7 x64. At some point an IOCTL is tucked away while IRP_MJ_READ/IRP_MJ_WRITE are created and processed with a completion routine setup. While those are processing, a DispatchWrite routine is called and it issues a ExAllocateFromNPagedLookasideList call in mydriver!NewWaitingIRP, verifier is active and you can see what happens as the full stack is below; it ends up calling the completion routine (for the IRP’s that have the IOCTL tucked away). During that completion routine it goes ahead and releases the IOCTL IRP down the stack (no locks, elevation, etc…). and then you see it crash with the 0xB8 and says the IRQL is 2 (DISPATCH_LEVEL). So perhaps the DispatchWrite was called at DISPATCH_LEVEL, which then caused the completion routine and the IoCallDriver to release the IOCTL down the driver stack at that same level, causing the crash??? How do you deal with this? Also, is there a way to get a stack listing showing the IRQL at each point level?

fffff88003793100 fffff80003492f32 : fffff880009b2180 fffffa8006d56680 0000000000000000 0000000000000000 : nt!KiSwapContext+0x7a
fffff88003793240 fffff8000349574f : 0000000000000002 0000000000000000 fffffa8000000000 0000000000000000 : nt!KiCommitThreadWait+0x1d2
fffff880037932d0 fffff8800128fc93 : 0000000000000000 fffffa8000000000 fffffa800db0c000 fffffa800c547700 : nt!KeWaitForSingleObject+0x19f
fffff88003793370 fffff8800128dd6a : fffff98005c36c60 fffff98005c36e98 fffff98000000200 fffffa8000000000 : iaStor+0x4dc93
fffff88003793420 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffffa8008007050 fffffa800e891b80 : iaStor+0x4bd6a
fffff88003793490 fffff880021a0ca0 : 00000000002d9404 00000000002d9404 fffff98005c36c60 fffffa800e891b80 : nt!IovCallDriver+0x566
fffff880037934f0 fffff88002189417 : fffff98005c36f28 0000000000000000 fffff98005c36c60 0000000000000002 : CLASSPNP!ClassDeviceControl+0x310
fffff88003793610 fffff880021a0e7d : 0000000000000002 0000000000000000 0000000000000000 fffffa800dfd5b40 : disk!DiskDeviceControl+0x171
fffff88003793670 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffff98005c36c60 fffff8000392f37e : CLASSPNP!ClassDeviceControlDispatch+0x2d
fffff880037936a0 fffff80003932c42 : fffff98005c36ee0 0000000000000002 fffffa8008436aa0 fffffa800dfd5b40 : nt!IovCallDriver+0x566
fffff88003793700 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffffa8008436950 fffff80003932026 : nt!ViFilterDispatchGeneric+0x62
fffff88003793730 fffff88000ff2183 : fffff98019c26fd0 0000000000000000 0000000000000000 fffffa800dd45b30 : nt!IovCallDriver+0x566
fffff88003793790 fffff88000ff243e : fffff98019c26fd0 0000000000000000 0000000000000000 fffffa800854fc50 : mydriver!ReleasePrimaryIRP+0x9f [c:\mydriver\mydriver.cpp @ 667]
fffff880037937c0 fffff800039355d6 : fffff9801a466fb0 fffff98019c26f02 fffff98019c26fd0 fffff9801a466e50 : mydriver!WriteSectorCompletion+0x13a [v:\mydriver\mydriver.cpp @ 832]
fffff88003793800 fffff80003491021 : fffff9801a466fb3 0000000000000001 0000000000000000 fffff8000354a803 : nt!IovpLocalCompletionRoutine+0x166
fffff88003793860 fffff8000392d19f : fffff9801a466e50 00000000ffffff01 fffffa8008555001 0000000000000000 : nt!IopfCompleteRequest+0x341
fffff88003793950 fffff8800219fbce : fffff88003793c20 fffff9800a498e02 0000000000000004 fffffa8008555010 : nt!IovCompleteRequest+0x19f
fffff88003793a20 fffff800039355d6 : fffffa800bf2ca60 fffffa800bf2ca60 fffff88003793c40 fffff9800a498ea0 : CLASSPNP!TransferPktComplete+0x1ce
fffff88003793aa0 fffff80003491021 : fffff9800a498fbb 0000000000000001 0000000000000000 fffff8000354a803 : nt!IovpLocalCompletionRoutine+0x166
fffff88003793b00 fffff8000392d19f : fffff9800a498ea0 fffff9800a498e00 fffffa800cfed500 0000000000000000 : nt!IopfCompleteRequest+0x341
fffff88003793bf0 fffff8800126edf9 : fffffa800bf2cb80 fffffa800cfed510 fffffa800bf2cb80 fffffa800cfed510 : nt!IovCompleteRequest+0x19f
fffff88003793cc0 fffff88001248a06 : fffff88003793da0 fffffa800811d3f0 fffffa800811d3f0 fffff88003793da0 : iaStor+0x2cdf9
fffff88003793d10 fffff88001248f79 : fffff88003793d01 fffff88003793da0 0000000000000800 fffffa80080f4440 : iaStor+0x6a06
fffff88003793d50 fffff88001248757 : 0000000000000000 0000000000000000 fffffa800ba6da00 00000000000000ff : iaStor+0x6f79
fffff88003793d80 fffff8800126eb08 : fffffa8000000064 0000000000000000 fffff88003764180 fffffa80080f4c38 : iaStor+0x6757
fffff88003793ed0 fffff800034990ac : fffff88003764180 fffffa800b8b6d28 fffffa800b8b6d40 0000000000000000 : iaStor+0x2cb08
fffff88003793f00 fffff80003490765 : 0000000000000000 fffffa8006d56680 0000000000000000 fffff8800126eacc : nt!KiRetireDpcList+0x1bc
fffff88003793fb0 fffff8000349057c : 0000000000000000 0000000000000008 0000000000000000 0000000000000000 : nt!KyRetireDpcList+0x5
fffff88007ebfed0 fffff800034d9993 : fffff80003489ab6 fffff80003489b22 0000000000000000 fffff88007ebff01 : nt!KiDispatchInterruptContinue
fffff88007ebff00 fffff80003489b22 : 0000000000000000 fffff88007ebff01 fffffa800800dcc0 0000006000000011 : nt!KiDpcInterruptBypass+0x13
fffff88007ebff10 fffff8000354a6f9 : 0000000000001254 0000000000000000 fffff88007ec01c0 00000000000012bf : nt!KiInterruptDispatch+0x212
fffff88007ec00a0 fffff8000354a803 : fffffa8007513718 fffff88000000011 fffff98000000000 fffff80000000004 : nt!RtlpWalkFrameChain+0x15a9
fffff88007ec0740 fffff8000354b68b : 0000000000000003 fffffa8007513718 0000000000000000 0000000000000000 : nt!RtlWalkFrameChain+0x63
fffff88007ec0770 fffff8000392402c : fffffa8007513700 0000000000000018 00000000000000c0 0000000000000000 : nt!RtlCaptureStackBackTrace+0x4b
fffff88007ec07a0 fffff8000392609a : fffff88007ebb000 fffff88007ec1000 00000000000000c0 0000000000000018 : nt!ViPoolLogStackCallout+0x1c
fffff88007ec07d0 fffff80003928cc6 : fffffa800d828d80 fffff98014718fe0 fffffa8006c9f550 00000000000000f9 : nt!ViPoolLogStackTrace+0x8a
fffff88007ec0800 fffff80003928d3d : fffffa800854fc50 0000000000000001 fffffa8050524957 fffffa800854fc50 : nt!VeAllocatePoolWithTagPriority+0x2b6
fffff88007ec0870 fffff88000ff2e6a : fffff88000ff7110 0000000000000000 fffffa8000000078 fffff8000392fd86 : nt!VerifierExAllocatePoolEx+0x1d
fffff88007ec08b0 fffff88000ff30bb : fffffa800854fc50 0000000000000002 fffffa800854fc50 fffff9801a582bd0 : mydriver!NewWaitingIRP+0x56 [v:\mydriver\mydriver.cpp @ 1478]
fffff88007ec08e0 fffff80003933c16 : fffffa800854fc50 fffff9801a582bd0 0000000000000002 fffffa800854fb00 : mydriver!DispatchWrite+0xa7 [v:\mydriver\mydriver.cpp @ 1675]
fffff88007ec0930 fffff80003932c42 : fffff9801a582dc0 0000000000000002 fffffa8008550f50 fffffa8007e57a30 : nt!IovCallDriver+0x566
fffff88007ec0990 fffff80003933c16 : fffff9801a582bd0 0000000000000002 fffffa8008550e00 0000000000000002 : nt!ViFilterDispatchGeneric+0x62
fffff88007ec09c0 fffff88000f650af : fffff9801a582bd0 0000000000000002 fffff9801a582e50 fffffa800dfb2f40 : nt!IovCallDriver+0x566
fffff88007ec0a20 fffff80003933c16 : fffff9801a582bd0 fffffa8008550950 fffff9801a582ee0 0000000000000000 : partmgr!PmGlobalDispatch+0x9f
fffff88007ec0a50 fffff88000f7a18c : fffffa8008441a90 0000000000000002 fffff9801a582bd0 fffffa800e8be580 : nt!IovCallDriver+0x566
fffff88007ec0ab0 fffff80003933c16 : 0000000000000002 fffffa800d58b610 fffff9801a582bd0 fffff8000392fbcc : volmgr!VmReadWrite+0x11c
fffff88007ec0af0 fffff8800214f2bf : fffff9801a582bd0 0000000000000002 fffffa8008454940 fffffa800d58b610 : nt!IovCallDriver+0x566
fffff88007ec0b50 fffff8800214f53c : fffffa8008454a90 0000000000000000 fffffa8008454940 0000000000000002 : fvevol!FveReadWrite+0x47
fffff88007ec0b90 fffff8800214f593 : 0000000000000000 fffff9801a582bd0 fffff9801a582f28 fffffa800deacc10 : fvevol!FveFilterRundownReadWrite+0x1dc
fffff88007ec0bf0 fffff80003933c16 : fffff9801a582bd0 0000000000000002 0000000000000000 0000000000000000 : fvevol!FveFilterRundownWrite+0x2f
fffff88007ec0c20 fffff880020a6108 : fffff9801a582bd0 0000000000000002 fffff9801a582f28 fffffa800deacc10 : nt!IovCallDriver+0x566
fffff88007ec0c80 fffff80003933c16 : 0000000000000002 fffffa8008563040 0000000000000000 fffffa8008563040 : volsnap!VolsnapWriteFilter+0xf8
fffff88007ec0cd0 fffff88001a2b39a : fffff88003b7e128 fffff88003b7e1b0 fffffa8006d56680 fffffa800dfae7a0 : nt!IovCallDriver+0x566
fffff88007ec0d30 fffff80003485757 : 0000000000000000 0000000000000000 000000007ef86000 0000000002dffb24 : Ntfs!NtfsStorageDriverCallout+0x16
fffff88007ec0d60 fffff80003485711 : 0000000000000000 0000000000000000 fffff88007ec1000 fffff8000349a7e2 : nt!KxSwitchKernelStackCallout+0x27
fffff88003b7dff0 fffff8000349a7e2 : fffffa800e9b4e00 0000000000000002 fffffa800ca49e40 fffff8a001420c70 : nt!KiSwitchKernelStackContinue
fffff88003b7e010 fffff88001a2af09 : fffff88001a2b384 fffff80003450a1e fffff88000001000 0000000000000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff88003b7e0f0 fffff88001a2a3d6 : fffffa8008585290 0000000000000000 fffff8a001420c70 0000000000000000 : Ntfs!NtfsMultipleAsync+0xa9
fffff88003b7e160 fffff88001a2e5f4 : fffffa800ca49e40 fffff9801a582bd0 0000000000000000 0000000000000000 : Ntfs!NtfsNonCachedIo+0x216
fffff88003b7e2e0 fffff88001a2f1a3 : fffffa800ca49e40 fffff9801a582bd0 fffff88003b7e400 fffff88000001000 : Ntfs!NtfsCommonWrite+0x2d91
fffff88003b7e490 fffff80003933c16 : fffff9801a582bd0 fffff9801a582bd0 fffffa8008583030 fffffa800dfa12a0 : Ntfs!NtfsFsdWrite+0x1c3
fffff88003b7e550 fffff880016c7bcf : fffff9801a582fb8 fffff88003b7e600 fffffa800ccb17a0 fffffa800dfa12a0 : nt!IovCallDriver+0x566
fffff88003b7e5b0 fffff880016c66df : fffffa8008469de0 fffffa8008469de0 fffffa8008469d00 fffff9801a582bd0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88003b7e640 fffff80003933c16 : fffff9801a582bd0 0000000000000002 fffff9801a582bd0 fffffa8006cc6b30 : fltmgr!FltpDispatch+0xcf
fffff88003b7e6a0 fffff8000379621b : 0000000000000001 fffffa800be6cdc0 0000000000000000 fffffa800c9bbcc0 : nt!IovCallDriver+0x566
fffff88003b7e700 fffff800037a0c83 : fffff9801a583000 fffff88003b7e960 fffffa800be6cdc0 fffff88003b7ea00 : nt!IopSynchronousServiceTail+0xfb
fffff88003b7e770 fffff8000348ced3 : 0000000000000000 ffffffff80000cc8 0000000000000000 0000000000000000 : nt!NtWriteFile+0x7e2
fffff88003b7e870 fffff80003489470 : fffff8000372b103 fffffa800d830000 0000000000001000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
fffff88003b7ea78 fffff8000372b103 : fffffa800d830000 0000000000001000 0000000000000000 fffffa800cdf2810 : nt!KiServiceLinkage
fffff88003b7ea80 fffff8000372c203 : ffffffff800003d0 fffff8a01353a8d0 fffff88003b7eb68 fffff88003b7ebe0 : nt!CmpDoFileWrite+0x1f3
fffff88003b7eb40 fffff8000372b791 : fffff88000000000 00000000000045bf 0000000000022df8 fffff8a001426000 : nt!CmpFileWrite+0x2f
fffff88003b7eb70 fffff8000372b99a : 0000000001d65000 0000000000000000 0000000000000000 0000000000000001 : nt!HvWriteDirtyDataToHive+0x161
fffff88003b7ebe0 fffff8000371c567 : 0000000000000000 0000000000000000 0000000000000000 fffff8a000505000 : nt!HvOptimizedSyncHive+0x32
fffff88003b7ec10 fffff8000371c6c9 : 0000000000000000 fffff88003b7ecb8 fffff8000371c600 0000000000010206 : nt!CmpDoFlushNextHive+0x197
fffff88003b7ec70 fffff80003498001 : fffff8000371c624 fffff80003784900 fffffa8000000000 fffff8000362e2b8 : nt!CmpLazyFlushWorker+0xa5

Completion routines can be called at DISPATCH_LEVEL, if you need to do
something at a lower level you need to handle this. You can either
queue a workitem, or have a thread to service this.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@terabyteunlimited.com” wrote in message
news:xxxxx@ntdev:

> Hi again,
>
> So I’m seeing another issue similar to the spinlock being held while calling something else, but this time it’s different. First, this occurred on W7 x64. At some point an IOCTL is tucked away while IRP_MJ_READ/IRP_MJ_WRITE are created and processed with a completion routine setup. While those are processing, a DispatchWrite routine is called and it issues a ExAllocateFromNPagedLookasideList call in mydriver!NewWaitingIRP, verifier is active and you can see what happens as the full stack is below; it ends up calling the completion routine (for the IRP’s that have the IOCTL tucked away). During that completion routine it goes ahead and releases the IOCTL IRP down the stack (no locks, elevation, etc…). and then you see it crash with the 0xB8 and says the IRQL is 2 (DISPATCH_LEVEL). So perhaps the DispatchWrite was called at DISPATCH_LEVEL, which then caused the completion routine and the IoCallDriver to release the IOCTL down the driver stack at that same level, causing the crash??? How do you deal with this? Also, is there a way to get a stack listing showing the IRQL at each point level?
>
>
>
> fffff88003793100 fffff80003492f32 : fffff880009b2180 fffffa8006d56680 0000000000000000 0000000000000000 : nt!KiSwapContext+0x7a
> fffff88003793240 fffff8000349574f : 0000000000000002 0000000000000000 fffffa8000000000 0000000000000000 : nt!KiCommitThreadWait+0x1d2
> fffff880037932d0 fffff8800128fc93 : 0000000000000000 fffffa8000000000 fffffa800db0c000 fffffa800c547700 : nt!KeWaitForSingleObject+0x19f
> fffff88003793370 fffff8800128dd6a : fffff98005c36c60 fffff98005c36e98 fffff98000000200 fffffa8000000000 : iaStor+0x4dc93
> fffff88003793420 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffffa8008007050 fffffa800e891b80 : iaStor+0x4bd6a
> fffff88003793490 fffff880021a0ca0 : 00000000002d9404 00000000002d9404 fffff98005c36c60 fffffa800e891b80 : nt!IovCallDriver+0x566
> fffff880037934f0 fffff88002189417 : fffff98005c36f28 0000000000000000 fffff98005c36c60 0000000000000002 : CLASSPNP!ClassDeviceControl+0x310
> fffff88003793610 fffff880021a0e7d : 0000000000000002 0000000000000000 0000000000000000 fffffa800dfd5b40 : disk!DiskDeviceControl+0x171
> fffff88003793670 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffff98005c36c60 fffff8000392f37e : CLASSPNP!ClassDeviceControlDispatch+0x2d
> fffff880037936a0 fffff80003932c42 : fffff98005c36ee0 0000000000000002 fffffa8008436aa0 fffffa800dfd5b40 : nt!IovCallDriver+0x566
> fffff88003793700 fffff80003933c16 : fffff98005c36c60 0000000000000002 fffffa8008436950 fffff80003932026 : nt!ViFilterDispatchGeneric+0x62
> fffff88003793730 fffff88000ff2183 : fffff98019c26fd0 0000000000000000 0000000000000000 fffffa800dd45b30 : nt!IovCallDriver+0x566
> fffff88003793790 fffff88000ff243e : fffff98019c26fd0 0000000000000000 0000000000000000 fffffa800854fc50 : mydriver!ReleasePrimaryIRP+0x9f [c:\mydriver\mydriver.cpp @ 667]
> fffff880037937c0 fffff800039355d6 : fffff9801a466fb0 fffff98019c26f02 fffff98019c26fd0 fffff9801a466e50 : mydriver!WriteSectorCompletion+0x13a [v:\mydriver\mydriver.cpp @ 832]
> fffff88003793800 fffff80003491021 : fffff9801a466fb3 0000000000000001 0000000000000000 fffff8000354a803 : nt!IovpLocalCompletionRoutine+0x166
> fffff88003793860 fffff8000392d19f : fffff9801a466e50 00000000ffffff01 fffffa8008555001 0000000000000000 : nt!IopfCompleteRequest+0x341
> fffff88003793950 fffff8800219fbce : fffff88003793c20 fffff9800a498e02 0000000000000004 fffffa8008555010 : nt!IovCompleteRequest+0x19f
> fffff88003793a20 fffff800039355d6 : fffffa800bf2ca60 fffffa800bf2ca60 fffff88003793c40 fffff9800a498ea0 : CLASSPNP!TransferPktComplete+0x1ce
> fffff88003793aa0 fffff80003491021 : fffff9800a498fbb 0000000000000001 0000000000000000 fffff8000354a803 : nt!IovpLocalCompletionRoutine+0x166
> fffff88003793b00 fffff8000392d19f : fffff9800a498ea0 fffff9800a498e00 fffffa800cfed500 0000000000000000 : nt!IopfCompleteRequest+0x341
> fffff88003793bf0 fffff8800126edf9 : fffffa800bf2cb80 fffffa800cfed510 fffffa800bf2cb80 fffffa800cfed510 : nt!IovCompleteRequest+0x19f
> fffff88003793cc0 fffff88001248a06 : fffff88003793da0 fffffa800811d3f0 fffffa800811d3f0 fffff88003793da0 : iaStor+0x2cdf9
> fffff88003793d10 fffff88001248f79 : fffff88003793d01 fffff88003793da0 0000000000000800 fffffa80080f4440 : iaStor+0x6a06
> fffff88003793d50 fffff88001248757 : 0000000000000000 0000000000000000 fffffa800ba6da00 00000000000000ff : iaStor+0x6f79
> fffff88003793d80 fffff8800126eb08 : fffffa8000000064 0000000000000000 fffff88003764180 fffffa80080f4c38 : iaStor+0x6757
> fffff88003793ed0 fffff800034990ac : fffff88003764180 fffffa800b8b6d28 fffffa800b8b6d40 0000000000000000 : iaStor+0x2cb08
> fffff88003793f00 fffff80003490765 : 0000000000000000 fffffa8006d56680 0000000000000000 fffff8800126eacc : nt!KiRetireDpcList+0x1bc
> fffff88003793fb0 fffff8000349057c : 0000000000000000 0000000000000008 0000000000000000 0000000000000000 : nt!KyRetireDpcList+0x5
> fffff88007ebfed0 fffff800034d9993 : fffff80003489ab6 fffff80003489b22 0000000000000000 fffff88007ebff01 : nt!KiDispatchInterruptContinue
> fffff88007ebff00 fffff80003489b22 : 0000000000000000 fffff88007ebff01 fffffa800800dcc0 0000006000000011 : nt!KiDpcInterruptBypass+0x13
> fffff88007ebff10 fffff8000354a6f9 : 0000000000001254 0000000000000000 fffff88007ec01c0 00000000000012bf : nt!KiInterruptDispatch+0x212
> fffff88007ec00a0 fffff8000354a803 : fffffa8007513718 fffff88000000011 fffff98000000000 fffff80000000004 : nt!RtlpWalkFrameChain+0x15a9
> fffff88007ec0740 fffff8000354b68b : 0000000000000003 fffffa8007513718 0000000000000000 0000000000000000 : nt!RtlWalkFrameChain+0x63
> fffff88007ec0770 fffff8000392402c : fffffa8007513700 0000000000000018 00000000000000c0 0000000000000000 : nt!RtlCaptureStackBackTrace+0x4b
> fffff88007ec07a0 fffff8000392609a : fffff88007ebb000 fffff88007ec1000 00000000000000c0 0000000000000018 : nt!ViPoolLogStackCallout+0x1c
> fffff88007ec07d0 fffff80003928cc6 : fffffa800d828d80 fffff98014718fe0 fffffa8006c9f550 00000000000000f9 : nt!ViPoolLogStackTrace+0x8a
> fffff88007ec0800 fffff80003928d3d : fffffa800854fc50 0000000000000001 fffffa8050524957 fffffa800854fc50 : nt!VeAllocatePoolWithTagPriority+0x2b6
> fffff88007ec0870 fffff88000ff2e6a : fffff88000ff7110 0000000000000000 fffffa8000000078 fffff8000392fd86 : nt!VerifierExAllocatePoolEx+0x1d
> fffff88007ec08b0 fffff88000ff30bb : fffffa800854fc50 0000000000000002 fffffa800854fc50 fffff9801a582bd0 : mydriver!NewWaitingIRP+0x56 [v:\mydriver\mydriver.cpp @ 1478]
> fffff88007ec08e0 fffff80003933c16 : fffffa800854fc50 fffff9801a582bd0 0000000000000002 fffffa800854fb00 : mydriver!DispatchWrite+0xa7 [v:\mydriver\mydriver.cpp @ 1675]
> fffff88007ec0930 fffff80003932c42 : fffff9801a582dc0 0000000000000002 fffffa8008550f50 fffffa8007e57a30 : nt!IovCallDriver+0x566
> fffff88007ec0990 fffff80003933c16 : fffff9801a582bd0 0000000000000002 fffffa8008550e00 0000000000000002 : nt!ViFilterDispatchGeneric+0x62
> fffff88007ec09c0 fffff88000f650af : fffff9801a582bd0 0000000000000002 fffff9801a582e50 fffffa800dfb2f40 : nt!IovCallDriver+0x566
> fffff88007ec0a20 fffff80003933c16 : fffff9801a582bd0 fffffa8008550950 fffff9801a582ee0 0000000000000000 : partmgr!PmGlobalDispatch+0x9f
> fffff88007ec0a50 fffff88000f7a18c : fffffa8008441a90 0000000000000002 fffff9801a582bd0 fffffa800e8be580 : nt!IovCallDriver+0x566
> fffff88007ec0ab0 fffff80003933c16 : 0000000000000002 fffffa800d58b610 fffff9801a582bd0 fffff8000392fbcc : volmgr!VmReadWrite+0x11c
> fffff88007ec0af0 fffff8800214f2bf : fffff9801a582bd0 0000000000000002 fffffa8008454940 fffffa800d58b610 : nt!IovCallDriver+0x566
> fffff88007ec0b50 fffff8800214f53c : fffffa8008454a90 0000000000000000 fffffa8008454940 0000000000000002 : fvevol!FveReadWrite+0x47
> fffff88007ec0b90 fffff8800214f593 : 0000000000000000 fffff9801a582bd0 fffff9801a582f28 fffffa800deacc10 : fvevol!FveFilterRundownReadWrite+0x1dc
> fffff88007ec0bf0 fffff80003933c16 : fffff9801a582bd0 0000000000000002 0000000000000000 0000000000000000 : fvevol!FveFilterRundownWrite+0x2f
> fffff88007ec0c20 fffff880020a6108 : fffff9801a582bd0 0000000000000002 fffff9801a582f28 fffffa800deacc10 : nt!IovCallDriver+0x566
> fffff88007ec0c80 fffff80003933c16 : 0000000000000002 fffffa8008563040 0000000000000000 fffffa8008563040 : volsnap!VolsnapWriteFilter+0xf8
> fffff88007ec0cd0 fffff88001a2b39a : fffff88003b7e128 fffff88003b7e1b0 fffffa8006d56680 fffffa800dfae7a0 : nt!IovCallDriver+0x566
> fffff88007ec0d30 fffff80003485757 : 0000000000000000 0000000000000000 000000007ef86000 0000000002dffb24 : Ntfs!NtfsStorageDriverCallout+0x16
> fffff88007ec0d60 fffff80003485711 : 0000000000000000 0000000000000000 fffff88007ec1000 fffff8000349a7e2 : nt!KxSwitchKernelStackCallout+0x27
> fffff88003b7dff0 fffff8000349a7e2 : fffffa800e9b4e00 0000000000000002 fffffa800ca49e40 fffff8a001420c70 : nt!KiSwitchKernelStackContinue
> fffff88003b7e010 fffff88001a2af09 : fffff88001a2b384 fffff80003450a1e fffff88000001000 0000000000000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
> fffff88003b7e0f0 fffff88001a2a3d6 : fffffa8008585290 0000000000000000 fffff8a001420c70 0000000000000000 : Ntfs!NtfsMultipleAsync+0xa9
> fffff88003b7e160 fffff88001a2e5f4 : fffffa800ca49e40 fffff9801a582bd0 0000000000000000 0000000000000000 : Ntfs!NtfsNonCachedIo+0x216
> fffff88003b7e2e0 fffff88001a2f1a3 : fffffa800ca49e40 fffff9801a582bd0 fffff88003b7e400 fffff88000001000 : Ntfs!NtfsCommonWrite+0x2d91
> fffff88003b7e490 fffff80003933c16 : fffff9801a582bd0 fffff9801a582bd0 fffffa8008583030 fffffa800dfa12a0 : Ntfs!NtfsFsdWrite+0x1c3
> fffff88003b7e550 fffff880016c7bcf : fffff9801a582fb8 fffff88003b7e600 fffffa800ccb17a0 fffffa800dfa12a0 : nt!IovCallDriver+0x566
> fffff88003b7e5b0 fffff880016c66df : fffffa8008469de0 fffffa8008469de0 fffffa8008469d00 fffff9801a582bd0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff88003b7e640 fffff80003933c16 : fffff9801a582bd0 0000000000000002 fffff9801a582bd0 fffffa8006cc6b30 : fltmgr!FltpDispatch+0xcf
> fffff88003b7e6a0 fffff8000379621b : 0000000000000001 fffffa800be6cdc0 0000000000000000 fffffa800c9bbcc0 : nt!IovCallDriver+0x566
> fffff88003b7e700 fffff800037a0c83 : fffff9801a583000 fffff88003b7e960 fffffa800be6cdc0 fffff88003b7ea00 : nt!IopSynchronousServiceTail+0xfb
> fffff88003b7e770 fffff8000348ced3 : 0000000000000000 ffffffff80000cc8 0000000000000000 0000000000000000 : nt!NtWriteFile+0x7e2
> fffff88003b7e870 fffff80003489470 : fffff8000372b103 fffffa800d830000 0000000000001000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
> fffff88003b7ea78 fffff8000372b103 : fffffa800d830000 0000000000001000 0000000000000000 fffffa800cdf2810 : nt!KiServiceLinkage
> fffff88003b7ea80 fffff8000372c203 : ffffffff800003d0 fffff8a01353a8d0 fffff88003b7eb68 fffff88003b7ebe0 : nt!CmpDoFileWrite+0x1f3
> fffff88003b7eb40 fffff8000372b791 : fffff88000000000 00000000000045bf 0000000000022df8 fffff8a001426000 : nt!CmpFileWrite+0x2f
> fffff88003b7eb70 fffff8000372b99a : 0000000001d65000 0000000000000000 0000000000000000 0000000000000001 : nt!HvWriteDirtyDataToHive+0x161
> fffff88003b7ebe0 fffff8000371c567 : 0000000000000000 0000000000000000 0000000000000000 fffff8a000505000 : nt!HvOptimizedSyncHive+0x32
> fffff88003b7ec10 fffff8000371c6c9 : 0000000000000000 fffff88003b7ecb8 fffff8000371c600 0000000000010206 : nt!CmpDoFlushNextHive+0x197
> fffff88003b7ec70 fffff80003498001 : fffff8000371c624 fffff80003784900 fffffa8000000000 fffff8000362e2b8 : nt!CmpLazyFlushWorker+0xa5

Don, Thanks, that’s good to know. But another question. I recall that DispatchRead/DispatchWrite can also be called at DISPATCH_LEVEL (and APC level if paging file in path). But, how about the DispatchDeviceControl, can that be called above PASSIVE_LEVEL? If so, shouldn’t that underlying driver (iaStor) be able to handle it? I’ll still probably have to do either a worker or queue with some type of release mechanism, but just would like to know.

IOCTL’s can be called at DISPATCH_LEVEL, but a driver write can choose
whether a specific request supports DISPATCH_LEVEL or APC_LEVEL or
requires PASSIVE_LEVEL. So unless you wrote both drivers (or have the
sources at least) assume PASSIVE.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@terabyteunlimited.com” wrote in message
news:xxxxx@ntdev:

> Don, Thanks, that’s good to know. But another question. I recall that DispatchRead/DispatchWrite can also be called at DISPATCH_LEVEL (and APC level if paging file in path). But, how about the DispatchDeviceControl, can that be called above PASSIVE_LEVEL? If so, shouldn’t that underlying driver (iaStor) be able to handle it? I’ll still probably have to do either a worker or queue with some type of release mechanism, but just would like to know.

In that stack trace, your completion routine IS being called at IRQL DISPATCH_LEVEL. Note that you’re in the path from IASTOR’s DPC calling IoCompleteRequest. And it looks like your driver is calling IoCallDriver directly from within that completion routine, which I insist is very naughty. Just LOOK at the size of that stack! Imagine how big the stack would be if IASTOR called IoCompleteRequest again instead of blue screening by calling KeWaitForSingleObject.

Peter
OSR

Thanks Peter. Is there a list that shows where for each dispatch routine which IRQL’s are guaranteed and not guaranteed? I recall reading something at some point that said DispatchRead/Write could be called at DISPATCH level, but the docs don’t say anything about that (only about the APC level):

Most drivers’ dispatch routines are called in an arbitrary thread context at IRQL = PASSIVE_LEVEL, with the following exceptions:

Any highest-level driver’s dispatch routines are called in the context of the thread that originated the I/O request, which is commonly a user-mode application thread.
In other words, the dispatch routines of file system drivers and other highest-level drivers are called in a nonarbitrary thread context at IRQL = PASSIVE_LEVEL.

The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of lowest-level device drivers, and of intermediate drivers layered above them in the system paging path, can be called at IRQL = APC_LEVEL and in an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine that also processes read and/or write requests in such a lowest-level device or intermediate driver, must be resident at all times. These driver routines can neither be pageable nor be part of a driver’s pageable-image section; they must not access any pageable memory. Furthermore, they should not be dependent on any blocking calls (such as KeWaitForSingleObject with a nonzero time-out).

The DispatchPower routine of drivers in the hibernation and/or paging paths can be called at IRQL = DISPATCH_LEVEL. The DispatchPnP routines of such drivers must be prepared to handle PnP IRP_MN_DEVICE_USAGE_NOTIFICATION requests.
The DispatchPower routine of drivers that require inrush power at start-up can be called at IRQL = DISPATCH_LEVEL.

The docs for each routine in a Windows driver indicates the IRQLs at which that routine can be called. For example, for your completion routine:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff548354(v=vs.85).aspx

The docs you show about dispatch routines show why IASTOR blue screened when you called it at IRQL DISPATCH_LEVEL from your completion routine.

The IRQL at which Dispatch routines can be called varies. And the practices vary by branch of the device tree, in terms of which IRQL at which one can expect their dispatch routine to be called. For example, the practices in the storage branch of the device tree might not be the same as those in branch that supports a USB device.

Peter
OSR