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 fffff800
03492f32 : fffff880009b2180 fffffa80
06d56680 0000000000000000 00000000
00000000 : nt!KiSwapContext+0x7a
fffff88003793240 fffff800
0349574f : 0000000000000002 00000000
00000000 fffffa8000000000 00000000
00000000 : nt!KiCommitThreadWait+0x1d2
fffff880037932d0 fffff880
0128fc93 : 0000000000000000 fffffa80
00000000 fffffa800db0c000 fffffa80
0c547700 : nt!KeWaitForSingleObject+0x19f
fffff88003793370 fffff880
0128dd6a : fffff98005c36c60 fffff980
05c36e98 fffff98000000200 fffffa80
00000000 : iaStor+0x4dc93
fffff88003793420 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffffa8008007050 fffffa80
0e891b80 : iaStor+0x4bd6a
fffff88003793490 fffff880
021a0ca0 : 00000000002d9404 00000000
002d9404 fffff98005c36c60 fffffa80
0e891b80 : nt!IovCallDriver+0x566
fffff880037934f0 fffff880
02189417 : fffff98005c36f28 00000000
00000000 fffff98005c36c60 00000000
00000002 : CLASSPNP!ClassDeviceControl+0x310
fffff88003793610 fffff880
021a0e7d : 0000000000000002 00000000
00000000 0000000000000000 fffffa80
0dfd5b40 : disk!DiskDeviceControl+0x171
fffff88003793670 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffff98005c36c60 fffff800
0392f37e : CLASSPNP!ClassDeviceControlDispatch+0x2d
fffff880037936a0 fffff800
03932c42 : fffff98005c36ee0 00000000
00000002 fffffa8008436aa0 fffffa80
0dfd5b40 : nt!IovCallDriver+0x566
fffff88003793700 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffffa8008436950 fffff800
03932026 : nt!ViFilterDispatchGeneric+0x62
fffff88003793730 fffff880
00ff2183 : fffff98019c26fd0 00000000
00000000 0000000000000000 fffffa80
0dd45b30 : nt!IovCallDriver+0x566
fffff88003793790 fffff880
00ff243e : fffff98019c26fd0 00000000
00000000 0000000000000000 fffffa80
0854fc50 : mydriver!ReleasePrimaryIRP+0x9f [c:\mydriver\mydriver.cpp @ 667]
fffff880037937c0 fffff800
039355d6 : fffff9801a466fb0 fffff980
19c26f02 fffff98019c26fd0 fffff980
1a466e50 : mydriver!WriteSectorCompletion+0x13a [v:\mydriver\mydriver.cpp @ 832]
fffff88003793800 fffff800
03491021 : fffff9801a466fb3 00000000
00000001 0000000000000000 fffff800
0354a803 : nt!IovpLocalCompletionRoutine+0x166
fffff88003793860 fffff800
0392d19f : fffff9801a466e50 00000000
ffffff01 fffffa8008555001 00000000
00000000 : nt!IopfCompleteRequest+0x341
fffff88003793950 fffff880
0219fbce : fffff88003793c20 fffff980
0a498e02 0000000000000004 fffffa80
08555010 : nt!IovCompleteRequest+0x19f
fffff88003793a20 fffff800
039355d6 : fffffa800bf2ca60 fffffa80
0bf2ca60 fffff88003793c40 fffff980
0a498ea0 : CLASSPNP!TransferPktComplete+0x1ce
fffff88003793aa0 fffff800
03491021 : fffff9800a498fbb 00000000
00000001 0000000000000000 fffff800
0354a803 : nt!IovpLocalCompletionRoutine+0x166
fffff88003793b00 fffff800
0392d19f : fffff9800a498ea0 fffff980
0a498e00 fffffa800cfed500 00000000
00000000 : nt!IopfCompleteRequest+0x341
fffff88003793bf0 fffff880
0126edf9 : fffffa800bf2cb80 fffffa80
0cfed510 fffffa800bf2cb80 fffffa80
0cfed510 : nt!IovCompleteRequest+0x19f
fffff88003793cc0 fffff880
01248a06 : fffff88003793da0 fffffa80
0811d3f0 fffffa800811d3f0 fffff880
03793da0 : iaStor+0x2cdf9
fffff88003793d10 fffff880
01248f79 : fffff88003793d01 fffff880
03793da0 0000000000000800 fffffa80
080f4440 : iaStor+0x6a06
fffff88003793d50 fffff880
01248757 : 0000000000000000 00000000
00000000 fffffa800ba6da00 00000000
000000ff : iaStor+0x6f79
fffff88003793d80 fffff880
0126eb08 : fffffa8000000064 00000000
00000000 fffff88003764180 fffffa80
080f4c38 : iaStor+0x6757
fffff88003793ed0 fffff800
034990ac : fffff88003764180 fffffa80
0b8b6d28 fffffa800b8b6d40 00000000
00000000 : iaStor+0x2cb08
fffff88003793f00 fffff800
03490765 : 0000000000000000 fffffa80
06d56680 0000000000000000 fffff880
0126eacc : nt!KiRetireDpcList+0x1bc
fffff88003793fb0 fffff800
0349057c : 0000000000000000 00000000
00000008 0000000000000000 00000000
00000000 : nt!KyRetireDpcList+0x5
fffff88007ebfed0 fffff800
034d9993 : fffff80003489ab6 fffff800
03489b22 0000000000000000 fffff880
07ebff01 : nt!KiDispatchInterruptContinue
fffff88007ebff00 fffff800
03489b22 : 0000000000000000 fffff880
07ebff01 fffffa800800dcc0 00000060
00000011 : nt!KiDpcInterruptBypass+0x13
fffff88007ebff10 fffff800
0354a6f9 : 0000000000001254 00000000
00000000 fffff88007ec01c0 00000000
000012bf : nt!KiInterruptDispatch+0x212
fffff88007ec00a0 fffff800
0354a803 : fffffa8007513718 fffff880
00000011 fffff98000000000 fffff800
00000004 : nt!RtlpWalkFrameChain+0x15a9
fffff88007ec0740 fffff800
0354b68b : 0000000000000003 fffffa80
07513718 0000000000000000 00000000
00000000 : nt!RtlWalkFrameChain+0x63
fffff88007ec0770 fffff800
0392402c : fffffa8007513700 00000000
00000018 00000000000000c0 00000000
00000000 : nt!RtlCaptureStackBackTrace+0x4b
fffff88007ec07a0 fffff800
0392609a : fffff88007ebb000 fffff880
07ec1000 00000000000000c0 00000000
00000018 : nt!ViPoolLogStackCallout+0x1c
fffff88007ec07d0 fffff800
03928cc6 : fffffa800d828d80 fffff980
14718fe0 fffffa8006c9f550 00000000
000000f9 : nt!ViPoolLogStackTrace+0x8a
fffff88007ec0800 fffff800
03928d3d : fffffa800854fc50 00000000
00000001 fffffa8050524957 fffffa80
0854fc50 : nt!VeAllocatePoolWithTagPriority+0x2b6
fffff88007ec0870 fffff880
00ff2e6a : fffff88000ff7110 00000000
00000000 fffffa8000000078 fffff800
0392fd86 : nt!VerifierExAllocatePoolEx+0x1d
fffff88007ec08b0 fffff880
00ff30bb : fffffa800854fc50 00000000
00000002 fffffa800854fc50 fffff980
1a582bd0 : mydriver!NewWaitingIRP+0x56 [v:\mydriver\mydriver.cpp @ 1478]
fffff88007ec08e0 fffff800
03933c16 : fffffa800854fc50 fffff980
1a582bd0 0000000000000002 fffffa80
0854fb00 : mydriver!DispatchWrite+0xa7 [v:\mydriver\mydriver.cpp @ 1675]
fffff88007ec0930 fffff800
03932c42 : fffff9801a582dc0 00000000
00000002 fffffa8008550f50 fffffa80
07e57a30 : nt!IovCallDriver+0x566
fffff88007ec0990 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 fffffa8008550e00 00000000
00000002 : nt!ViFilterDispatchGeneric+0x62
fffff88007ec09c0 fffff880
00f650af : fffff9801a582bd0 00000000
00000002 fffff9801a582e50 fffffa80
0dfb2f40 : nt!IovCallDriver+0x566
fffff88007ec0a20 fffff800
03933c16 : fffff9801a582bd0 fffffa80
08550950 fffff9801a582ee0 00000000
00000000 : partmgr!PmGlobalDispatch+0x9f
fffff88007ec0a50 fffff880
00f7a18c : fffffa8008441a90 00000000
00000002 fffff9801a582bd0 fffffa80
0e8be580 : nt!IovCallDriver+0x566
fffff88007ec0ab0 fffff800
03933c16 : 0000000000000002 fffffa80
0d58b610 fffff9801a582bd0 fffff800
0392fbcc : volmgr!VmReadWrite+0x11c
fffff88007ec0af0 fffff880
0214f2bf : fffff9801a582bd0 00000000
00000002 fffffa8008454940 fffffa80
0d58b610 : nt!IovCallDriver+0x566
fffff88007ec0b50 fffff880
0214f53c : fffffa8008454a90 00000000
00000000 fffffa8008454940 00000000
00000002 : fvevol!FveReadWrite+0x47
fffff88007ec0b90 fffff880
0214f593 : 0000000000000000 fffff980
1a582bd0 fffff9801a582f28 fffffa80
0deacc10 : fvevol!FveFilterRundownReadWrite+0x1dc
fffff88007ec0bf0 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 0000000000000000 00000000
00000000 : fvevol!FveFilterRundownWrite+0x2f
fffff88007ec0c20 fffff880
020a6108 : fffff9801a582bd0 00000000
00000002 fffff9801a582f28 fffffa80
0deacc10 : nt!IovCallDriver+0x566
fffff88007ec0c80 fffff800
03933c16 : 0000000000000002 fffffa80
08563040 0000000000000000 fffffa80
08563040 : volsnap!VolsnapWriteFilter+0xf8
fffff88007ec0cd0 fffff880
01a2b39a : fffff88003b7e128 fffff880
03b7e1b0 fffffa8006d56680 fffffa80
0dfae7a0 : nt!IovCallDriver+0x566
fffff88007ec0d30 fffff800
03485757 : 0000000000000000 00000000
00000000 000000007ef86000 00000000
02dffb24 : Ntfs!NtfsStorageDriverCallout+0x16
fffff88007ec0d60 fffff800
03485711 : 0000000000000000 00000000
00000000 fffff88007ec1000 fffff800
0349a7e2 : nt!KxSwitchKernelStackCallout+0x27
fffff88003b7dff0 fffff800
0349a7e2 : fffffa800e9b4e00 00000000
00000002 fffffa800ca49e40 fffff8a0
01420c70 : nt!KiSwitchKernelStackContinue
fffff88003b7e010 fffff880
01a2af09 : fffff88001a2b384 fffff800
03450a1e fffff88000001000 00000000
00000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff88003b7e0f0 fffff880
01a2a3d6 : fffffa8008585290 00000000
00000000 fffff8a001420c70 00000000
00000000 : Ntfs!NtfsMultipleAsync+0xa9
fffff88003b7e160 fffff880
01a2e5f4 : fffffa800ca49e40 fffff980
1a582bd0 0000000000000000 00000000
00000000 : Ntfs!NtfsNonCachedIo+0x216
fffff88003b7e2e0 fffff880
01a2f1a3 : fffffa800ca49e40 fffff980
1a582bd0 fffff88003b7e400 fffff880
00001000 : Ntfs!NtfsCommonWrite+0x2d91
fffff88003b7e490 fffff800
03933c16 : fffff9801a582bd0 fffff980
1a582bd0 fffffa8008583030 fffffa80
0dfa12a0 : Ntfs!NtfsFsdWrite+0x1c3
fffff88003b7e550 fffff880
016c7bcf : fffff9801a582fb8 fffff880
03b7e600 fffffa800ccb17a0 fffffa80
0dfa12a0 : nt!IovCallDriver+0x566
fffff88003b7e5b0 fffff880
016c66df : fffffa8008469de0 fffffa80
08469de0 fffffa8008469d00 fffff980
1a582bd0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88003b7e640 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 fffff9801a582bd0 fffffa80
06cc6b30 : fltmgr!FltpDispatch+0xcf
fffff88003b7e6a0 fffff800
0379621b : 0000000000000001 fffffa80
0be6cdc0 0000000000000000 fffffa80
0c9bbcc0 : nt!IovCallDriver+0x566
fffff88003b7e700 fffff800
037a0c83 : fffff9801a583000 fffff880
03b7e960 fffffa800be6cdc0 fffff880
03b7ea00 : nt!IopSynchronousServiceTail+0xfb
fffff88003b7e770 fffff800
0348ced3 : 0000000000000000 ffffffff
80000cc8 0000000000000000 00000000
00000000 : nt!NtWriteFile+0x7e2
fffff88003b7e870 fffff800
03489470 : fffff8000372b103 fffffa80
0d830000 0000000000001000 00000000
00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff88003b7ea78 fffff800
0372b103 : fffffa800d830000 00000000
00001000 0000000000000000 fffffa80
0cdf2810 : nt!KiServiceLinkage
fffff88003b7ea80 fffff800
0372c203 : ffffffff800003d0 fffff8a0
1353a8d0 fffff88003b7eb68 fffff880
03b7ebe0 : nt!CmpDoFileWrite+0x1f3
fffff88003b7eb40 fffff800
0372b791 : fffff88000000000 00000000
000045bf 0000000000022df8 fffff8a0
01426000 : nt!CmpFileWrite+0x2f
fffff88003b7eb70 fffff800
0372b99a : 0000000001d65000 00000000
00000000 0000000000000000 00000000
00000001 : nt!HvWriteDirtyDataToHive+0x161
fffff88003b7ebe0 fffff800
0371c567 : 0000000000000000 00000000
00000000 0000000000000000 fffff8a0
00505000 : nt!HvOptimizedSyncHive+0x32
fffff88003b7ec10 fffff800
0371c6c9 : 0000000000000000 fffff880
03b7ecb8 fffff8000371c600 00000000
00010206 : nt!CmpDoFlushNextHive+0x197
fffff88003b7ec70 fffff800
03498001 : fffff8000371c624 fffff800
03784900 fffffa8000000000 fffff800
0362e2b8 : 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 fffff800
03492f32 : fffff880009b2180 fffffa80
06d56680 0000000000000000 00000000
00000000 : nt!KiSwapContext+0x7a
> fffff88003793240 fffff800
0349574f : 0000000000000002 00000000
00000000 fffffa8000000000 00000000
00000000 : nt!KiCommitThreadWait+0x1d2
> fffff880037932d0 fffff880
0128fc93 : 0000000000000000 fffffa80
00000000 fffffa800db0c000 fffffa80
0c547700 : nt!KeWaitForSingleObject+0x19f
> fffff88003793370 fffff880
0128dd6a : fffff98005c36c60 fffff980
05c36e98 fffff98000000200 fffffa80
00000000 : iaStor+0x4dc93
> fffff88003793420 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffffa8008007050 fffffa80
0e891b80 : iaStor+0x4bd6a
> fffff88003793490 fffff880
021a0ca0 : 00000000002d9404 00000000
002d9404 fffff98005c36c60 fffffa80
0e891b80 : nt!IovCallDriver+0x566
> fffff880037934f0 fffff880
02189417 : fffff98005c36f28 00000000
00000000 fffff98005c36c60 00000000
00000002 : CLASSPNP!ClassDeviceControl+0x310
> fffff88003793610 fffff880
021a0e7d : 0000000000000002 00000000
00000000 0000000000000000 fffffa80
0dfd5b40 : disk!DiskDeviceControl+0x171
> fffff88003793670 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffff98005c36c60 fffff800
0392f37e : CLASSPNP!ClassDeviceControlDispatch+0x2d
> fffff880037936a0 fffff800
03932c42 : fffff98005c36ee0 00000000
00000002 fffffa8008436aa0 fffffa80
0dfd5b40 : nt!IovCallDriver+0x566
> fffff88003793700 fffff800
03933c16 : fffff98005c36c60 00000000
00000002 fffffa8008436950 fffff800
03932026 : nt!ViFilterDispatchGeneric+0x62
> fffff88003793730 fffff880
00ff2183 : fffff98019c26fd0 00000000
00000000 0000000000000000 fffffa80
0dd45b30 : nt!IovCallDriver+0x566
> fffff88003793790 fffff880
00ff243e : fffff98019c26fd0 00000000
00000000 0000000000000000 fffffa80
0854fc50 : mydriver!ReleasePrimaryIRP+0x9f [c:\mydriver\mydriver.cpp @ 667]
> fffff880037937c0 fffff800
039355d6 : fffff9801a466fb0 fffff980
19c26f02 fffff98019c26fd0 fffff980
1a466e50 : mydriver!WriteSectorCompletion+0x13a [v:\mydriver\mydriver.cpp @ 832]
> fffff88003793800 fffff800
03491021 : fffff9801a466fb3 00000000
00000001 0000000000000000 fffff800
0354a803 : nt!IovpLocalCompletionRoutine+0x166
> fffff88003793860 fffff800
0392d19f : fffff9801a466e50 00000000
ffffff01 fffffa8008555001 00000000
00000000 : nt!IopfCompleteRequest+0x341
> fffff88003793950 fffff880
0219fbce : fffff88003793c20 fffff980
0a498e02 0000000000000004 fffffa80
08555010 : nt!IovCompleteRequest+0x19f
> fffff88003793a20 fffff800
039355d6 : fffffa800bf2ca60 fffffa80
0bf2ca60 fffff88003793c40 fffff980
0a498ea0 : CLASSPNP!TransferPktComplete+0x1ce
> fffff88003793aa0 fffff800
03491021 : fffff9800a498fbb 00000000
00000001 0000000000000000 fffff800
0354a803 : nt!IovpLocalCompletionRoutine+0x166
> fffff88003793b00 fffff800
0392d19f : fffff9800a498ea0 fffff980
0a498e00 fffffa800cfed500 00000000
00000000 : nt!IopfCompleteRequest+0x341
> fffff88003793bf0 fffff880
0126edf9 : fffffa800bf2cb80 fffffa80
0cfed510 fffffa800bf2cb80 fffffa80
0cfed510 : nt!IovCompleteRequest+0x19f
> fffff88003793cc0 fffff880
01248a06 : fffff88003793da0 fffffa80
0811d3f0 fffffa800811d3f0 fffff880
03793da0 : iaStor+0x2cdf9
> fffff88003793d10 fffff880
01248f79 : fffff88003793d01 fffff880
03793da0 0000000000000800 fffffa80
080f4440 : iaStor+0x6a06
> fffff88003793d50 fffff880
01248757 : 0000000000000000 00000000
00000000 fffffa800ba6da00 00000000
000000ff : iaStor+0x6f79
> fffff88003793d80 fffff880
0126eb08 : fffffa8000000064 00000000
00000000 fffff88003764180 fffffa80
080f4c38 : iaStor+0x6757
> fffff88003793ed0 fffff800
034990ac : fffff88003764180 fffffa80
0b8b6d28 fffffa800b8b6d40 00000000
00000000 : iaStor+0x2cb08
> fffff88003793f00 fffff800
03490765 : 0000000000000000 fffffa80
06d56680 0000000000000000 fffff880
0126eacc : nt!KiRetireDpcList+0x1bc
> fffff88003793fb0 fffff800
0349057c : 0000000000000000 00000000
00000008 0000000000000000 00000000
00000000 : nt!KyRetireDpcList+0x5
> fffff88007ebfed0 fffff800
034d9993 : fffff80003489ab6 fffff800
03489b22 0000000000000000 fffff880
07ebff01 : nt!KiDispatchInterruptContinue
> fffff88007ebff00 fffff800
03489b22 : 0000000000000000 fffff880
07ebff01 fffffa800800dcc0 00000060
00000011 : nt!KiDpcInterruptBypass+0x13
> fffff88007ebff10 fffff800
0354a6f9 : 0000000000001254 00000000
00000000 fffff88007ec01c0 00000000
000012bf : nt!KiInterruptDispatch+0x212
> fffff88007ec00a0 fffff800
0354a803 : fffffa8007513718 fffff880
00000011 fffff98000000000 fffff800
00000004 : nt!RtlpWalkFrameChain+0x15a9
> fffff88007ec0740 fffff800
0354b68b : 0000000000000003 fffffa80
07513718 0000000000000000 00000000
00000000 : nt!RtlWalkFrameChain+0x63
> fffff88007ec0770 fffff800
0392402c : fffffa8007513700 00000000
00000018 00000000000000c0 00000000
00000000 : nt!RtlCaptureStackBackTrace+0x4b
> fffff88007ec07a0 fffff800
0392609a : fffff88007ebb000 fffff880
07ec1000 00000000000000c0 00000000
00000018 : nt!ViPoolLogStackCallout+0x1c
> fffff88007ec07d0 fffff800
03928cc6 : fffffa800d828d80 fffff980
14718fe0 fffffa8006c9f550 00000000
000000f9 : nt!ViPoolLogStackTrace+0x8a
> fffff88007ec0800 fffff800
03928d3d : fffffa800854fc50 00000000
00000001 fffffa8050524957 fffffa80
0854fc50 : nt!VeAllocatePoolWithTagPriority+0x2b6
> fffff88007ec0870 fffff880
00ff2e6a : fffff88000ff7110 00000000
00000000 fffffa8000000078 fffff800
0392fd86 : nt!VerifierExAllocatePoolEx+0x1d
> fffff88007ec08b0 fffff880
00ff30bb : fffffa800854fc50 00000000
00000002 fffffa800854fc50 fffff980
1a582bd0 : mydriver!NewWaitingIRP+0x56 [v:\mydriver\mydriver.cpp @ 1478]
> fffff88007ec08e0 fffff800
03933c16 : fffffa800854fc50 fffff980
1a582bd0 0000000000000002 fffffa80
0854fb00 : mydriver!DispatchWrite+0xa7 [v:\mydriver\mydriver.cpp @ 1675]
> fffff88007ec0930 fffff800
03932c42 : fffff9801a582dc0 00000000
00000002 fffffa8008550f50 fffffa80
07e57a30 : nt!IovCallDriver+0x566
> fffff88007ec0990 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 fffffa8008550e00 00000000
00000002 : nt!ViFilterDispatchGeneric+0x62
> fffff88007ec09c0 fffff880
00f650af : fffff9801a582bd0 00000000
00000002 fffff9801a582e50 fffffa80
0dfb2f40 : nt!IovCallDriver+0x566
> fffff88007ec0a20 fffff800
03933c16 : fffff9801a582bd0 fffffa80
08550950 fffff9801a582ee0 00000000
00000000 : partmgr!PmGlobalDispatch+0x9f
> fffff88007ec0a50 fffff880
00f7a18c : fffffa8008441a90 00000000
00000002 fffff9801a582bd0 fffffa80
0e8be580 : nt!IovCallDriver+0x566
> fffff88007ec0ab0 fffff800
03933c16 : 0000000000000002 fffffa80
0d58b610 fffff9801a582bd0 fffff800
0392fbcc : volmgr!VmReadWrite+0x11c
> fffff88007ec0af0 fffff880
0214f2bf : fffff9801a582bd0 00000000
00000002 fffffa8008454940 fffffa80
0d58b610 : nt!IovCallDriver+0x566
> fffff88007ec0b50 fffff880
0214f53c : fffffa8008454a90 00000000
00000000 fffffa8008454940 00000000
00000002 : fvevol!FveReadWrite+0x47
> fffff88007ec0b90 fffff880
0214f593 : 0000000000000000 fffff980
1a582bd0 fffff9801a582f28 fffffa80
0deacc10 : fvevol!FveFilterRundownReadWrite+0x1dc
> fffff88007ec0bf0 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 0000000000000000 00000000
00000000 : fvevol!FveFilterRundownWrite+0x2f
> fffff88007ec0c20 fffff880
020a6108 : fffff9801a582bd0 00000000
00000002 fffff9801a582f28 fffffa80
0deacc10 : nt!IovCallDriver+0x566
> fffff88007ec0c80 fffff800
03933c16 : 0000000000000002 fffffa80
08563040 0000000000000000 fffffa80
08563040 : volsnap!VolsnapWriteFilter+0xf8
> fffff88007ec0cd0 fffff880
01a2b39a : fffff88003b7e128 fffff880
03b7e1b0 fffffa8006d56680 fffffa80
0dfae7a0 : nt!IovCallDriver+0x566
> fffff88007ec0d30 fffff800
03485757 : 0000000000000000 00000000
00000000 000000007ef86000 00000000
02dffb24 : Ntfs!NtfsStorageDriverCallout+0x16
> fffff88007ec0d60 fffff800
03485711 : 0000000000000000 00000000
00000000 fffff88007ec1000 fffff800
0349a7e2 : nt!KxSwitchKernelStackCallout+0x27
> fffff88003b7dff0 fffff800
0349a7e2 : fffffa800e9b4e00 00000000
00000002 fffffa800ca49e40 fffff8a0
01420c70 : nt!KiSwitchKernelStackContinue
> fffff88003b7e010 fffff880
01a2af09 : fffff88001a2b384 fffff800
03450a1e fffff88000001000 00000000
00000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
> fffff88003b7e0f0 fffff880
01a2a3d6 : fffffa8008585290 00000000
00000000 fffff8a001420c70 00000000
00000000 : Ntfs!NtfsMultipleAsync+0xa9
> fffff88003b7e160 fffff880
01a2e5f4 : fffffa800ca49e40 fffff980
1a582bd0 0000000000000000 00000000
00000000 : Ntfs!NtfsNonCachedIo+0x216
> fffff88003b7e2e0 fffff880
01a2f1a3 : fffffa800ca49e40 fffff980
1a582bd0 fffff88003b7e400 fffff880
00001000 : Ntfs!NtfsCommonWrite+0x2d91
> fffff88003b7e490 fffff800
03933c16 : fffff9801a582bd0 fffff980
1a582bd0 fffffa8008583030 fffffa80
0dfa12a0 : Ntfs!NtfsFsdWrite+0x1c3
> fffff88003b7e550 fffff880
016c7bcf : fffff9801a582fb8 fffff880
03b7e600 fffffa800ccb17a0 fffffa80
0dfa12a0 : nt!IovCallDriver+0x566
> fffff88003b7e5b0 fffff880
016c66df : fffffa8008469de0 fffffa80
08469de0 fffffa8008469d00 fffff980
1a582bd0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff88003b7e640 fffff800
03933c16 : fffff9801a582bd0 00000000
00000002 fffff9801a582bd0 fffffa80
06cc6b30 : fltmgr!FltpDispatch+0xcf
> fffff88003b7e6a0 fffff800
0379621b : 0000000000000001 fffffa80
0be6cdc0 0000000000000000 fffffa80
0c9bbcc0 : nt!IovCallDriver+0x566
> fffff88003b7e700 fffff800
037a0c83 : fffff9801a583000 fffff880
03b7e960 fffffa800be6cdc0 fffff880
03b7ea00 : nt!IopSynchronousServiceTail+0xfb
> fffff88003b7e770 fffff800
0348ced3 : 0000000000000000 ffffffff
80000cc8 0000000000000000 00000000
00000000 : nt!NtWriteFile+0x7e2
> fffff88003b7e870 fffff800
03489470 : fffff8000372b103 fffffa80
0d830000 0000000000001000 00000000
00000000 : nt!KiSystemServiceCopyEnd+0x13
> fffff88003b7ea78 fffff800
0372b103 : fffffa800d830000 00000000
00001000 0000000000000000 fffffa80
0cdf2810 : nt!KiServiceLinkage
> fffff88003b7ea80 fffff800
0372c203 : ffffffff800003d0 fffff8a0
1353a8d0 fffff88003b7eb68 fffff880
03b7ebe0 : nt!CmpDoFileWrite+0x1f3
> fffff88003b7eb40 fffff800
0372b791 : fffff88000000000 00000000
000045bf 0000000000022df8 fffff8a0
01426000 : nt!CmpFileWrite+0x2f
> fffff88003b7eb70 fffff800
0372b99a : 0000000001d65000 00000000
00000000 0000000000000000 00000000
00000001 : nt!HvWriteDirtyDataToHive+0x161
> fffff88003b7ebe0 fffff800
0371c567 : 0000000000000000 00000000
00000000 0000000000000000 fffff8a0
00505000 : nt!HvOptimizedSyncHive+0x32
> fffff88003b7ec10 fffff800
0371c6c9 : 0000000000000000 fffff880
03b7ecb8 fffff8000371c600 00000000
00010206 : nt!CmpDoFlushNextHive+0x197
> fffff88003b7ec70 fffff800
03498001 : fffff8000371c624 fffff800
03784900 fffffa8000000000 fffff800
0362e2b8 : 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