Hi,
I’m totally desperate about this, and would appreciate ANY help and
suggestions:
I’m developing a file system filter driver. Basically, what I want to do is,
on each CREATE operation, check if the file opened is of a special type, for
which I need to do some reads on that file. I let the create IRP pass
through and wait for its termination (I know CREATE is always synchronous,
but just in case I set a completion routine which sets and event and then
wait for the event). If the create IRP succeeds, then I use the file object
to perform all the necessary read operations to check if the file is the
kind I’m trying to monitor (and at the end I have to set the file position
again to zero using a set information IRP).
For these reads, I cook my own IRPs. I’ve seen several examples of such
practice and read many messages in this list regarding the topic, so I hope
I’m doing things properly. I do the following:
IoAllocateIrp
KeInitializeEvent
IoGetNextIrpStackLocation
IoSetCompletionRoutine
IoCallDriver
KeWaitForSingleEvent
My completion routine does the following:
*irp->UserIosb = irp->IoStatus; // Copy status information to
// the user
KeSetEvent(irp->UserEvent, 0, FALSE); // Signal event
IoFreeIrp(irp); // Free IRP
return STATUS_MORE_PROCESSING_REQUIRED; // Tell the I/O manager to stop
And I think I initialize properly all fields in the read IRP. Anyway, at the
end of the message I attach the code that initializes the fields, just in
case I’m forgetting something.
All this seems to work PERFECTLY, the reads are performed, the special files
are detected, and so on… then the user program that opened the file reads
whatever he wants to read, and closes the file (actually, what I use to
access the file is the ATTRIB command, just to see its attributes).
And then, I don’t known exactly *when* (might be when the user code closes
the file, or when the user process terminates, or might be just some time
afterwards when the system does some internal updates), the system blows
with a page fault. Since I have installed the checked NT version, I know the
page fault occurs in the CcFlushBuffers system routine, but not much more. A
field in some structure seems to be NULL when it should contain something.
I’m pretty sure the guilty are the IRP read operations, because if I don’t
perform the last set information IRP to set the file pointer back to zero,
the thing blows away too.
As said before, ANY suggestions or help will be greatly appreciated. Also
any new examples of code rolling and passing its own read IRPs will be
greatly appreciated.
Here is the code for the initializtion of the read IRP I’m creating and
passing down to the underlying driver.
irp->UserBuffer = buffer;
irp->UserEvent = &event;
irp->UserIosb = &ioStatus;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = fileObject;
irp->RequestorMode = KernelMode;
irp->Flags = IRP_READ_OPERATION;
irpSp = IoGetNextIrpStackLocation(irp);
irpSp->MajorFunction = IRP_MJ_READ;
irpSp->MinorFunction = 0;
irpSp->DeviceObject = hookedDevice;
irpSp->FileObject = fileObject;
irpSp->Parameters.Read.Length = length;
irpSp->Parameters.Read.Key = 0;
irpSp->Parameters.Read.ByteOffset = *offset;
Regards. Nacho.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com