"Invalid file handle." message on deleting files in explorer.

NTFSD
1

Hello,

I am developing minifilter driver that pends IO operations and then sends
operation info to .NET service using FltSendMessage. By that info service
decides if the operation should be processed further or aborted and sends
answer to driver. Driver then calls FltCompletePendedPreOperation to process
or abort operation. Everything works fine except of deletion files in
Windows Explorer (both to Recycle Bin and permanent). For some reason I
receive “Invalid file handle.” message in it. Files are deleted without
problems from Command line and Total Commander.
At first the message appeared on every file deletion. But I found suggestion
on some forum to use KeStackAttachProcess. I changed my code as showcased
below and started to receive this messages on rare occasions on bulk file
deletion (for example for 5 files from 200).
deleteOperation = (Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION) &&
(pData->Iopb->Parameters.SetFileInformation.FileInformationClass ==
FileDispositionInformation) &&
(((PFILE_DISPOSITION_INFORMATION)pData->Iopb->Parameters.SetFileInformation.InfoBuffer)->DeleteFile);

…

if (deleteOperation) {
pProcess = FltGetRequestorProcess(pCallbackData);
ObReferenceObject(pProcess);
KeStackAttachProcess(pProcess, &state);
}
FltCompletePendedPreOperation(pCallbackData, callbackStatus,
pOperationContext);
if (deleteOperation) {
KeUnstackDetachProcess(&state);
ObDereferenceObject(pProcess);
}
I also read somewhere that same problem was encountered in Windows Home
Server Beta.
Please, help me to understand what’s happening: why I getting this message?
why only in explorer? why attaching to issuer process helps? why it helps
not in all cases?

2

Hi.

I bet your problem will disappear if you switch your filter design from “PreOp-Pend” to “block PreOp-Thread with a synchronous FltSendMessage call”

3

Thanks for reply.
In fact first version of driver was using this design and there were no such
problem. But I decided to move to the async logic trying to raise
performance. Also performance became better but in cases of some
applications (IE for example) it remains bad.

4

I’m pretty sure you problem is that you’re using a handle in an invalid
process context. Please take a look at the IRP_MJ_SET_INFORMATION page
(currently at http://msdn.microsoft.com/en-us/library/ff549366(v=vs.85).aspx
http: ). There
is a member IrpSp->Parameters.SetFile.DeleteHandle, which is not documented.
I’m not sure what the deal is with that handle but I expect it’s a user
process handle and your pending and resuming in a different process context
makes that problematic.

Could you please try something ?

Instead of resuming the operation in a different process context by calling
FltCompletePendedPreOperation() with STATUS_SUCCESS_Xxx_CALLBACK, could you
please try to call FltSetInformationFile on the FILE_OBJECT yourself with
the same disposition and when FltSetInformationFIle returns you complete the
original request with FltCompletePendedPreOperation() and FLT_PREOP_COMPLETE
(you need to also set the status returned from FltSetInformationFile in the
FLT_CALLBACK_DATA) ?

Thanks,

Alex.</http:>

5

>async logic trying to raise performance

At least some FS requests are always synchronized by the IO manager and so pending them is useless and maybe bug-prone.

IoIsOperationSynchronous() will check for these cases.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Thanks for all your answers. I solved problem by making driver not to pend
delete operations. It seems like performance even became higher.

7

Good to hear that and thanks for posting your findings.

In general if a request is synchronous then pending it will not only not
increase but even likely decrease performance (it depends on implementation
but it’ll likely happen).

Thanks,

Alex.