Detecting volume going offline in cluster

Doron_Holan · May 10, 2012, 4:01pm

As a filter you should not need to handle any relations at all

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, May 10, 2012 11:08 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting volume going offline in cluster

I’ve made lots of progress in my driver but unfortunately I’ve not been able to resolve my issue. What I was trying to understand is if my device is getting surprise remove from some other device(?). I’ve not found answer to that.

Here is how my device stack looks like. My driver is wdffltr.

0: kd> !devobj \Device\HarddiskVolume3
Device object (fffffa800357fcd0) is for:
HarddiskVolume3 \Driver\volmgr DriverObject fffffa8003395de0 Current Irp 00000000 RefCount 25 Type 00000007 Flags 00003050 Vpb fffffa8003575ea0 Dacl fffff9a1002dc320 DevExt fffffa800357fe20 DevObjExt fffffa800357ff88 Dope fffffa800357fc10 DevNode fffffa8003580b10 ExtensionFlags (0x00000800)
Unknown flags 0x00000800 AttachedDevice (Upper) fffffa8003680040 \Driver\volsnap Device queue is not busy.
0: kd> !devstack fffffa800357fcd0
!DevObj !DrvObj !DevExt ObjectName
fffffa8003582950 \Driver\wdffltr fffffa8003582ec0
fffffa8003680040 \Driver\volsnap fffffa8003680190

fffffa800357fcd0 \Driver\volmgr fffffa800357fe20 HarddiskVolume3
!DevNode fffffa8003580b10 :
DeviceInst is “STORAGE\Volume{c2fa4078-9d1e-11e0-bdcc-806e6f6e6963}#0000000000100000”
ServiceName is “volsnap”

The article, http://www.wd-3.com/031504/AboutRemovalRelations.htm, from Mark Roddy, suggests something which I think I’m not addressing in my driver - Device relations. The MSDN states in the article http://msdn.microsoft.com/en-us/library/windows/hardware/ff551670(v=vs.85).aspx that “Function and filter drivers might handle RemovalRelations requests.” Are there any guidelines how KMDF filter driver would handle EvtDeviceRelationsQuery/IRP_MN_QUERY_DEVICE_RELATIONS

Would appreciate any help on this. Thanks.

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

M_D · June 8, 2012, 12:10pm

I was off doing something else but back to looking at this issue again.

When I take the cluster volume offline, my kmdf volume upper filter driver gets IOCTL_VOLUME_OFFLINE before my pnpPowerCallbacks.EvtDeviceSurpriseRemoval call back.

Here is the stack traces when I take cluster volume offline.

Breakpoint in ioQueueConfig.EvtIoDeviceControl handler for IOCTL_VOLUME_OFFLINE

Child-SP RetAddr Call Site
fffff880041acad0 fffff88000f6df90 wdffltr!WdfFltrDeviceControl(
struct WDFQUEUE__ * Queue = 0xfffffa8002e6e770, struct WDFREQUEST__ \* Request = 0x0000057ffd16bfd8,
unsigned int64 OutputBufferLength = 0xfffffa8001c49a10, unsigned int64 InputBufferLength = 0xfffffa8002d6ba40,
unsigned long IoControlCode = 0x56c00c)+0x230 [c:\wdffltr_v10\filter\control.cpp @ 145]
fffff880041acb20 fffff88000f6d99f Wdf01000!FxIoQueue::DispatchRequestToDriver+0x4b8
fffff880041acba0 fffff88000f6cf98 Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880041acc10 fffff88000f72558 Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff880041acc80 fffff88000f5c245 Wdf01000!FxPkgIo::Dispatch+0x37c
fffff880041acd00 fffff8800141539a Wdf01000!FxDevice::Dispatch+0xa9
fffff880041acd30 fffff8000187e157 Ntfs!NtfsStorageDriverCallout+0x16
fffff880041acd60 fffff8000187e111 nt!KxSwitchKernelStackCallout+0x27
fffff88004b5b730 fffff80001893242 nt!KiSwitchKernelStackContinue
fffff88004b5b750 fffff8800141ddd9 nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff88004b5b830 fffff88001485175 Ntfs!NtfsCallStorageDriver+0x31
fffff88004b5b890 fffff88001241bcf Ntfs!NtfsFsdDeviceControl+0x10d
fffff88004b5b920 fffff880012406df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88004b5b9b0 fffff80001ba0f97 fltmgr!FltpDispatch+0xcf
fffff88004b5ba10 fffff80001ba17f6 nt!IopXxxControlFile+0x607
fffff88004b5bb40 fffff800018858d3 nt!NtDeviceIoControlFile+0x56
fffff88004b5bbb0 0000000077c9138a nt!KiSystemServiceCopyEnd+0x13
0000000001a1f718 000007fefdc4b939 ntdll!NtDeviceIoControlFile+0xa
0000000001a1f720 0000000000000000 KernelBase+0xb939

Breakpoint in pnpPowerCallbacks.EvtDeviceSurpriseRemoval handler

Child-SP RetAddr Call Site
fffff880041c4a08 fffff88000f9778c wdffltr!WdfFltrEvtDeviceSurpriseRemoval(
struct WDFDEVICE__ * Device = 0xfffff880041c4b70) [c:\wdffltr_v10\filter\wdffltr.cpp @ 907] fffff880041c4a10 fffff88000f96841 Wdf01000!FxPkgPnp::PnpEventSurpriseRemoveIoStarted+0x2c fffff880041c4a40 fffff88000f964fe Wdf01000!FxPkgPnp::PnpEnterNewState+0x1a5 fffff880041c4ab0 fffff88000f96201 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x122 fffff880041c4b20 fffff88000f94e54 Wdf01000!FxPkgPnp::PnpProcessEvent+0x1b1 fffff880041c4bb0 fffff88000f8cdd6 Wdf01000!FxPkgFdo::_PnpSurpriseRemoval+0x28 fffff880041c4be0 fffff88000f4b7fa Wdf01000!FxPkgPnp::Dispatch+0x1b2 fffff880041c4c50 fffff88000f5c342 Wdf01000!imp_WdfDeviceWdmDispatchPreprocessedIrp+0x196 fffff880041c4c90 fffff88000f5c1d2 Wdf01000!FxDevice::PreprocessIrp+0xf2 fffff880041c4cc0 fffff88000f5c14b Wdf01000!FxDevice::Dispatch+0x36 fffff880041c4cf0 fffff8800141539a Wdf01000!FxDevice::DispatchWithLock+0x93 fffff880041c4d30 fffff8000187e157 Ntfs!NtfsStorageDriverCallout+0x16 fffff880041c4d60 fffff8000187e111 nt!KxSwitchKernelStackCallout+0x27 fffff8800210f500 fffff80001893242 nt!KiSwitchKernelStackContinue fffff8800210f520 fffff8800141ddd9 nt!KeExpandKernelStackAndCalloutEx+0x2a2 fffff8800210f600 fffff880014d366f Ntfs!NtfsCallStorageDriver+0x31 fffff8800210f660 fffff880014d4a0c Ntfs!NtfsCommonPnp+0x16f fffff8800210f740 fffff88001241bcf Ntfs!NtfsFsdPnp+0x1f0 fffff8800210f7e0 fffff880012406df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f fffff8800210f870 fffff80001af2f29 fltmgr!FltpDispatch+0xcf fffff8800210f8d0 fffff80001c6d381 nt!IopSynchronousCall+0xc5 fffff8800210f940 fffff80001c67d78 nt!IopRemoveDevice+0x101 fffff8800210fa00 fffff80001c6cec7 nt!PnpSurpriseRemoveLockedDeviceNode+0x128 fffff8800210fa40 fffff80001c6cfe0 nt!PnpDeleteLockedDeviceNode+0x37 fffff8800210fa70 fffff80001cfd8ef nt!PnpDeleteLockedDeviceNodes+0xa0 fffff8800210fae0 fffff80001cfe4ac nt!PnpProcessQueryRemoveAndEject+0x6cf fffff8800210fc20 fffff80001be76ac nt!PnpProcessTargetDeviceEvent+0x4c fffff8800210fc50 fffff80001890a21 nt! ?? ::NNGAKEGL::string’+0x5cd3b
fffff8800210fcb0 fffff80001b23cce nt!ExpWorkerThread+0x111
fffff8800210fd40 fffff80001877fe6 nt!PspSystemThreadStartup+0x5a
fffff8800210fd80 0000000000000000 nt!KxStartSystemThread+0x16

Is it possible that I’m seeing surprise removal because I’m using KMDF and not WDM?

Doron_Holan · June 8, 2012, 12:18pm

No, kmdf will not affect surprise remove vs remove. No driver model can have that type of influence

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, June 8, 2012 9:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting volume going offline in cluster

I was off doing something else but back to looking at this issue again.

When I take the cluster volume offline, my kmdf volume upper filter driver gets IOCTL_VOLUME_OFFLINE before my pnpPowerCallbacks.EvtDeviceSurpriseRemoval call back.

Here is the stack traces when I take cluster volume offline.

Breakpoint in ioQueueConfig.EvtIoDeviceControl handler for IOCTL_VOLUME_OFFLINE

Child-SP RetAddr Call Site
fffff880041acad0 fffff88000f6df90 wdffltr!WdfFltrDeviceControl(
struct WDFQUEUE__ * Queue = 0xfffffa8002e6e770, struct WDFREQUEST__ \* Request = 0x0000057ffd16bfd8,
unsigned int64 OutputBufferLength = 0xfffffa8001c49a10, unsigned int64 InputBufferLength = 0xfffffa8002d6ba40,
unsigned long IoControlCode = 0x56c00c)+0x230 [c:\wdffltr_v10\filter\control.cpp @ 145]
fffff880041acb20 fffff88000f6d99f Wdf01000!FxIoQueue::DispatchRequestToDriver+0x4b8
fffff880041acba0 fffff88000f6cf98 Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880041acc10 fffff88000f72558 Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff880041acc80 fffff88000f5c245 Wdf01000!FxPkgIo::Dispatch+0x37c
fffff880041acd00 fffff8800141539a Wdf01000!FxDevice::Dispatch+0xa9
fffff880041acd30 fffff8000187e157 Ntfs!NtfsStorageDriverCallout+0x16
fffff880041acd60 fffff8000187e111 nt!KxSwitchKernelStackCallout+0x27
fffff88004b5b730 fffff80001893242 nt!KiSwitchKernelStackContinue
fffff88004b5b750 fffff8800141ddd9 nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff88004b5b830 fffff88001485175 Ntfs!NtfsCallStorageDriver+0x31
fffff88004b5b890 fffff88001241bcf Ntfs!NtfsFsdDeviceControl+0x10d
fffff88004b5b920 fffff880012406df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88004b5b9b0 fffff80001ba0f97 fltmgr!FltpDispatch+0xcf
fffff88004b5ba10 fffff80001ba17f6 nt!IopXxxControlFile+0x607
fffff88004b5bb40 fffff800018858d3 nt!NtDeviceIoControlFile+0x56
fffff88004b5bbb0 0000000077c9138a nt!KiSystemServiceCopyEnd+0x13
0000000001a1f718 000007fefdc4b939 ntdll!NtDeviceIoControlFile+0xa
0000000001a1f720 0000000000000000 KernelBase+0xb939

Breakpoint in pnpPowerCallbacks.EvtDeviceSurpriseRemoval handler

Child-SP RetAddr Call Site
fffff880041c4a08 fffff88000f9778c wdffltr!WdfFltrEvtDeviceSurpriseRemoval(
struct WDFDEVICE__ * Device = 0xfffff880041c4b70) [c:\wdffltr_v10\filter\wdffltr.cpp @ 907] fffff880041c4a10 fffff88000f96841 Wdf01000!FxPkgPnp::PnpEventSurpriseRemoveIoStarted+0x2c fffff880041c4a40 fffff88000f964fe Wdf01000!FxPkgPnp::PnpEnterNewState+0x1a5 fffff880041c4ab0 fffff88000f96201 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x122 fffff880041c4b20 fffff88000f94e54 Wdf01000!FxPkgPnp::PnpProcessEvent+0x1b1 fffff880041c4bb0 fffff88000f8cdd6 Wdf01000!FxPkgFdo::_PnpSurpriseRemoval+0x28 fffff880041c4be0 fffff88000f4b7fa Wdf01000!FxPkgPnp::Dispatch+0x1b2 fffff880041c4c50 fffff88000f5c342 Wdf01000!imp_WdfDeviceWdmDispatchPreprocessedIrp+0x196 fffff880041c4c90 fffff88000f5c1d2 Wdf01000!FxDevice::PreprocessIrp+0xf2 fffff880041c4cc0 fffff88000f5c14b Wdf01000!FxDevice::Dispatch+0x36 fffff880041c4cf0 fffff8800141539a Wdf01000!FxDevice::DispatchWithLock+0x93 fffff880041c4d30 fffff8000187e157 Ntfs!NtfsStorageDriverCallout+0x16 fffff880041c4d60 fffff8000187e111 nt!KxSwitchKernelStackCallout+0x27 fffff8800210f500 fffff80001893242 nt!KiSwitchKernelStackContinue fffff8800210f520 fffff8800141ddd9 nt!KeExpandKernelStackAndCalloutEx+0x2a2 fffff8800210f600 fffff880014d366f Ntfs!NtfsCallStorageDriver+0x31 fffff8800210f660 fffff880014d4a0c Ntfs!NtfsCommonPnp+0x16f fffff8800210f740 fffff88001241bcf Ntfs!NtfsFsdPnp+0x1f0 fffff8800210f7e0 fffff880012406df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f fffff8800210f870 fffff80001af2f29 fltmgr!FltpDispatch+0xcf fffff8800210f8d0 fffff80001c6d381 nt!IopSynchronousCall+0xc5 fffff8800210f940 fffff80001c67d78 nt!IopRemoveDevice+0x101 fffff8800210fa00 fffff80001c6cec7 nt!PnpSurpriseRemoveLockedDeviceNode+0x128 fffff8800210fa40 fffff80001c6cfe0 nt!PnpDeleteLockedDeviceNode+0x37 fffff8800210fa70 fffff80001cfd8ef nt!PnpDeleteLockedDeviceNodes+0xa0 fffff8800210fae0 fffff80001cfe4ac nt!PnpProcessQueryRemoveAndEject+0x6cf fffff8800210fc20 fffff80001be76ac nt!PnpProcessTargetDeviceEvent+0x4c fffff8800210fc50 fffff80001890a21 nt! ?? ::NNGAKEGL::string’+0x5cd3b
fffff8800210fcb0 fffff80001b23cce nt!ExpWorkerThread+0x111
fffff8800210fd40 fffff80001877fe6 nt!PspSystemThreadStartup+0x5a
fffff8800210fd80 0000000000000000 nt!KxStartSystemThread+0x16

Is it possible that I’m seeing surprise removal because I’m using KMDF and not WDM?

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