Hi Don,
I am a novice in the field of driver writing. This is the first project for
me in this field.
I guess my design is on same lines of design proposed by you. I don’t see
any deadlock scenario in case of any GUI control request.
My GUI app creates a device driver object and sends all the control request
through that device driver object.
All the file system calls either by my GUI app or a user app are made by
calling user-mode CreateFile()/ReadFile()/WriteFile APIs. My driver design
is based on the FileMon driver.
Let me try to explain the sequence of events again:
- GUI app created a device driver object and sent a control request to
hook to drives.
- GUI app sends another control request to pass a comman event object
to the driver.
- User app starts up and starts making File system calls.
- File Syetm Drivers intercpets the File system calls made by User app.
It then holds the IRP_MJ_READ/FAST_IO_READ calls and checks with the GUI
app(GUI app actually wakes up on an event set up by driver) whether to
release the call or keep waiting till the relevant data has been fetched by
GUI.
- On receiving the relevant data from driver, GUI app checks a data table
to see if the data needed by ReadFile() call is already there. If it is
already there, it sets up an comman event object to wake up the filter
driver. Otherwise, it gathers the relevant data, opens up the relevant
file(using CreateFile()) and writes to the file. On completeion, it sets the
comman object so as to wake up the driver.
Dead lock happens when savrt.sys driver (Anti Virus) waits on same resource
during the CreateFile() call that has been acquired by ReadFile() call. I
can’t release the ReadFile() call till I am able to open up the file and
write data to it. Only solution I see to my problem is If my driver is on
the top of the stack. In that case when I hold the ReadFile() call, I won’t
be holding up any resources of other drivers. But as you said, even after
making my driver as a boot-start driver it looks like I can’t control the
layering order.
Please let me know if you still need to some more information to understand
the problem.
Thansk & Regards,
Mahesh Bajaj
“Don Burn” wrote in message news:xxxxx@ntfsd…
> I guess I need to know more, from your initial description I believed you
> had one device object that was used for both the file system filtering and
> for control requests from the GUI. Assuming this, it is perfectly legal
for
> NAV to hold your GUI request while the other request is being processed,
> unfortunately that produces a deadlock.
>
> I was proposing a design where your filter layers as normal with a device
> object attaching to the file system stack. There should be a second
device
> object which you create in your filter that does not appear in the storage
> stack. This device object then can be accessed by the GUI without any
> impact from NAV.
>
> If you are doing something other than the first model, please explain
things
> further since I am not sure what is happening.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
>
>
> “Mahesh Bajaj” wrote in message
> news:xxxxx@ntfsd…
> > Hi Don,
> > Thanks for a quick answer.
> >
> > I am not able to completely understand what you are trying me to do.
> >
> > My application is a on-demand kind of application. My application have
to
> > get the data as and when that particular user application needs. Assume
> that
> > user application uses a set of files that has got the inital data just
to
> > start the user app. When user app needs the data that’s not already
there,
> > my filter driver will intercept that call and then requests the GUI app
to
> > get the releavnt data. Once the data is there, GUI app has to open the
> same
> > file to write to it.
> >
> > GUI app uses my filter driver for controlling purpose only, just to get
> the
> > files names, offsets requested and to set the event back to release the
> > filter driver. User application doesn’t have a direct interaction with
the
> > filter driver. It just makes regular user-mode file system calls.
> >
> > Also, Only GUI app uses device object for control purposes.
> >
> > Can you please give some more details about the things that you want me
to
> > try.
> >
> > Thanks,
> > Mahesh Bajaj
> >
> >
> > “Don Burn” wrote in message news:xxxxx@ntfsd…
> > > First you will never be able to control the order, so if your filter
> > cannot
> > > work with NAV above or below you then there is a problem. The big
> problem
> > I
> > > see is it appears you are trying to use the file system path for both
> your
> > > GUI and the user program you care about. This design means you have
to
> be
> > > concerned about all of the effects other filters can have on you GUI
> app,
> > > personally I don’t think you can ever get this to work safely.
> > >
> > > Have you considered creating a different interface for your GUI?
Using
> a
> > > second device object for control purposes would mean that NAV does not
> > > impact the control path, and therefore should get rid of the problem
as
> > you
> > > describe it.
> > >
> > >
> > > –
> > > Don Burn (MVP, Windows DDK)
> > > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > Remove StopSpam from the email to reply
> > >
> > > “Mahesh Bajaj” wrote in message
> > > news:xxxxx@ntfsd…
> > > > Hi All,
> > > >
> > > > I am writing a file system filter driver.
> > > >
> > > > Job of the file system filter driver is to hold a ReadFile() call
made
> > by
> > > a
> > > > particular use application. After holding up a readfile() call, it
> sets
> > up
> > > > an event for the GUI application so that GUI application can bring
the
> > > data
> > > > for the file ( for the file against which the readfile() call was
> made)
> > > and
> > > > once the data for the file has been written to the file, it lets the
> > file
> > > > system driver release the readfile() call. I am not holding any
paging
> > IO
> > > > calls.
> > > >
> > > > Application works great when Symantec norton anti virus is not
> > installed.
> > > > But If I run the application where Symantec norton anti virus is
> > > installed,
> > > > It deadlocks. I have seen in my debug logs that file system filter
> > driver
> > > is
> > > > waiting on a resource (in the CreateFile() call made by GUI
> > application)
> > > > that drivers holds in the ReadFile() call.
> > > >
> > > > When the a user application makes a ReadFile() call, it first goes
to
> > > > savrt.sys (anti virus driver). savrt.sys locks a resource(mutant)
> there.
> > > It
> > > > then passes over to my file system filter driver. My file system
> filter
> > > > driver then holds the ReadFile() call till the GUI app signals to
> filter
> > > > driver for release. GUI application on receiving the event from File
> > Sytem
> > > > driver, tries to open the relevant file by making a CreateFile()
call
> so
> > > > that it can write to the data.
> > > >
> > > > CreateFile() call first goes to savrt.sys driver that waits on the
> same
> > > > resource that was locked in the held up ReadFile() call.
> > > >
> > > > If I make my file system filter driver to be called up at the very
> first
> > > of
> > > > the list( IO manager should pass all file system calls to my driver
> > first
> > > > then to other (like savrt.sys) drivers), then whole of my design can
> > work.
> > > >
> > > > I made my driver to be ‘boot start’ driver so as to load it before
any
> > > other
> > > > anti virus driver. But still the problem hasn’t gone away. When I
see
> my
> > > > debug log, it still calls up savrt.sys driver first.
> > > >
> > > > Is there a way to make sure that my filter driver is called first in
> the
> > > > list always?
> > > >
> > > > Please let me know if you need any other information.
> > > >
> > > > Thanks alot,
> > > > Mahesh
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>