Currently, I’ve created a filter that uses the pre-operation callbacks for IRP_MJ_CREATE and then uses the SendMessage/RecieveMessage to get information from a user-mode application.
The problem that is happening is that in the user application, there is an fopen called after the FilterGetMessage and before the FilterReplyMessage (a flat file needs to be read to send a code back to the filter). Is there anyway to prevent the deadlock that occurs?
Perhaps, if in the IPR_MJ_CREATE path, you didnt bother you user mode, when
the flatfeil is the file, it woukd help?
wrote in message news:xxxxx@ntfsd…
> Currently, I’ve created a filter that uses the pre-operation callbacks for
> IRP_MJ_CREATE and then uses the SendMessage/RecieveMessage to get
> information from a user-mode application.
>
> The problem that is happening is that in the user application, there is an
> fopen called after the FilterGetMessage and before the FilterReplyMessage
> (a flat file needs to be read to send a code back to the filter). Is there
> anyway to prevent the deadlock that occurs?
>
If you can ignore IO from your user User Mode program the following can
help:
When your user process connects to the MiniFilter record the process IDs.
NTSTATUS cbPortConnect(IN PFLT_PORT _ClientPort,
IN PVOID _ServerPortCookie,
IN PVOID _ConnectionContext,
IN ULONG _SizeOfContext,
OUT PVOID *_ConnectionCookie) {
…
s_FilterData.m_UserProcess = PsGetCurrentProcess();
…
}
In your minifilter ignore IO from your user process.
FLT_PREOP_CALLBACK_STATUS cbPreCreate(IN OUT PFLT_CALLBACK_DATA _Data,
IN PCFLT_RELATED_OBJECTS _FltObjects,
OUT PVOID *_CompletionContext) {
FLT_PREOP_CALLBACK_STATUS Status = FLT_PREOP_SUCCESS_NO_CALLBACK;
if (IoThreadToProcess( _Data->Thread ) != s_FilterData.m_UserProcess)) {
…
}
return(Status);
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Thursday, October 12, 2006 12:40 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] opening a file and deadlock
Currently, I’ve created a filter that uses the pre-operation callbacks for
IRP_MJ_CREATE and then uses the SendMessage/RecieveMessage to get
information from a user-mode application.
The problem that is happening is that in the user application, there is an
fopen called after the FilterGetMessage and before the FilterReplyMessage (a
flat file needs to be read to send a code back to the filter). Is there
anyway to prevent the deadlock that occurs?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@rts-services.com
To unsubscribe send a blank email to xxxxx@lists.osr.com