If I have to use FltSendMessage with a null timeout in order to wait on a user response (acknowledges a prompt for example), how can I break that wait if the application crashes? According to a post from a few years back, FltSendMessage only breaks if the thread in whose context it is executing in terminates but it does not break if the thread that is communicating with crashes. So this leads to a driver being stuck waiting for a response that will never come. I thought about pending the pre or post operation, having a separate thread perform the FltSendMessage function and if the driver is notified that the user mode completion thread dies that I could forcefully kill the kernel thread. But that’s not a very elegant way plus I’m not even sure it would work.
For a different project (non-FltXXX) I made a kernel to user waiting system where the driver created events and assigned them unique ids and the user mode would send a IOCTL with the id of the event it wanted to trigger. And because the driver kept the list of all events it could easily break waits as needed but for this I’d prefer to use the FltXXX functions. So how can I wait indefinitely but still have the resiliency to recover from a user mode crash? It’d be nice if FltSendMessage had an extra parameter just for this sort of outside breakage.
When you send a request to a user mode service, you have to supply a
port in the FltSendMessage() call. This port handle is retrieved when
the service connects to the driver. Thus if you call FltSendMessage()
and the user mode process which opened the port dies, the
FltSendMessage() API will return with a failure code since the port
handle will be closed when the process goes away. If I recall the error
returned is STATUS_PORT_DISCONNECTED.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295
------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 12/15/2015 4:18:02 PM
Subject: [ntfsd] FltSendMessage break
>If I have to use FltSendMessage with a null timeout in order to wait on
>a user response (acknowledges a prompt for example), how can I break
>that wait if the application crashes? According to a post from a few
>years back, FltSendMessage only breaks if the thread in whose context
>it is executing in terminates but it does not break if the thread that
>is communicating with crashes. So this leads to a driver being stuck
>waiting for a response that will never come. I thought about pending
>the pre or post operation, having a separate thread perform the
>FltSendMessage function and if the driver is notified that the user
>mode completion thread dies that I could forcefully kill the kernel
>thread. But that’s not a very elegant way plus I’m not even sure it
>would work.
>
>For a different project (non-FltXXX) I made a kernel to user waiting
>system where the driver created events and assigned them unique ids and
>the user mode would send a IOCTL with the id of the event it wanted to
>trigger. And because the driver kept the list of all events it could
>easily break waits as needed but for this I’d prefer to use the FltXXX
>functions. So how can I wait indefinitely but still have the
>resiliency to recover from a user mode crash? It’d be nice if
>FltSendMessage had an extra parameter just for this sort of outside
>breakage.
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
Well, if the application crashed, the handle the application has to the
communication channel would close and you’ll get a notification that the
port got disconnected. I’m not actually sure if this will automatically
return from FltSendMessage() but if it doesn’t you could do a
KeWaitForMultipleObjects() and have an event that gets signaled when the
communication port closes.
Thanks,
Alex
On Tue, Dec 15, 2015 at 3:18 PM, wrote:
> If I have to use FltSendMessage with a null timeout in order to wait on a
> user response (acknowledges a prompt for example), how can I break that
> wait if the application crashes? According to a post from a few years
> back, FltSendMessage only breaks if the thread in whose context it is
> executing in terminates but it does not break if the thread that is
> communicating with crashes. So this leads to a driver being stuck waiting
> for a response that will never come. I thought about pending the pre or
> post operation, having a separate thread perform the FltSendMessage
> function and if the driver is notified that the user mode completion thread
> dies that I could forcefully kill the kernel thread. But that’s not a very
> elegant way plus I’m not even sure it would work.
>
> For a different project (non-FltXXX) I made a kernel to user waiting
> system where the driver created events and assigned them unique ids and the
> user mode would send a IOCTL with the id of the event it wanted to
> trigger. And because the driver kept the list of all events it could
> easily break waits as needed but for this I’d prefer to use the FltXXX
> functions. So how can I wait indefinitely but still have the resiliency to
> recover from a user mode crash? It’d be nice if FltSendMessage had an
> extra parameter just for this sort of outside breakage.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Well in my testing (i.e. when my user mode app crashed) it never did return
so it just got stuck. But the issue with an event, Alex, is that if
FltSendMessage doesn’t return then any processing the event triggers
doesn’t matter or am I missing something? So that’s why I thought
forcefully terminating the thread would be the only option other than not
using FltSendMessage.
On Tue, Dec 15, 2015 at 6:44 PM, Alex Carp
wrote:
> Well, if the application crashed, the handle the application has to the
> communication channel would close and you’ll get a notification that the
> port got disconnected. I’m not actually sure if this will automatically
> return from FltSendMessage() but if it doesn’t you could do a
> KeWaitForMultipleObjects() and have an event that gets signaled when the
> communication port closes.
>
> Thanks,
> Alex
>
> On Tue, Dec 15, 2015 at 3:18 PM, wrote:
>
>> If I have to use FltSendMessage with a null timeout in order to wait on a
>> user response (acknowledges a prompt for example), how can I break that
>> wait if the application crashes? According to a post from a few years
>> back, FltSendMessage only breaks if the thread in whose context it is
>> executing in terminates but it does not break if the thread that is
>> communicating with crashes. So this leads to a driver being stuck waiting
>> for a response that will never come. I thought about pending the pre or
>> post operation, having a separate thread perform the FltSendMessage
>> function and if the driver is notified that the user mode completion thread
>> dies that I could forcefully kill the kernel thread. But that’s not a very
>> elegant way plus I’m not even sure it would work.
>>
>> For a different project (non-FltXXX) I made a kernel to user waiting
>> system where the driver created events and assigned them unique ids and the
>> user mode would send a IOCTL with the id of the event it wanted to
>> trigger. And because the driver kept the list of all events it could
>> easily break waits as needed but for this I’d prefer to use the FltXXX
>> functions. So how can I wait indefinitely but still have the resiliency to
>> recover from a user mode crash? It’d be nice if FltSendMessage had an
>> extra parameter just for this sort of outside breakage.
>>
>> —
>> NTFSD is sponsored by OSR
>>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
>
> — NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis,
> WDF, Windows internals and software drivers! Details at To unsubscribe,
> visit the List Server section of OSR Online at</http:>