Why a named volume filter device can not mount to the Volume Device?

I have written a Volume Filter. Before I named it , it worked correctly.

But after I named it,I found that it was not on the device tree.

Here’s my code:

#define VOLUME_DEVICE_NAME L"\Device\MyVolumeFilter2021"
#define VOLUME_DEVICE_SYMBOL L"\??\VolumeFilter2021"

status = IoCreateDevice(
DriverObject,
sizeof(FLT_DEV_EXTENSION),
&FilterDeviceName,
FILE_DEVICE_DISK,
0,
FALSE,
&FltDevObj);

UNICODE_STRING VolumeDeviceSymbol;
RtlInitUnicodeString(&VolumeDeviceSymbol, VOLUME_DEVICE_SYMBOL);
status = IoCreateSymbolicLink(&VolumeDeviceSymbol, &FilterDeviceName);

I have written a Volume Filter. Before I named it , it worked correctly.

But after I named it,I found that it was not on the device tree.

Well, you cannot have more than one named device in a PnP stack, right. PDO that the target stack is built upon is named, which means that FDO and filters cannot have their names. Simple, ugh…

Anton Bassov

Well, you cannot have more than one named device in a PnP stack, right

Ah, wrong. The PDO is named, but the FDO can also be named. This creates the famous “two separate protections for the same devnode” problem.

Peter

The PDO is named, but the FDO can also be named.

I mean a “proper” PnP stack, of course. Certainly, IoAttachDeviceToDeviceStack() is going to do its job just fine even if the attached device is named, but various issues may potentially arise later.

For example, consider calling IoAttachDevice() on such a stack. What ‘is the target device object’s StackSize’ field going to be like? Does it depend on the name that callers have specified (i.e. the one of PDO or FDO)? If it does, your FDO’s driver will have to make a distinction between these two cases.

If you need a named FDO, is not it better to implement its logical equivalent as a “unnamed FDO - named standalone DO” pair instead???
It may save you quite a bit of a headache if you do it this way…

This creates the famous “two separate protections for the same devnode” problem.

This is yet another issue with this approach.

It seems to be closely related to the problem the OP is dealing with, and his problem arose only after the OP had decided to make his filter DO named…

Anton Bassov

In a “proper” PnP stack, multiple Device Objects can be named. There is absolutely nothing, architecturally, by implementation, or practically that prevents this. It’s is, in fact still rather common.

Write a WDF driver. Call WdfDeviceInitAssignName. Done. This works. There are many production drivers that do this. This is not an any way prohibited, though the security issue alone makes this a less than best practice.

Peter

1 Like

Peter,

In a “proper” PnP stack, multiple Device Objects can be named. There is absolutely nothing, architecturally,
by implementation, or practically that prevents this.

After having thought carefully about the whole thing I’ve got to admit that the “issue” I have mentioned in my previous post is, in actuality, simply a non-issue indeed. Once you are always getting a pointer to the device that happens to be on top of the stack at the moment, it does not really matter which name you have specified - even if there are multiple names DOs in the stack, you are still going to get a pointer to exactly the same device object anyway

Anton Bassov

1 Like

Anton: Correct. :slight_smile:

1 Like