How to get USB info for WPD storage device?

NTFSD
1

I kind of posted this in another thread yesterday on NTDEV, but didn’t really get an answer.

I have a minifilter that is attempting to only filter USB devices. WPD devices, such as my iPhone connected via USB, count.

So, normally in my minifilter’s InstanceSetup, (or a work item, haven’t figured out if that is necessary yet?) I can get the disk device object via FltGetDiskDeviceObject, and usually I can send an IOCTL_STORAGE_QUERY_PROPERTY IRP to that device and get the bus type as USB (haven’t been sure if that is dependable – apparently it isn’t). The WPD storage device reports its bus type as Scsi.

So, no problem, I can also send an IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS request to this same disk device to get the VolumeExt->Extents[0].DiskNumber and use that to create a name and thus open the real disk device by name. That device, or it’s PDO, can be used to query all kinds of USB info. However, the WPD volume’s disk device apparently doesn’t support IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS (returns STATUS_INVALID_DEVICE_REQUEST).

So, is there a way to determine if a WPD storage device is USB connected?

I suppose I could try creating a disk filter and see if I can correlate something I do from the minifilter with a specific instance of my disk filter, but yucky!

Has anyone noticed this weirdness with WPD?

Thanks for any help!

-Fred

2

What did you mean by a file system minifilter attached to a WPD device?

As far as I know a general WPD storage is managed by a MS UMDF driver. It doesn’t have storage stack and a mounted file system. WPD uses a protocol for communication between a host and a device. WPD device doesn’t expose file system at the block level, instead an interface for media transfer is exported.

If you have a file system mounted on a USB storage device this is either a device with the standard USBSTOR interface or a proprietary storage driver implementation for WPD that emulates a block device.

Did I miss something and MS reimplemented WPD stack?

3

AH, that makes sense! It was a circus of errors on my part. I had a USB storage device plugged in I didn’t realize (didn’t notice it didn’t go away when I unplugged the phone either. And when I plugged in the phone my minifilter was getting a shot at a device it had already rejected before which is fine, but I mapped that to the phone in my head. Sorry for the nonsense. The universe makes sense again. So, interesting that a volume on a scsi drive on my machine doesn’t support IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS?? I thought all volumes had to support that?