User/Kernel mode communications using events

I have been thinking about the idea of event sharing between an app and a
driver. There is a nice example on the OSRonline site. Assuming either a
named event created by the user app or just passing the handle of a user app
created event to the driver, how can the driver know that the event is no
longer valid, when the app may crash? I was thinking about using an IRP
that is held by the driver with a cancel routine set. If the app crashes,
the IoManager should try and cancel that IRP so the driver can invalidate
the event handle.

I think this would have two advantages: 1) no invalid use of an event
handle 2) the driver will know when the app has gone, both scheduled and
unscheduled.

“David J. Craig” wrote:

I have been thinking about the idea of event sharing between an app and a
driver. There is a nice example on the OSRonline site. Assuming either a
named event created by the user app or just passing the handle of a user app
created event to the driver, how can the driver know that the event is no
longer valid, when the app may crash? I was thinking about using an IRP
that is held by the driver with a cancel routine set. If the app crashes,
the IoManager should try and cancel that IRP so the driver can invalidate
the event handle.

I thought I had pretty well covered this ground on pp. 495-505 on my WDM
book…


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

I got stuck on page 464 and haven’t made it that far yet. I think it is
pages 497-505. It still doesn’t mention how to determine if there is
someone present to listen to your event setting. You can keep bug checks
from happening by using the correct functions, but when the app goes away,
the event will have to remain valid until the driver dereferences it. I
think that if someone feels they must use an event, using a pending IoCtl to
get the call during cancel processing is a good way to know you have to
clean up the event stuff.

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> “David J. Craig” wrote:
> > I have been thinking about the idea of event sharing between an app and
a
> > driver. There is a nice example on the OSRonline site. Assuming either
a
> > named event created by the user app or just passing the handle of a user
app
> > created event to the driver, how can the driver know that the event is
no
> > longer valid, when the app may crash? I was thinking about using an IRP
> > that is held by the driver with a cancel routine set. If the app
crashes,
> > the IoManager should try and cancel that IRP so the driver can
invalidate
> > the event handle.
>
> I thought I had pretty well covered this ground on pp. 495-505 on my WDM
> book…
>
> –
> Walter Oney, Consulting and Training
> Basic and Advanced Driver Programming Seminars
> Check out our schedule at http://www.oneysoft.com
>
>

I was under the impression that the event would not become invalid until all
references to it where closed. That, I think, includes the reference held by
the driver. Isn’t that right?

David J. Craig wrote:

I got stuck on page 464 and haven’t made it that far yet. I think it is
pages 497-505. It still doesn’t mention how to determine if there is
someone present to listen to your event setting. You can keep bug checks
from happening by using the correct functions, but when the app goes away,
the event will have to remain valid until the driver dereferences it. I
think that if someone feels they must use an event, using a pending IoCtl to
get the call during cancel processing is a good way to know you have to
clean up the event stuff.

“Walter Oney” wrote in message news:xxxxx@ntdev…
>
>>“David J. Craig” wrote:
>>
>>>I have been thinking about the idea of event sharing between an app and
>
> a
>
>>>driver. There is a nice example on the OSRonline site. Assuming either
>
> a
>
>>>named event created by the user app or just passing the handle of a user
>
> app
>
>>>created event to the driver, how can the driver know that the event is
>
> no
>
>>>longer valid, when the app may crash? I was thinking about using an IRP
>>>that is held by the driver with a cancel routine set. If the app
>
> crashes,
>
>>>the IoManager should try and cancel that IRP so the driver can
>
> invalidate
>
>>>the event handle.
>>
>>I thought I had pretty well covered this ground on pp. 495-505 on my WDM
>>book…
>>
>>–
>>Walter Oney, Consulting and Training
>>Basic and Advanced Driver Programming Seminars
>>Check out our schedule at http://www.oneysoft.com
>>
>>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stg.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Burkhard Daniel
Software Technologies Group, Inc.
xxxxx@stg.com * http://www.stg.com
fon: +49-179-5319489 fax: +49-179-335319489

That is true; a user-mode or kernel-mode handle is simply an opaque
reference to a single kernel-mode entity with a reference-counted header
maintained by the Object Manager.

Burkhard Daniel wrote:

I was under the impression that the event would not become invalid until
all references to it where closed. That, I think, includes the reference
held by the driver. Isn’t that right?

David J. Craig wrote:

> I got stuck on page 464 and haven’t made it that far yet. I think it is
> pages 497-505. It still doesn’t mention how to determine if there is
> someone present to listen to your event setting. You can keep bug checks
> from happening by using the correct functions, but when the app goes
> away,
> the event will have to remain valid until the driver dereferences it. I
> think that if someone feels they must use an event, using a pending
> IoCtl to
> get the call during cancel processing is a good way to know you have to
> clean up the event stuff.
>
> “Walter Oney” wrote in message
>> news:xxxxx@ntdev…
>>
>>> “David J. Craig” wrote:
>>>
>>>> I have been thinking about the idea of event sharing between an app and
>>
>>
>> a
>>
>>>> driver. There is a nice example on the OSRonline site. Assuming
>>>> either
>>
>>
>> a
>>
>>>> named event created by the user app or just passing the handle of a
>>>> user
>>
>>
>> app
>>
>>>> created event to the driver, how can the driver know that the event is
>>
>>
>> no
>>
>>>> longer valid, when the app may crash? I was thinking about using an
>>>> IRP
>>>> that is held by the driver with a cancel routine set. If the app
>>
>>
>> crashes,
>>
>>>> the IoManager should try and cancel that IRP so the driver can
>>
>>
>> invalidate
>>
>>>> the event handle.
>>>
>>>
>>> I thought I had pretty well covered this ground on pp. 495-505 on my WDM
>>> book…
>>>
>>> –
>>> Walter Oney, Consulting and Training
>>> Basic and Advanced Driver Programming Seminars
>>> Check out our schedule at http://www.oneysoft.com
>>>
>>>
>>
>>
>>
>>
>> —
>> You are currently subscribed to ntdev as: xxxxx@stg.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


- Nick Ryan (MVP for DDK)

> named event created by the user app or just passing the handle of a
user app

created event to the driver, how can the driver know that the event
is no
longer valid, when the app may crash?

Named events are un-recommended by MS due to namespace issues on
Remote Desktop.
Passing a handle is OK, if the driver will call
ObReferenceObjectByHandle - this adds an extra reference, which will
be pending even if the app will crash. Later, the driver will release
this reference.

I was thinking about using an IRP
that is held by the driver with a cancel routine set. If the app
crashes,
the IoManager should try and cancel that IRP so the driver can
invalidate
the event handle.

In this case, you do not need any event :slight_smile: the IRP completion
replaces the event signaling.

Max

Sometimes you have to use an event for reasons I won’t defend, but will live
with. I do need to know if the app has gone away though. That is why I
have suggested using the IoCtl only for app termination/exiting detection so
it remains pended from the time the app starts until it is done. There is
one advantage to this logic in that the event will always be available to be
signaled, even if already signaled, while an IRP that has been completed is
not available until the next request. Might have to make sure that the app
will see that multiple signals were done so it can get all the
data/information it needs.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>
> > named event created by the user app or just passing the handle of a
> user app
> > created event to the driver, how can the driver know that the event
> is no
> > longer valid, when the app may crash?
>
> Named events are un-recommended by MS due to namespace issues on
> Remote Desktop.
> Passing a handle is OK, if the driver will call
> ObReferenceObjectByHandle - this adds an extra reference, which will
> be pending even if the app will crash. Later, the driver will release
> this reference.
>
> >I was thinking about using an IRP
> > that is held by the driver with a cancel routine set. If the app
> crashes,
> > the IoManager should try and cancel that IRP so the driver can
> invalidate
> > the event handle.
>
> In this case, you do not need any event :slight_smile: the IRP completion
> replaces the event signaling.
>
> Max
>
>
>
>