Hi,
Is it possible to attach to a Volume object (DeviceObject) at runtime? Our
driver is a PnP driver and it sends us “AddDevice” only at boot time where
we attach to the volume object. We need to be able to do this at runtime, is
there a way? “IoGetDeviceObjectPointer” seems to be one way of doing this.
IoGetDeviceObjectPointer takes name as input, for volume what name should I
give? For “\.\E:”, it attaches to FileSystem object.
Thanks,
Sunil
Hi,
Is it possible to attach to a Volume object (DeviceObject) at runtime?
What are you trying to do? Attaching your filter after the stacks are built
isn’t going to get you much, you’ll be bypassed for most I/O operations
because you attached too late.
IoGetDeviceObjectPointer takes name as input, for volume what name should I
give?
Not all volumes have drive letters (you can mount a volume as a folder), so
using letters is a mistake. You can call IoGetDeviceInterfaces to get all of
the volume devices in the system.
For “\.\E:”, it attaches to FileSystem object.
What access are you asking for? If you ask for data access then the open is
going to go through the VPB to the file system.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Sunil Patil” wrote in message news:xxxxx@ntdev…
Hi,
Is it possible to attach to a Volume object (DeviceObject) at runtime? Our
driver is a PnP driver and it sends us “AddDevice” only at boot time where
we attach to the volume object. We need to be able to do this at runtime, is
there a way? “IoGetDeviceObjectPointer” seems to be one way of doing this.
IoGetDeviceObjectPointer takes name as input, for volume what name should I
give? For “\.\E:”, it attaches to FileSystem object.
Thanks,
Sunil
Can proceed as follows:
* register IoRegisterPlugPlayNotification(…, GUID_DEVINTERFACE_VOLUME, …)
* callback: if NotificationStructure->Event is GUID_DEVICE_INTERFACE_ARRIVAL then NotificationStructure->SymbolicLinkName is name of volume device object
GetDeviceObjectPointer must be called with (NotificationStructure->SymbolicLinkName)
Do this logically.
Your driver can be a simple pass-through in the stack but provide
additional logic only when knob(e.g via ioctl) is turned on for a
particular volume.
Harish
From: Sunil Patil [mailto:xxxxx@gmail.com]
Sent: Tuesday, September 28, 2010 9:43 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Attaching to Volume Object at runtime
Hi,
Is it possible to attach to a Volume object (DeviceObject) at runtime?
Our driver is a PnP driver and it sends us “AddDevice” only at boot time
where we attach to the volume object. We need to be able to do this at
runtime, is there a way? “IoGetDeviceObjectPointer” seems to be one way
of doing this.
IoGetDeviceObjectPointer takes name as input, for volume what name
should I give? For “\.\E:”, it attaches to FileSystem object.
Thanks,
Sunil
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
and other 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
> Is it possible to attach to a Volume object (DeviceObject) at runtime?
> What are you trying to do? Attaching your filter after the stacks are
built isn’t going to get you much, you’ll be bypassed for most I/O
operations because you >> attached too late.
I am fine if I miss initial IOs, prior to attach. But after successful
attach, will my driver still be bypassed? Is there a way to intercept IOs
after attach. Will “IoRegisterPlugPlayNotification” suggested in this mail
thread work (help in intercepting IOs after attach)?
“Sunil Patil” wrote in message news:xxxxx@ntdev…
>
> Hi,
>
> Is it possible to attach to a Volume object (DeviceObject) at runtime? Our
> driver is a PnP driver and it sends us “AddDevice” only at boot time where
> we attach to the volume object. We need to be able to do this at runtime, is
> there a way? “IoGetDeviceObjectPointer” seems to be one way of doing this.
>
> IoGetDeviceObjectPointer takes name as input, for volume what name should I
> give? For “\.\E:”, it attaches to FileSystem object.
>
> Thanks,
> Sunil
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
You really have to install while the stack is being created by registering
as a volume upper or lower filter driver. That is the programming model for
driver stacks in windows. As you have been told, you can acheive the effect
you want by having a default ‘passive filter’ mode.
Mark Roddy
On Wed, Sep 29, 2010 at 7:06 AM, Sunil Patil wrote:
>
> Is it possible to attach to a Volume object (DeviceObject) at runtime?
>>
>
> >> What are you trying to do? Attaching your filter after the stacks are
> built isn’t going to get you much, you’ll be bypassed for most I/O
> operations because you >> attached too late.
>
> I am fine if I miss initial IOs, prior to attach. But after successful
> attach, will my driver still be bypassed? Is there a way to intercept IOs
> after attach. Will “IoRegisterPlugPlayNotification” suggested in this mail
> thread work (help in intercepting IOs after attach)?
>
>
>>
>> “Sunil Patil” wrote in message news:xxxxx@ntdev…
>>
>> Hi,
>>
>> Is it possible to attach to a Volume object (DeviceObject) at runtime? Our
>> driver is a PnP driver and it sends us “AddDevice” only at boot time where
>> we attach to the volume object. We need to be able to do this at runtime, is
>> there a way? “IoGetDeviceObjectPointer” seems to be one way of doing this.
>>
>> IoGetDeviceObjectPointer takes name as input, for volume what name should
>> I give? For “\.\E:”, it attaches to FileSystem object.
>>
>> Thanks,
>> Sunil
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>>
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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
>
>> You really have to install while the stack is being created by
registering as a volume upper or lower filter driver. That is the
programming model for driver stacks >> in windows. As you have been told,
you can acheive the effect you want by having a default ‘passive filter’
mode.
I tried both approaches:
IoGetDeviceInterfaces to get list of all volumes, then
IoGetDeviceObjectPointer on each volume and then attached my device object
to volume object.
* register IoRegisterPlugPlayNotification(…, GUID_DEVINTERFACE_VOLUME,
…)
* callback: if NotificationStructure->Event is
GUID_DEVICE_INTERFACE_ARRIVAL then NotificationStructure->SymbolicLinkName
is name of volume device object. IoGetDeviceObjectPointer called with
(NotificationStructure->SymbolicLinkName), then attached my device object to
volume object.
In both cases, found that if I use access_mask “STANDARD_RIGHTS_WRITE |
STANDARD_RIGHTS_READ” in IoGetDeviceObjectPointer with volume-object as
input, then my device object is stacked above “volsnap” device object, but
my driver is by-passed (for READs/WRITEs) for all existing volumes but for
new volumes (created after driver load) my driver gets the IOs.
If I use access_mask “STANDARD_RIGHTS_ALL” in IoGetDeviceObjectPointer with
volume-object as input, then my device object is stacked above
“\FileSystem\FltMgr” device object (which is not desired), but my driver
gets all IOs (performed on FileSystem).
> As you have been told, you can acheive the effect you want by having a
default ‘passive filter’ mode.
How do I achieve the effect I want? I have tried both methods. Am I using
correct access_mask? There was some suggestion to enable filtering by means
of some IOCTL, can somebody elaborate on this.
On Wed, Sep 29, 2010 at 6:32 PM, Mark Roddy wrote:
>
> On Wed, Sep 29, 2010 at 7:06 AM, Sunil Patil wrote:
>
>>
>> Is it possible to attach to a Volume object (DeviceObject) at runtime?
>>>
>>
>> >> What are you trying to do? Attaching your filter after the stacks are
>> built isn’t going to get you much, you’ll be bypassed for most I/O
>> operations because you >> attached too late.
>>
>> I am fine if I miss initial IOs, prior to attach. But after successful
>> attach, will my driver still be bypassed? Is there a way to intercept IOs
>> after attach. Will “IoRegisterPlugPlayNotification” suggested in this mail
>> thread work (help in intercepting IOs after attach)?
>>
>>
>>>
>>> “Sunil Patil” wrote in message news:xxxxx@ntdev…
>>>
>>> Hi,
>>>
>>> Is it possible to attach to a Volume object (DeviceObject) at runtime?
>>> Our driver is a PnP driver and it sends us “AddDevice” only at boot time
>>> where we attach to the volume object. We need to be able to do this at
>>> runtime, is there a way? “IoGetDeviceObjectPointer” seems to be one way of
>>> doing this.
>>>
>>> IoGetDeviceObjectPointer takes name as input, for volume what name should
>>> I give? For “\.\E:”, it attaches to FileSystem object.
>>>
>>> Thanks,
>>> Sunil
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other 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
>>>
>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other 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
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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
You have to install as a proper upper filter… Forget attaching to a stack that already exists. Several people, including SNoone in his initial reply, have told you that attaching to the stack after it’s already been built won’t work. They’re right.
As Mr. Roddy said… Install your driver as a normal filter.
Peter
OSR
Thanks for the confirmation. I will stop exploring this. This gives me an
impression that “Reboot is a must in Windows if I want to install my volume
filter driver” seems too restrictive, as in other OSes ex, Linux, Solaris it
can be done at run-time and does not need Reboot.
On Thu, Sep 30, 2010 at 6:48 PM, wrote:
> You have to install as a proper upper filter… Forget attaching to a stack
> that already exists. Several people, including SNoone in his initial reply,
> have told you that attaching to the stack after it’s already been built
> won’t work. They’re right.
>
> As Mr. Roddy said… Install your driver as a normal filter.
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
If that is too difficult then indeed you should stick to
implementation on Solaris.
Mark Roddy
On Thu, Sep 30, 2010 at 11:28 AM, Sunil Patil wrote:
> Thanks for the confirmation. I will stop exploring this. This gives me an
> impression that “Reboot is a must in Windows if I want to install my volume
> filter driver” seems too restrictive, as in other OSes ex, Linux, Solaris it
> can be done at run-time and does not need Reboot.
>
> On Thu, Sep 30, 2010 at 6:48 PM, wrote:
>>
>> You have to install as a proper upper filter… Forget attaching to a
>> stack that already exists. ?Several people, including SNoone in his initial
>> reply, have told you that attaching to the stack after it’s already been
>> built won’t work. ?They’re right.
>>
>> As Mr. Roddy said… Install your driver as a normal filter.
>>
>> Peter
>> OSR
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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
At the risk of going out of topic, Please explain how you managed to
insert your layer into bdev switch on solaris in a fail safe manner.
This black magic has evaded me.
Harish
From: Sunil Patil [mailto:xxxxx@gmail.com]
Sent: Thursday, September 30, 2010 8:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Attaching to Volume Object at runtime
Thanks for the confirmation. I will stop exploring this. This gives me
an impression that “Reboot is a must in Windows if I want to install my
volume filter driver” seems too restrictive, as in other OSes ex, Linux,
Solaris it can be done at run-time and does not need Reboot.
On Thu, Sep 30, 2010 at 6:48 PM, wrote:
You have to install as a proper upper filter… Forget attaching to a
stack that already exists. Several people, including SNoone in his
initial reply, have told you that attaching to the stack after it’s
already been built won’t work. They’re right.
As Mr. Roddy said… Install your driver as a normal filter.
Peter
OSR
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
and other 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