Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

User/Kernel mode communications using events

David_J._CraigDavid_J._Craig Member Posts: 1,885
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.

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    "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
  • David_J._CraigDavid_J._Craig Member Posts: 1,885
    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
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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" <xxxxx@oneysoft.com> 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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" <xxxxx@oneysoft.com> 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)
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > 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 :-) the IRP completion
    replaces the event signaling.

    Max
  • David_J._CraigDavid_J._Craig Member Posts: 1,885
    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 :-) the IRP completion
    > replaces the event signaling.
    >
    > Max
    >
    >
    >
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space