Monitoring Communication Between VDO and Storage Stack

NTFSD
1

Hello,

I am working on a filter driver for some time. It filters various kinds
of devices including CD/DVD and memory card reader. Right now, I am
attempting to detect a situation when a media (CD/DVD, memory card…)
is removed from the device. When the media is formatted with certain
file system, such as FAT or CDFS, the corresponding volume is not
dismounted; its VDO is not removed.

I used the IrpTracker tool to do some monitoring and found that the file
system driver periodically checks whether a media is inserted in the
device. The IRP, however, is not sent to the top device in the storage
stack but is directly passed to the device on which the file system
(VDO) is mounted. The same applies for communication between the file
system driver and underlying storage stack.

Is there a way how to monitor the communication between file system
driver and the corresponding device in device stack? For example, it is
possible to force the FS driver to communicate with a different device
than on which the file system is mounted? I am looking for a kind of
documented way, no hooking is desirable if possible.

To give an example:
A media is isnerted into the CD-ROM drive. The file system is
represented by an unnamed device of the CDFS file system driver and is
mounted on the \Device\CdRom0 device. I need to monitor communication
made between the file system and the \Device\CdRom0 device.

Thanks for any help and suggestions.

Best regards
Martin Dráb

Dne 11. 7. 2014 15:00, Scott Noone napsal(a):

This is why kernel HANDLEs exist. See the OBJ_KERNEL_HANDLE flag.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

In defferent places we have different process contexts… and handle
opened in one process context became invalid in other, so for instance i
can’t close handle in FilterMessage callback that was opened in system
process context during driver entry routine.

Is the best way to use FltQueueGenericWorkItem approach and Queue all
open-close handles operations to system process context?
That makes code less readble and more complex… but i don’t see other
choise.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

2

When did you attach your filter to the media stack?

If you attach late (like after mount) then the FSD already has a pointer to the device to which you are attached. IoCallDriver sends the request to the driver specified. Thus, media filters need to be loaded BEFORE the file system has an opportunity to mount on top of the given volume - afterwards is too late.

Tony
OSR

3

Hello,

I attach the filtering device to the storage stack during processing of
the IRP_MN_START_DEVICE request. I am also monitoring file system
control devices so I can see IRP_MN_MOUNT_VOLUME reuqests but since it
is not possible to change Vpb->RealDevice I do not see a way how to
solve my problem just before the mount.

Martin Dráb

Dne 12. 7. 2014 14:19, Tony Mason napsal(a):

When did you attach your filter to the media stack?

If you attach late (like after mount) then the FSD already has a pointer to the device to which you are attached. IoCallDriver sends the request to the driver specified. Thus, media filters need to be loaded BEFORE the file system has an opportunity to mount on top of the given volume - afterwards is too late.

Tony
OSR

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

4

How does this compare to what diskperf is doing? They obviously make this work, so there is a mechanism for accomplishing that.

A quick glance at the WDK code sample for it, they appear to let the PnP manager handle it all (it attaches in the AddDevice entry point).

Tony
OSR

5

Hello,

Thank you for the suggestion. Actually, I looked at source code of
TrueCrypt and DiskCryptor, expecting both must cope with my problem.

TrueCrypt seems to avoid it by creating its own storage device object on
which the file system is then mounted. DiskCryptor uses the AddDevice
approach (it installs itself as a lower filter for the Volume device
class and as an upper filter for the CD-ROM class). So, I know that the
AddDevice approach should work but:

  1. I would prefer not to use it,
  2. I would like to know what’s really behind the fact that it works.
    This is the main reason I decided to ask here.

Well, I should write this in my first post.

Martin Dráb

Dne 12. 7. 2014 15:20, Tony Mason napsal(a):

How does this compare to what diskperf is doing? They obviously make this work, so there is a mechanism for accomplishing that.

A quick glance at the WDK code sample for it, they appear to let the PnP manager handle it all (it attaches in the AddDevice entry point).

Tony
OSR

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

6

The issue is ordering. The volume filter approach ensures that everything gets set up properly before the file system mounts. The approach you are taking doesn’t work because you aren’t being layered in the proper sequence.

Tony
OSR