NuMega DriverWorks based filter for logging names of opened files

Hi,

I writing a file filter driver with the DriverWorks class libs and can’t seem to get attached correctly so that I can get
access to names of files as they are opened.

I’ve paid my dues and then some with the MS DDK FileSpy sample and thought I understood pretty solidly what that code does to
filter CREATE irps and get these filenames in hand but haven’t been able to replicate that functionality in my DriverWorks
WDM driver.

At present, I’m using IoRegisterFsRegistrationChange() to ostensibly get called back with everything I want to attach to but
the net result is that my subsequently attached object seems to see a CREATE irp once in awhile whereas the ‘same code’ in
FileSpy swamps the machine with CREATE irp logging.

Basically, I’m at the point where I think I just need to see one of these things that actually works. :slight_smile: Wondering if anyone
can shoot me to a sample DriverWorks filter that just demonstrates how to correctly detect and attach to the drives on the
box (hopefully fixed drives, PnP, USB, whatever) so that I can see the file CREATE irps.

Thanks in advance for any help or sample code anyone can shed on this,

Dex

There is only one thing that comes to mind here: is your Driverworks driver loaded at boot time? FileSpy does not require
loading at boot time, as it can attach to drive letters, or volume mount points dynamically, a driver using
IoRegisterFsRegistrationChange cannot.

“Dexter St. George” wrote:

Hi,

I writing a file filter driver with the DriverWorks class libs and can’t seem to get attached correctly so that I can get
access to names of files as they are opened.

I’ve paid my dues and then some with the MS DDK FileSpy sample and thought I understood pretty solidly what that code does to
filter CREATE irps and get these filenames in hand but haven’t been able to replicate that functionality in my DriverWorks
WDM driver.

At present, I’m using IoRegisterFsRegistrationChange() to ostensibly get called back with everything I want to attach to but
the net result is that my subsequently attached object seems to see a CREATE irp once in awhile whereas the ‘same code’ in
FileSpy swamps the machine with CREATE irp logging.

Basically, I’m at the point where I think I just need to see one of these things that actually works. :slight_smile: Wondering if anyone
can shoot me to a sample DriverWorks filter that just demonstrates how to correctly detect and attach to the drives on the
box (hopefully fixed drives, PnP, USB, whatever) so that I can see the file CREATE irps.

Thanks in advance for any help or sample code anyone can shed on this,

Dex


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

If your driver do not load before any other FSDs your solution will work
only on XP and later OS.
I suggest that your driver do not attach device objects to the file system’s
mounted device objects instead it attach device object to a device object
which is used for sending mount requests to the FSD(file system driver).
After registering for the notification with IoRegisterFsRegistrationChange()
your callback function will be called with a device object ( as a first
parameter ) which represents a loaded FSD but not any mounted device
objects( which used for handling create requests), this device object is
used by the system to send mount requests, this device object is not used
for handling any disk’s partitions. If you want to filter create requests,
you must attach your device object to the FSD’s device object during mount
request processing. If your driver is loaded after FSDs and your callback
function is called for this FSDs( i.e. this is XP/2003 OS ) you can use
IoEnumerateDeviceObjectList() to get all FSD’s device objects and attach to
them.

“Dexter St. George” wrote in message
news:xxxxx@ntfsd…
>
> Hi,
>
> I writing a file filter driver with the DriverWorks class libs and can’t
> seem to get attached correctly so that I can get
> access to names of files as they are opened.
>
> I’ve paid my dues and then some with the MS DDK FileSpy sample and thought
> I understood pretty solidly what that code does to
> filter CREATE irps and get these filenames in hand but haven’t been able
> to replicate that functionality in my DriverWorks
> WDM driver.
>
> At present, I’m using IoRegisterFsRegistrationChange() to ostensibly get
> called back with everything I want to attach to but
> the net result is that my subsequently attached object seems to see a
> CREATE irp once in awhile whereas the ‘same code’ in
> FileSpy swamps the machine with CREATE irp logging.
>
> Basically, I’m at the point where I think I just need to see one of these
> things that actually works. :slight_smile: Wondering if anyone
> can shoot me to a sample DriverWorks filter that just demonstrates how to
> correctly detect and attach to the drives on the
> box (hopefully fixed drives, PnP, USB, whatever) so that I can see the
> file CREATE irps.
>
>
> Thanks in advance for any help or sample code anyone can shed on this,
>
> Dex
>
>
>

Thanks Slava,

I thought I was already doing all of that actually. Again, I went and pretty exactingly replicated that functionality from
the DDK FileSpy sample, where they do just that - use IoRegisterFsRegistrationChange() to get called back and then in that
callback use IoEnumerateDeviceObjectList() to get the list of devices and attach to them. If that’s supposed to be all there
is to it then maybe it’s more the case where I’m doing what I should be doing, but just have a bug in the doing of it. :slight_smile:
Guess I’ll have to take another stepwalk through it in the debugger.

Regarding the device object hierarchy you outlined, I’ve become ‘slightly’ familiar with it mostly through the bloody-nosed
process of just studying FileSpy and but would definitely benefit from a clearer understanding. Is there a decent reference
somewhere you can point me to for a discussion of FSD objects vs. the actual mounted devices objects vs. the ‘base disk
objects’ (i.e. as obtained from IoDiskDeviceObject()). That and anything regarding their interactions - e.g. what you
mentioned about the sequence of events surrounding mount requests.

I’ll need to get into some finer details pretty quick here simply because, like you mentioned, the callback mechanism I’m
using won’t tell me about the drives mounted previous to my call to IoRegisterFsRegistrationChange() if running on OSs prior
to XP. So at some time in the near future, after simply getting the attach code working, I’m going to have to have to use
something other than the callback mechanism to get and maintain a list of all mounted drives.

Thanks much for your help,

Dex

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Thursday, February 16, 2006 3:12 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] NuMega DriverWorks based filter for logging names of opened files

If your driver do not load before any other FSDs your solution will work only on XP and later OS.
I suggest that your driver do not attach device objects to the file system’s mounted device objects instead it attach device
object to a device object which is used for sending mount requests to the FSD(file system driver).
After registering for the notification with IoRegisterFsRegistrationChange() your callback function will be called with a
device object ( as a first parameter ) which represents a loaded FSD but not any mounted device objects( which used for
handling create requests), this device object is used by the system to send mount requests, this device object is not used
for handling any disk’s partitions. If you want to filter create requests, you must attach your device object to the FSD’s
device object during mount request processing. If your driver is loaded after FSDs and your callback function is called for
this FSDs( i.e. this is XP/2003 OS ) you can use
IoEnumerateDeviceObjectList() to get all FSD’s device objects and attach to them.

“Dexter St. George” wrote in message news:xxxxx@ntfsd…
>
> Hi,
>
> I writing a file filter driver with the DriverWorks class libs and
> can’t seem to get attached correctly so that I can get access to names
> of files as they are opened.
>
> I’ve paid my dues and then some with the MS DDK FileSpy sample and
> thought I understood pretty solidly what that code does to filter
> CREATE irps and get these filenames in hand but haven’t been able to
> replicate that functionality in my DriverWorks WDM driver.
>
> At present, I’m using IoRegisterFsRegistrationChange() to ostensibly
> get called back with everything I want to attach to but the net result
> is that my subsequently attached object seems to see a CREATE irp once
> in awhile whereas the ‘same code’ in FileSpy swamps the machine with
> CREATE irp logging.
>
> Basically, I’m at the point where I think I just need to see one of
> these things that actually works. :slight_smile: Wondering if anyone can shoot me
> to a sample DriverWorks filter that just demonstrates how to correctly
> detect and attach to the drives on the box (hopefully fixed drives,
> PnP, USB, whatever) so that I can see the file CREATE irps.
>
>
> Thanks in advance for any help or sample code anyone can shed on this,
>
> Dex
>
>
>


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@diamondsierra.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

The flow of the mount process is outlined in (chapter 11)->“What Happens
After the FSD Is Loaded” in R.Nagar “Windows NT File Systems Internals”, you
can buy it at OSR’s bookstore, or you can see IRP_MN_MOUNT_VOLUME processing
code in any FSD source code. Use OSR’s DeviceTree to see whether your driver
actually attaches device objects to FSD’s device objects.

“Dexter St.George” wrote in message
news:xxxxx@ntfsd…
> Thanks Slava,
>
> I thought I was already doing all of that actually. Again, I went and
> pretty exactingly replicated that functionality from
> the DDK FileSpy sample, where they do just that - use
> IoRegisterFsRegistrationChange() to get called back and then in that
> callback use IoEnumerateDeviceObjectList() to get the list of devices and
> attach to them. If that’s supposed to be all there
> is to it then maybe it’s more the case where I’m doing what I should be
> doing, but just have a bug in the doing of it. :slight_smile:
> Guess I’ll have to take another stepwalk through it in the debugger.
>
> Regarding the device object hierarchy you outlined, I’ve become ‘slightly’
> familiar with it mostly through the bloody-nosed
> process of just studying FileSpy and but would definitely benefit from a
> clearer understanding. Is there a decent reference
> somewhere you can point me to for a discussion of FSD objects vs. the
> actual mounted devices objects vs. the ‘base disk
> objects’ (i.e. as obtained from IoDiskDeviceObject()). That and anything
> regarding their interactions - e.g. what you
> mentioned about the sequence of events surrounding mount requests.
>
> I’ll need to get into some finer details pretty quick here simply because,
> like you mentioned, the callback mechanism I’m
> using won’t tell me about the drives mounted previous to my call to
> IoRegisterFsRegistrationChange() if running on OSs prior
> to XP. So at some time in the near future, after simply getting the attach
> code working, I’m going to have to have to use
> something other than the callback mechanism to get and maintain a list of
> all mounted drives.
>
> Thanks much for your help,
>
> Dex
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
> Sent: Thursday, February 16, 2006 3:12 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] NuMega DriverWorks based filter for logging names of
> opened files
>
> If your driver do not load before any other FSDs your solution will work
> only on XP and later OS.
> I suggest that your driver do not attach device objects to the file
> system’s mounted device objects instead it attach device
> object to a device object which is used for sending mount requests to the
> FSD(file system driver).
> After registering for the notification with
> IoRegisterFsRegistrationChange() your callback function will be called
> with a
> device object ( as a first parameter ) which represents a loaded FSD but
> not any mounted device objects( which used for
> handling create requests), this device object is used by the system to
> send mount requests, this device object is not used
> for handling any disk’s partitions. If you want to filter create requests,
> you must attach your device object to the FSD’s
> device object during mount request processing. If your driver is loaded
> after FSDs and your callback function is called for
> this FSDs( i.e. this is XP/2003 OS ) you can use
> IoEnumerateDeviceObjectList() to get all FSD’s device objects and attach
> to them.
>
> “Dexter St. George” wrote in message
> news:xxxxx@ntfsd…
>>
>> Hi,
>>
>> I writing a file filter driver with the DriverWorks class libs and
>> can’t seem to get attached correctly so that I can get access to names
>> of files as they are opened.
>>
>> I’ve paid my dues and then some with the MS DDK FileSpy sample and
>> thought I understood pretty solidly what that code does to filter
>> CREATE irps and get these filenames in hand but haven’t been able to
>> replicate that functionality in my DriverWorks WDM driver.
>>
>> At present, I’m using IoRegisterFsRegistrationChange() to ostensibly
>> get called back with everything I want to attach to but the net result
>> is that my subsequently attached object seems to see a CREATE irp once
>> in awhile whereas the ‘same code’ in FileSpy swamps the machine with
>> CREATE irp logging.
>>
>> Basically, I’m at the point where I think I just need to see one of
>> these things that actually works. :slight_smile: Wondering if anyone can shoot me
>> to a sample DriverWorks filter that just demonstrates how to correctly
>> detect and attach to the drives on the box (hopefully fixed drives,
>> PnP, USB, whatever) so that I can see the file CREATE irps.
>>
>>
>> Thanks in advance for any help or sample code anyone can shed on this,
>>
>> Dex
>>
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@diamondsierra.com To
> unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>

For me, looks like a good cause to abandon DriverWorks.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Dexter St. George”
To: “Windows File Systems Devs Interest List”
Sent: Thursday, February 16, 2006 7:21 AM
Subject: [ntfsd] NuMega DriverWorks based filter for logging names of opened
files

>
> Hi,
>
> I writing a file filter driver with the DriverWorks class libs and can’t seem
to get attached correctly so that I can get
> access to names of files as they are opened.
>
> I’ve paid my dues and then some with the MS DDK FileSpy sample and thought I
understood pretty solidly what that code does to
> filter CREATE irps and get these filenames in hand but haven’t been able to
replicate that functionality in my DriverWorks
> WDM driver.
>
> At present, I’m using IoRegisterFsRegistrationChange() to ostensibly get
called back with everything I want to attach to but
> the net result is that my subsequently attached object seems to see a CREATE
irp once in awhile whereas the ‘same code’ in
> FileSpy swamps the machine with CREATE irp logging.
>
> Basically, I’m at the point where I think I just need to see one of these
things that actually works. :slight_smile: Wondering if anyone
> can shoot me to a sample DriverWorks filter that just demonstrates how to
correctly detect and attach to the drives on the
> box (hopefully fixed drives, PnP, USB, whatever) so that I can see the file
CREATE irps.
>
>
> Thanks in advance for any help or sample code anyone can shed on this,
>
> Dex
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com