Hi,
I am implementing a file system filter driver. I would like to ask if the technique I am using is OK. This filter driver denies a file open based on the contents of the file, if the file has a virus access is denied. I have learned from documentation and from this list how to achieve this. But the main problem I have is that the huge virus recognition software (a dll) was made to be executed in user mode. As I intercept the file openings in kernel mode I can’t call this dll directly.
Then I had to make an NT service to call this dll in order to find out if there is virus or not. And I had to synchronize this NT service with my filter driver. Is it worthy to tell my coworkers to make a new virus recognition module that could be called from kernel mode or should I go on as I have until now?
I am having some problems with the way it is now.
I would explain more things about my driver but I don’t want to scare readers because of large e-mails.
One of the problems with using a Win32 service from kernel mode is that some
calls (notably those from Win32) are not constructed to be re-entrant (that
is, the Win32 subsystem does not expect to receive recursive calls FROM the
OS.) These can be handled, but they do arise.
Moving everything to kernel mode is a substantial undertaking as well.
Before I were to look at doing this at the point you describe, I would
really suggest trying to resolve the problems you are having now.
Large e-mails do not scare the folks on this list.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:
-----Original Message-----
From: Ratmil Torres [mailto:xxxxx@seg.inf.cu]
Sent: Friday, September 05, 2003 4:12 PM
To: File Systems Developers
Subject: [ntfsd] filtering technique
Hi,
I am implementing a file system filter driver. I would like to ask if the
technique I am using is OK. This filter driver denies a file open based on
the contents of the file, if the file has a virus access is denied. I have
learned from documentation and from this list how to achieve this. But the
main problem I have is that the huge virus recognition software (a dll) was
made to be executed in user mode. As I intercept the file openings in kernel
mode I can’t call this dll directly.
Then I had to make an NT service to call this dll in order to find out if
there is virus or not. And I had to synchronize this NT service with my
filter driver. Is it worthy to tell my coworkers to make a new virus
recognition module that could be called from kernel mode or should I go on
as I have until now?
I am having some problems with the way it is now.
I would explain more things about my driver but I don’t want to scare
readers because of large e-mails.
—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>
There are A/V products out there that use both methods, so both are
possible.
Ratmil Torres wrote:
Hi,
I am implementing a file system filter driver. I would like to ask if
the technique I am using is OK. This filter driver denies a file open
based on the contents of the file, if the file has a virus access is
denied. I have learned from documentation and from this list how to
achieve this. But the main problem I have is that the huge virus
recognition software (a dll) was made to be executed in user mode. As I
intercept the file openings in kernel mode I can’t call this dll directly.
Then I had to make an NT service to call this dll in order to find out
if there is virus or not. And I had to synchronize this NT service with
my filter driver. Is it worthy to tell my coworkers to make a new virus
recognition module that could be called from kernel mode or should I go
on as I have until now?
I am having some problems with the way it is now.
I would explain more things about my driver but I don’t want to scare
readers because of large e-mails.
–
Nick Ryan (MVP for DDK)
Thank you very much for responding too soon.
Below is how I am syncronizing my driver and the NT service:
- There is a File System Filter Driver and a Windows NT Service.
- The driver takes control of all the file openings.
- When the driver intercepts a file opening (a CREATE call), it sets a
completion routine, marks the IRP as pending and return STATUS_PENDING. - In the Completion Routine the driver verifies that the openning was
successfull. If it is the case the driver saves information about the file
(among other things path and file name) in a queue and wakes up the service
using an event. Then returns STATUS_MORE_PROCESSING_REQUIRED. - The service then gets the information from the queue. Reads the file
(avoiding reentrancy using a shadow device) to see if there are viruses and
sends the result to the driver. - The driver gets the result and complete the request calling
IoCompleteRequest on the IRP that was marked as pending. Setting the result
of the request (STATUS_SUCCESS or STATUS_ACCESS_DENIED) based on the result
of the scanning . In case of access denied IoCancelFileOpen is called.
Maybe I have some bugs I haven’t seen yet. But what I would like to know if
there is something wrong in the technique I have briefly explained.
Thanks.
----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Friday, September 05, 2003 1:34 PM
Subject: [ntfsd] RE: filtering technique
> One of the problems with using a Win32 service from kernel mode is that
some
> calls (notably those from Win32) are not constructed to be re-entrant
(that
> is, the Win32 subsystem does not expect to receive recursive calls FROM
the
> OS.) These can be handled, but they do arise.
>
>
>
> Moving everything to kernel mode is a substantial undertaking as well.
> Before I were to look at doing this at the point you describe, I would
> really suggest trying to resolve the problems you are having now.
>
>
>
> Large e-mails do not scare the folks on this list.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http://www.osr.com http:
>
>
>
> -----Original Message-----
> From: Ratmil Torres [mailto:xxxxx@seg.inf.cu]
> Sent: Friday, September 05, 2003 4:12 PM
> To: File Systems Developers
> Subject: [ntfsd] filtering technique
>
>
>
> Hi,
>
> I am implementing a file system filter driver. I would like to ask if the
> technique I am using is OK. This filter driver denies a file open based on
> the contents of the file, if the file has a virus access is denied. I have
> learned from documentation and from this list how to achieve this. But the
> main problem I have is that the huge virus recognition software (a dll)
was
> made to be executed in user mode. As I intercept the file openings in
kernel
> mode I can’t call this dll directly.
>
> Then I had to make an NT service to call this dll in order to find out if
> there is virus or not. And I had to synchronize this NT service with my
> filter driver. Is it worthy to tell my coworkers to make a new virus
> recognition module that could be called from kernel mode or should I go on
> as I have until now?
>
> I am having some problems with the way it is now.
>
> I would explain more things about my driver but I don’t want to scare
> readers because of large e-mails.
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
></http:>
I implemented FSFD for AV software which synchronizes with user mode
service. I works fine. Though there are lots of things you must be aware of.
-htfv
----- Original Message -----
From: Ratmil Torres
To: File Systems Developers
Sent: Friday, September 05, 2003 11:11 PM
Subject: [ntfsd] filtering technique
Hi,
I am implementing a file system filter driver. I would like to ask if the
technique I am using is OK. This filter driver denies a file open based on
the contents of the file, if the file has a virus access is denied. I have
learned from documentation and from this list how to achieve this. But the
main problem I have is that the huge virus recognition software (a dll) was
made to be executed in user mode. As I intercept the file openings in kernel
mode I can’t call this dll directly.
Then I had to make an NT service to call this dll in order to find out if
there is virus or not. And I had to synchronize this NT service with my
filter driver. Is it worthy to tell my coworkers to make a new virus
recognition module that could be called from kernel mode or should I go on
as I have until now?
I am having some problems with the way it is now.
I would explain more things about my driver but I don’t want to scare
readers because of large e-mails.
You are currently subscribed to ntfsd as: xxxxx@vba.com.by
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes, there is. Read the latest NT Insider’s article about
IoCancelFileOpen().
“Ratmil Torres” wrote in message news:xxxxx@ntfsd…
>
> Thank you very much for responding too soon.
>
> Below is how I am syncronizing my driver and the NT service:
>
> - There is a File System Filter Driver and a Windows NT Service.
> - The driver takes control of all the file openings.
> - When the driver intercepts a file opening (a CREATE call), it sets a
> completion routine, marks the IRP as pending and return STATUS_PENDING.
> - In the Completion Routine the driver verifies that the openning was
> successfull. If it is the case the driver saves information about the file
> (among other things path and file name) in a queue and wakes up the
service
> using an event. Then returns STATUS_MORE_PROCESSING_REQUIRED.
> - The service then gets the information from the queue. Reads the file
> (avoiding reentrancy using a shadow device) to see if there are viruses
and
> sends the result to the driver.
> - The driver gets the result and complete the request calling
> IoCompleteRequest on the IRP that was marked as pending. Setting the
result
> of the request (STATUS_SUCCESS or STATUS_ACCESS_DENIED) based on the
result
> of the scanning . In case of access denied IoCancelFileOpen is called.
>
> Maybe I have some bugs I haven’t seen yet. But what I would like to know
if
> there is something wrong in the technique I have briefly explained.
>
> Thanks.
>
> ----- Original Message -----
> From: “Tony Mason”
> To: “File Systems Developers”
> Sent: Friday, September 05, 2003 1:34 PM
> Subject: [ntfsd] RE: filtering technique
>
>
> > One of the problems with using a Win32 service from kernel mode is that
> some
> > calls (notably those from Win32) are not constructed to be re-entrant
> (that
> > is, the Win32 subsystem does not expect to receive recursive calls FROM
> the
> > OS.) These can be handled, but they do arise.
> >
> >
> >
> > Moving everything to kernel mode is a substantial undertaking as well.
> > Before I were to look at doing this at the point you describe, I would
> > really suggest trying to resolve the problems you are having now.
> >
> >
> >
> > Large e-mails do not scare the folks on this list.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Tony
> >
> >
> >
> > Tony Mason
> >
> > Consulting Partner
> >
> > OSR Open Systems Resources, Inc.
> >
> > http://www.osr.com http:
> >
> >
> >
> > -----Original Message-----
> > From: Ratmil Torres [mailto:xxxxx@seg.inf.cu]
> > Sent: Friday, September 05, 2003 4:12 PM
> > To: File Systems Developers
> > Subject: [ntfsd] filtering technique
> >
> >
> >
> > Hi,
> >
> > I am implementing a file system filter driver. I would like to ask if
the
> > technique I am using is OK. This filter driver denies a file open based
on
> > the contents of the file, if the file has a virus access is denied. I
have
> > learned from documentation and from this list how to achieve this. But
the
> > main problem I have is that the huge virus recognition software (a dll)
> was
> > made to be executed in user mode. As I intercept the file openings in
> kernel
> > mode I can’t call this dll directly.
> >
> > Then I had to make an NT service to call this dll in order to find out
if
> > there is virus or not. And I had to synchronize this NT service with my
> > filter driver. Is it worthy to tell my coworkers to make a new virus
> > recognition module that could be called from kernel mode or should I go
on
> > as I have until now?
> >
> > I am having some problems with the way it is now.
> >
> > I would explain more things about my driver but I don’t want to scare
> > readers because of large e-mails.
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@osr.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
></http:>
Thank you very much to all the people in the list who has helped me with the
answers.
You say there are a lot of things to be aware of. Any suggestion?
----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Friday, September 05, 2003 2:59 PM
Subject: [ntfsd] Re: filtering technique
> I implemented FSFD for AV software which synchronizes with user mode
> service. I works fine. Though there are lots of things you must be aware
of.
>
> -htfv
>
>
>
> ----- Original Message -----
> From: Ratmil Torres
> To: File Systems Developers
> Sent: Friday, September 05, 2003 11:11 PM
> Subject: [ntfsd] filtering technique
>
>
> Hi,
> I am implementing a file system filter driver. I would like to ask if the
> technique I am using is OK. This filter driver denies a file open based on
> the contents of the file, if the file has a virus access is denied. I have
> learned from documentation and from this list how to achieve this. But the
> main problem I have is that the huge virus recognition software (a dll)
was
> made to be executed in user mode. As I intercept the file openings in
kernel
> mode I can’t call this dll directly.
> Then I had to make an NT service to call this dll in order to find out if
> there is virus or not. And I had to synchronize this NT service with my
> filter driver. Is it worthy to tell my coworkers to make a new virus
> recognition module that could be called from kernel mode or should I go on
> as I have until now?
> I am having some problems with the way it is now.
> I would explain more things about my driver but I don’t want to scare
> readers because of large e-mails.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
What about what Tony Mason said about moving everything to kernel mode?
----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Friday, September 05, 2003 2:59 PM
Subject: [ntfsd] Re: filtering technique
> I implemented FSFD for AV software which synchronizes with user mode
> service. I works fine. Though there are lots of things you must be aware
of.
>
> -htfv
>
>
>
> ----- Original Message -----
> From: Ratmil Torres
> To: File Systems Developers
> Sent: Friday, September 05, 2003 11:11 PM
> Subject: [ntfsd] filtering technique
>
>
> Hi,
> I am implementing a file system filter driver. I would like to ask if the
> technique I am using is OK. This filter driver denies a file open based on
> the contents of the file, if the file has a virus access is denied. I have
> learned from documentation and from this list how to achieve this. But the
> main problem I have is that the huge virus recognition software (a dll)
was
> made to be executed in user mode. As I intercept the file openings in
kernel
> mode I can’t call this dll directly.
> Then I had to make an NT service to call this dll in order to find out if
> there is virus or not. And I had to synchronize this NT service with my
> filter driver. Is it worthy to tell my coworkers to make a new virus
> recognition module that could be called from kernel mode or should I go on
> as I have until now?
> I am having some problems with the way it is now.
> I would explain more things about my driver but I don’t want to scare
> readers because of large e-mails.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Moving the whole AV kernel to kernel mode is pain. You might know what I’m
talking about.
-htfv
----- Original Message -----
From: “Ratmil Torres”
To: “File Systems Developers”
Sent: Monday, September 08, 2003 8:49 PM
Subject: [ntfsd] Re: filtering technique
> What about what Tony Mason said about moving everything to kernel mode?
>
> ----- Original Message -----
> From: “Alexey Logachyov”
> To: “File Systems Developers”
> Sent: Friday, September 05, 2003 2:59 PM
> Subject: [ntfsd] Re: filtering technique
>
>
> > I implemented FSFD for AV software which synchronizes with user mode
> > service. I works fine. Though there are lots of things you must be aware
> of.
> >
> > -htfv
> >
> >
> >
> > ----- Original Message -----
> > From: Ratmil Torres
> > To: File Systems Developers
> > Sent: Friday, September 05, 2003 11:11 PM
> > Subject: [ntfsd] filtering technique
> >
> >
> > Hi,
> > I am implementing a file system filter driver. I would like to ask if
the
> > technique I am using is OK. This filter driver denies a file open based
on
> > the contents of the file, if the file has a virus access is denied. I
have
> > learned from documentation and from this list how to achieve this. But
the
> > main problem I have is that the huge virus recognition software (a dll)
> was
> > made to be executed in user mode. As I intercept the file openings in
> kernel
> > mode I can’t call this dll directly.
> > Then I had to make an NT service to call this dll in order to find out
if
> > there is virus or not. And I had to synchronize this NT service with my
> > filter driver. Is it worthy to tell my coworkers to make a new virus
> > recognition module that could be called from kernel mode or should I go
on
> > as I have until now?
> > I am having some problems with the way it is now.
> > I would explain more things about my driver but I don’t want to scare
> > readers because of large e-mails.
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Hi,
Its probably unrealistic to expect the dll to be rewitten for kernel mode,
but flag up the potential performance advantage to your management anyway.
This’ll cover you ass, as they say.
In your situation I’d recommend you write a user mode thread to check a
single (named) file for a virus by opening, reading it, and checking it
using the dll. Then wrap this up as part of an NT service… (you can test
using a simple application first, it’ll translate to a service quite
easily).
To simplify things, when it starts up, the service can send an ioctl to
the driver indicating it is “ready”. At that point the driver can capture
the service process id for use later.
The filter driver simply allows ALL opens originating at your service
process, but ‘checks’ the opens for ALL other processes.
When your filter driver receives an open request from clients (except for
the service), it should indicate this up to the service, passing the file
name. In the meantime its probably right in this case simply to block the
client thread.
The driver can indicate to the service in a number of ways, but I would do
it by responding to a pending ioctl issued earlier by a service thread.
I’d arrange that the service issues a whole bundle of these so that the
driver can never be “starved” when it needs one. Exactly how many?
Configure this in a registry entry for the service.
In this approach, the service (not the driver) then has the responsibility
for allowing or denying an open on any file. It must signal its verdict
back to the driver so that the driver can continue with the open request
on behalf of its client, and ultimately complete it to the requestor.
Again the signalling between service and driver can be done with a simple
ioctl. The driver then either proceeds with (one of) the (blocked) open
request(s) or denies it.
With this approach both components remain clear and manageable. This means
they are fairly quick to develop and you will be able to measure
performance early in the development cycle (that’s presumably the worry
here).
Of course there are still many tricky issues, this note is only intended
to indicate a possible approach. I presume you know that ;-).
Hope this helps,
Jack.
I hope Tony is also willing to give advice on minimizing kernel stack usage
if you do this.
Carl
“Ratmil Torres” wrote in message news:xxxxx@ntfsd…
>
> What about what Tony Mason said about moving everything to kernel mode?
>
This is basic C programming 101. What advice do you need?
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Carl Appellof
Sent: Tuesday, September 09, 2003 9:36 AM
To: File Systems Developers
Subject: [ntfsd] Re: filtering technique
I hope Tony is also willing to give advice on minimizing kernel stack usage
if you do this.
Carl
“Ratmil Torres” wrote in message news:xxxxx@ntfsd…
>
> What about what Tony Mason said about moving everything to kernel mode?
>
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
For the benefit of budding A/V authors, I’ll give a preview of what
Tony’s (and Microsoft’s) answer will contain - switching stacks is NOT
acceptable.
Carl Appellof wrote:
I hope Tony is also willing to give advice on minimizing kernel stack usage
if you do this.
Carl“Ratmil Torres” wrote in message news:xxxxx@ntfsd…
>
>>What about what Tony Mason said about moving everything to kernel mode?
>>
>
>
>
>
>
–
Nick Ryan (MVP for DDK)
Definitely!
-htfv
----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, September 09, 2003 8:37 PM
Subject: [ntfsd] Re: filtering technique
> For the benefit of budding A/V authors, I’ll give a preview of what
> Tony’s (and Microsoft’s) answer will contain - switching stacks is NOT
> acceptable.
>
> Carl Appellof wrote:
>
> > I hope Tony is also willing to give advice on minimizing kernel stack
usage
> > if you do this.
> > Carl
> >
> > “Ratmil Torres” wrote in message news:xxxxx@ntfsd…
> >
> >>What about what Tony Mason said about moving everything to kernel mode?
> >>
> >
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vba.com.by
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Hi.
The antivirus driver is working ok with the driver-service model. But it has a little problem when I try to map a network path to the same pc. For example I map Z: to “\MyComputer\SomePath”, “MyComputer” would be the name of my PC. When an application tries to open a file with name “Z:\anyfile.exe” it falls in deadlock.
I guess that has to do with what Tony Mason said about doing everything in kernel mode.
Loopbacks are tricky, but you can still handle it. Use a thread pool in
your service instead of a single thread. The number of nested dependent
opens you can handle == the number of threads in your pool.
Ratmil Torres wrote:
Hi.
The antivirus driver is working ok with the driver-service model. But it
has a little problem when I try to map a network path to the same pc.
For example I map Z: to “\MyComputer\SomePath
<file:>”, “MyComputer” would be the name of my
> PC. When an application tries to open a file with name
> “Z:\anyfile.exe” it falls in deadlock.
> I guess that has to do with what Tony Mason said about doing everything
> in kernel mode.
>
>
>
–
Nick Ryan (MVP for DDK)</file:>
Yes, that’s what I am doing.
You can open that file two or three times. But comes a time when the
application hangs.
I open an unlimited number of threads, every time request comes I open a new
thread.
----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, September 12, 2003 12:56 PM
Subject: [ntfsd] Re: filtering technique
> Loopbacks are tricky, but you can still handle it. Use a thread pool in
> your service instead of a single thread. The number of nested dependent
> opens you can handle == the number of threads in your pool.
>
> Ratmil Torres wrote:
>
> > Hi.
> > The antivirus driver is working ok with the driver-service model. But it
> > has a little problem when I try to map a network path to the same pc.
> > For example I map Z: to “\MyComputer\SomePath
> > <file:>”, “MyComputer” would be the name of my
> > PC. When an application tries to open a file with name
> > “Z:\anyfile.exe” it falls in deadlock.
> > I guess that has to do with what Tony Mason said about doing everything
> > in kernel mode.
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
></file:>
Can’t tell your filter not to filter opens coming from your service
context? That should nail the problem at the source.
Ratmil Torres wrote:
Yes, that’s what I am doing.
You can open that file two or three times. But comes a time when the
application hangs.
I open an unlimited number of threads, every time request comes I open a new
thread.----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, September 12, 2003 12:56 PM
> Subject: [ntfsd] Re: filtering technique
>
>
>
>>Loopbacks are tricky, but you can still handle it. Use a thread pool in
>>your service instead of a single thread. The number of nested dependent
>>opens you can handle == the number of threads in your pool.
>>
>>Ratmil Torres wrote:
>>
>>
>>>Hi.
>>>The antivirus driver is working ok with the driver-service model. But it
>>>has a little problem when I try to map a network path to the same pc.
>>>For example I map Z: to “\MyComputer\SomePath
>>><file:>”, “MyComputer” would be the name of my
>>>PC. When an application tries to open a file with name
>>>“Z:\anyfile.exe” it falls in deadlock.
>>>I guess that has to do with what Tony Mason said about doing everything
>>>in kernel mode.
>>>
>>>
>>>
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
>
>
–
Nick Ryan (MVP for DDK)</file:>
In fact, if you’re not already doing this, I don’t see how you can avoid
infinite recursion in any scenario. You’ll have to do some intensive
stack snooping in WinDbg to see what’s going on.
Nick Ryan wrote:
Can’t tell your filter not to filter opens coming from your service
context? That should nail the problem at the source.Ratmil Torres wrote:
> Yes, that’s what I am doing.
> You can open that file two or three times. But comes a time when the
> application hangs.
> I open an unlimited number of threads, every time request comes I open
> a new
> thread.
>
> ----- Original Message -----
> From: “Nick Ryan”
>> Newsgroups: ntfsd
>> To: “Windows File Systems Devs Interest List”
>> Sent: Friday, September 12, 2003 12:56 PM
>> Subject: [ntfsd] Re: filtering technique
>>
>>
>>
>>> Loopbacks are tricky, but you can still handle it. Use a thread pool in
>>> your service instead of a single thread. The number of nested dependent
>>> opens you can handle == the number of threads in your pool.
>>>
>>> Ratmil Torres wrote:
>>>
>>>
>>>> Hi.
>>>> The antivirus driver is working ok with the driver-service model.
>>>> But it
>>>> has a little problem when I try to map a network path to the same pc.
>>>> For example I map Z: to “\MyComputer\SomePath
>>>> <file:>”, “MyComputer” would be the name of my
>>>> PC. When an application tries to open a file with name
>>>> “Z:\anyfile.exe” it falls in deadlock.
>>>> I guess that has to do with what Tony Mason said about doing everything
>>>> in kernel mode.
>>>>
>>>>
>>>>
>>>
>>> –
>>> Nick Ryan (MVP for DDK)
>>>
>>>
>>> —
>>> You are currently subscribed to ntfsd as: xxxxx@seg.inf.cu
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>
>>
>>
>>
>>
>
–
Nick Ryan (MVP for DDK)</file:>
You hit re-entrancy issue. File system request from your AV service is
intercepted by kernel mode driver. That’s the most important problem to
solve in driver-service model. You will have to find the way around this.
-htfv
----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Friday, September 12, 2003 10:23 PM
Subject: [ntfsd] filtering technique
Hi.
The antivirus driver is working ok with the driver-service model. But it has
a little problem when I try to map a network path to the same pc. For
example I map Z: to “\MyComputer\SomePath”, “MyComputer” would be the name
of my PC. When an application tries to open a file with name
“Z:\anyfile.exe” it falls in deadlock.
I guess that has to do with what Tony Mason said about doing everything in
kernel mode.
You are currently subscribed to ntfsd as: xxxxx@vba.com.by
To unsubscribe send a blank email to xxxxx@lists.osr.com