Hi,
I am trying to write a file system filter driver, which is indeed an AV
driver delaying the IRP_MJ_CREATE while scanning the file being accessed for
viruses. The scan is performed at the user space. I have a couple of
questions.
Assuming the scan takes some arbitrary time t, which is the most vital
parameter from the performance point of view, I would like know other
factors that may have significant affects on the system performance.
1- As I recall from the MS documentations, one of these factors are
dispather lock contention problem. If I implement the driver with the
following strategy, " Upon getting an IRP_MJ_CREATE, i create a named event
object and issue KeWaitForSingleObject on that object so that after scan is
completed by the user mode service, i chain the IRP to lower filter drivers"
obviously this implementation will have the dispather lock contention
problem. Because KeWait… is issued for each IRP_MJ_CREATE request.
Can anybody show me a known workaround for this problem if any?
While trying to find a workaround, i tried various strategies to see if
something makes difference :
2- As a second option, i tried marking the IRP as pending and later
processing it. For this, i mark the IRP as pending and add it to a
processing queue and return status_pending. Then in another system thread
created while driver is initialized i tried to process them. Indeed this
model did not work because after processing a few IRPs, the system bugchecks
and ntoskernel complains about the SeValidSecurityDescriptor +
42(IRQL_NOT_LESS…). I thought this would be because i am changing the
context of the current IRP_MJ_CREATE IRP so NTFS fails to apply security
checks. Would it be a case? But if I create a system worker thread per
request and process the pending IRP in it, such an error does not
happen(Creating a worker thread per request is obviously a very bad thing
though).
Marking IRP_MJ_CREATE IRPs as pending is what is not recomended by Microsoft
AFAIK, since IRP_MJ_CREATE requests are syncronous, if i mark them pending,
io manager still waits for it by issuing KeWaitXXX calls. So would this
approach have anything to do with dispather lock contention problem?
Any comment is appreciated.
Regards,
Egemen Tas