Getting getting STATUS_DEVICE_OFF_LINE without getting IRP_MN_SURPRISE_REMOVAL

NTDEV
1

Hi,

We have a volume filter driver which sits on top of volsnap. We are building our own IRPs
and sending it to volsnap. We are facing a situation here in which we are failing to write the IRP. The NTSTATUS we get in return is STATUS_DEVICE_OFF_LINE. However, we believe that we should have received some removal IRP for the disk (local disk). We are not getting either IRP_MN_SURPRISE_REMOVAL or IRP_MN_REMOVE_DEVICE or IRP_MN_STOP_DEVICE or IRP_MN_QUERY_STOP and IRP_MN_QUERY_REMOVE_DEVICE ?

The environment has MSCS and it is expected that the shared disk volume will come in and go away. We have built our code logic around the assumption that we will get at least one of the removal IRP_MN.

Is this assumption incorrect ? I found on this thread (http://www.osronline.com/showthread.cfm?link=144518) that “1. It is consistent behaviour that IMSR (and IMRD) won’t be issued if
there’s a reference on the device(open handle).”
If the above statement is correct then how do I find who has left the handle open on the volume device ?

Thanks,
Ukis

2

I am facing this issue on Windows 7 64-bit.

9: kd> vertarget
Windows 7 Kernel Version 7601 (Service Pack 1) MP (32 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 7601.18229.amd64fre.win7sp1_gdr.130801-1533
Machine Name:
Kernel base = 0xfffff80001e08000 PsLoadedModuleList = 0xfffff8000204b6d0
Debug session time: Thu Dec 18 13:26:54.335 2014 (UTC + 5:30)
System Uptime: 0 days 12:00:30.708

3

> Is this assumption incorrect ?

Yes, it is incorrect.

On/offline volume operations, used by the cluster among the other things, are NOT related to PnP removes.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

4

> On/offline volume operations, used by the cluster among the other things, are
NOT related to PnP removes.

Thanks for clarifying Maxim. So I am assuming that we should have gotten IOCTL_VOLUME_OFFLINE when our volume (and the underlying disk) moves from this node to another. We are not getting this IOCTL. Its when we send our own write IRP to the lower driver, the write IRP fails and we get STATUS_DEVICE_OFF_LINE.

There is one more observation that I have here:

9: kd> !devobj fffffa80715ef970
Device object (fffffa80715ef970) is for:
HarddiskVolume4 \Driver\volmgr DriverObject fffffa80328db060
Current Irp 00000000 RefCount 76 Type 00000007 Flags 00003050
Vpb fffffa80715bb8e0 Dacl fffff9a10034a470 DevExt fffffa80715efac0 DevObjExt fffffa80715efc28 Dope fffffa80715af900 DevNode fffffa80335395d0
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedDevice (Upper) fffffa803353e030 \Driver\volsnap
Device queue is not busy.

The reference count on volume device object is 76. Did we not get the IOCTL_VOLUME_OFFLINE because of this ?

Any suggestions on what to expect when the volume moves from one node to another.

Thanks,
Ukis

5

From this thread, it sound like I should be getting IOCTL_VOLUME_OFFLINE
http://www.osronline.com/showthread.cfm?link=224364

Any suggestions ?

Thanks,
Ukis