Hello guys! Well there is a similar thread actually, but it’s too old and I have to start the similar one. My driver uses FltSendMessage to exchange the messages of the same size with user mode. Most of the time it works fine. But on occasion FltSendMessage hangs the system - it seems like it doesn’t receive a reply from user mode at all sometimes. Did anyone met the same problem? If so, how did you solve it?..
Thank you
There is a timeout parameter to FltSendMessage (if all else fails…).
Could you please post a bit more information about this specific hang ?
Which OS version, how are you sure that you sent the message back and so
on… Also it might be useful to post a link to the thread you are referring
to if you think it’s similar enough to what you’re seeing…
Thanks,
Alex.
What is the application doing? Unless you specify a timeout the application
can cause this to happen.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, September 13, 2011 3:37 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltSendMessage hangs the system
Hello guys! Well there is a similar thread actually, but it’s too old and I
have to start the similar one. My driver uses FltSendMessage to exchange the
messages of the same size with user mode. Most of the time it works fine.
But on occasion FltSendMessage hangs the system - it seems like it doesn’t
receive a reply from user mode at all sometimes. Did anyone met the same
problem? If so, how did you solve it?..
Thank you
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Well, here is some code
WorkerThread(
__in void\* ContextV )
{
...
message = NULL;
BOOL bResult = GetQueuedCompletionStatus(Context-\>Completion, &outSize, &key, &pOvlp, INFINITE );
if (!bResult)
{
__asm int 3; // should break into debugger
break;
}
message = CONTAINING_RECORD( pOvlp, MINFILTER_MESSAGE, Ovlp );
if (!Context-\>FilteringThread(message))
{
__asm int 3;
break;
}
memset( &message-\>Ovlp, 0, sizeof( OVERLAPPED ) );
hr = FilterGetMessage(Context-\>Port,
(PFILTER_MESSAGE_HEADER)message,
FIELD_OFFSET( MINFILTER_MESSAGE, Ovlp ),
&message-\>Ovlp );
}
and Filtering thread
bool FilteringThread(MINFILTER_MESSAGE\* message)
{
MINFILTER_NOTIFICATION\* notification;
MINFILTER_REPLY_MESSAGE replyMessage;
notification = &message-\>Notification;
replyMessage.ReplyHeader.Status = 0;
replyMessage.ReplyHeader.MessageId = message-\>MessageHeader.MessageId;
.....
HRESULT hr = FilterReplyMessage( Port,
(PFILTER_REPLY_HEADER) &replyMessage,
sizeof( FILTER_REPLY_HEADER ) + sizeof(MINFILTER_REPLY ));
}
As you may see, the message is always replied…
The os is WinXP x32, but I don’t think it has much sence in this case…
And most of the time it works… It hangs on occasion, and yes, I’ve already tried specifing timeout in the driver (60 seconds, for sure) and yes, once the process is hung, timeout expires and function in the driver terminates with STATUS_TIMEOUT. But it should had received a reply…
I suspect that there is something missing in the code you supplied which
is causing the problem. I use this sort of interface all the time and
when there is a hang due to non-responsiveness from a request sent from
kernel mode it is always because the user mode service is not correctly
handling the response.
Have you stepped through the code in a debugger, ensuring that the
thread is not exiting without you knowing about it? Thus the next
request goes unhandled?
Pete
On 9/13/2011 2:03 PM, xxxxx@gmail.com wrote:
Well, here is some code
WorkerThread( __in void\* ContextV ) { ... message = NULL; BOOL bResult = GetQueuedCompletionStatus(Context-\>Completion,&outSize,&key,&pOvlp, INFINITE ); if (!bResult) { __asm int 3; // should break into debugger break; } message = CONTAINING_RECORD( pOvlp, MINFILTER_MESSAGE, Ovlp ); if (!Context-\>FilteringThread(message)) { __asm int 3; break; } memset(&message-\>Ovlp, 0, sizeof( OVERLAPPED ) ); hr = FilterGetMessage(Context-\>Port, (PFILTER_MESSAGE_HEADER)message, FIELD_OFFSET( MINFILTER_MESSAGE, Ovlp ), &message-\>Ovlp ); }and Filtering thread
bool FilteringThread(MINFILTER_MESSAGE\* message) { MINFILTER_NOTIFICATION\* notification; MINFILTER_REPLY_MESSAGE replyMessage; notification =&message-\>Notification; replyMessage.ReplyHeader.Status = 0; replyMessage.ReplyHeader.MessageId = message-\>MessageHeader.MessageId; ..... HRESULT hr = FilterReplyMessage( Port, (PFILTER_REPLY_HEADER)&replyMessage, sizeof( FILTER_REPLY_HEADER ) + sizeof(MINFILTER_REPLY )); }As you may see, the message is always replied…
The os is WinXP x32, but I don’t think it has much sence in this case…
And most of the time it works… It hangs on occasion, and yes, I’ve already tried specifing timeout in the driver (60 seconds, for sure) and yes, once the process is hung, timeout expires and function in the driver terminates with STATUS_TIMEOUT. But it should had received a reply…
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi all,
This is weird. I was about to ask a very similar question to Eugene. Perhaps we are having the same problem so I’ll post here. I am seeing a very small percentage of my calls to FltSendMessage hang forever.
In my code, the minifilter does not specify a timeout (this code is based on the scanner WDK sample):
// Send message to user mode to indicate it should overwrite the file.
// We don’t have to synchronize between the send and close of the handle
// as FltSendMessage takes care of that.
replyLength = sizeof(EETD_REPLY);
status = FltSendMessage(EETDGlobalData.FilterHandle,
&EETDGlobalData.ClientPort,
msgFromFilter,
sizeof(EETD_MESSAGE_FROM_FILTER),
msgFromFilter,
&replyLength,
NULL);
Our user mode component gets the message and *always* calls FilterReplyMessage. Furthermore it seems to be doing so with a valid reply header (I’ve debugged through) but the call to FilterReplyMessage returns ERROR_FLT_NO_WAITER_FOR_REPLY. Clearly, our driver is waiting so that isn’t the problem. The message id *could* be wrong but we are not modifying it in any way.
Eugene, are you seeing a simliar error code in your user mode application?
The rest of the list, do you have any suggestions about troubleshooting this? Our filter communicates frequently with our user mode component. There are definitely cases where tens of messages are exchange per second.
Thanks,
Alnoor
In general, if you are seeing occasional messages hanging, that is some
work and some don’t, then you need to confirm that 1) you are correctly
initializing the reply header in the user mode code, 2) That you are
correctly responding to each request. If you are getting back a
NO_WAITER error code then odds are it is 1) above.
I would pepper the user mode code with trace, ensuring that everything
is initialized correctly, spewing things to WinDbg. Do the same with
your driver and see where the mismatch is coming.
Pete
On 9/19/2011 8:50 AM, xxxxx@entrust.com wrote:
Hi all,
This is weird. I was about to ask a very similar question to Eugene. Perhaps we are having the same problem so I’ll post here. I am seeing a very small percentage of my calls to FltSendMessage hang forever.
In my code, the minifilter does not specify a timeout (this code is based on the scanner WDK sample):
// Send message to user mode to indicate it should overwrite the file.
// We don’t have to synchronize between the send and close of the handle
// as FltSendMessage takes care of that.
replyLength = sizeof(EETD_REPLY);
status = FltSendMessage(EETDGlobalData.FilterHandle,
&EETDGlobalData.ClientPort,
msgFromFilter,
sizeof(EETD_MESSAGE_FROM_FILTER),
msgFromFilter,
&replyLength,
NULL);Our user mode component gets the message and *always* calls FilterReplyMessage. Furthermore it seems to be doing so with a valid reply header (I’ve debugged through) but the call to FilterReplyMessage returns ERROR_FLT_NO_WAITER_FOR_REPLY. Clearly, our driver is waiting so that isn’t the problem. The message id *could* be wrong but we are not modifying it in any way.
Eugene, are you seeing a simliar error code in your user mode application?
The rest of the list, do you have any suggestions about troubleshooting this? Our filter communicates frequently with our user mode component. There are definitely cases where tens of messages are exchange per second.
Thanks,
Alnoor
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi,
I ended up unassembling FltSendMessage and figuring out what msg ID the driver was waiting on. It turns out that the user mode client was losing the message sent by the driver in a very small number of cases, and was replying to the previously sent message twice.
In some cases GetQueuedCompletionStatus returns 998 or 995 and we weren’t handling that correctly. The scanner sample just exits but that doesn’t seem to be the correct behaviour. Still not sure why those errors are happening but at least we can recover.
Thanks Peter.
Alnoor