Best practice of Device Driver to User Mode Application Notifcation,...

Discussion in 'Windows Vista Drivers' started by Kerem Gümrükcü, Sep 2, 2008.

  1. Hi,

    maybe this is a common question, but what is the best
    practice of notifying a User Mode Application that
    holds a Handle to the Driver by CreateFile? By notifying
    i mean if a certain event occurs inside the driver i want
    to pass a piece of memory to my user mode application
    that holds a CreateFile Handle and was communicating
    only the direction of DeviceIOControl and "synchronously"?
    There is no "request" for anything from the UserMode
    application. The Driver should inform the User Mode
    Application. What is best practice for that. It is a
    Software-Only Driver e.g. it has no physical device
    attached. Should i work with some kind of shared
    memory and events wait-handles? Any recommendation,...?

    Regards

    Kerem
     
    Kerem Gümrükcü, Sep 2, 2008
    #1
    1. Advertisements

  2. Kerem Gümrükcü

    David Craig Guest

    Define the problem. The answer varies. OSR has a paper on how to handle
    the various possibilities. IoCtls and events are the two I use. The last
    choice is shared memory and should only be used under very rare
    circumstances. The event sample in the WDK shows how to do events but these
    are also very seldom required. I had a case where they were appropriate and
    the correct method to use for bidirectional signalling but there was no data
    required to be passed in either direction, but just a signal. Both also
    have issues that have to be handled with cancelling and app termination so
    you will have to use at least one IoCtl to handle app termination.
     
    David Craig, Sep 2, 2008
    #2
    1. Advertisements

  3. RegisterDeviceNotification for the file handle,

    IoReportTargetDeviceChange/TARGET_DEVICE_CUSTOM_NOTIFICATION
     
    Alexander Grigoriev, Sep 2, 2008
    #3
  4. the inverted call model is the easiest. the app sends an IOCtl to your
    driver, you pend it and and complete it when the event occurs. this solves
    2 problems for you. first, it notifies the app that something happend.
    second, the ioctl can contain an output buffer that you can write to so that
    when the app is notified of the event occurring, it has the corresponding
    data immediately w/out having to send an other ioctl to the dirver or for a
    complicated scheme where you are sharing memory between the 2

    d
     
    Doron Holan [MSFT], Sep 2, 2008
    #4
  5. Kerem Gümrükcü

    Pavel A. Guest

    And if the app dies, the ioctl will be canceled automatically
    and your (?) driver will receive cancel request on the
    ioctl, and then cleanup.

    Nevertheless... that a usermode app can hold a driver and prevent
    deletion of surprise-removed device, etc. is annoying.
    Fortunately, there are many 3rd party "close handle"
    hacks to work around this.
    ( can MS include this ability in "Windows 7", please? )

    --PA
     
    Pavel A., Sep 2, 2008
    #5
  6. The usermode app should use RegisterDeviceNotification, to release the
    handle of removed device. And in any case, a properly written driver doesn't
    suffer from hanging handles. The secret is to delete symboolic links and
    device interfaces on surprise removal.
     
    Alexander Grigoriev, Sep 3, 2008
    #6
  7. this is not new to a pnp device. an app can hold a legacy NT4 driver in
    memory by keeping a handle open after the driver has been unloaded

    d
     
    Doron Holan [MSFT], Sep 3, 2008
    #7
  8. Kerem Gümrükcü

    Pavel A. Guest

    The usermode app should use RegisterDeviceNotification

    This "should" often is not realistic.
    The app may be written in a scripting language that simply
    has no support for receiving Windows notification.
    Or you know... it can be a quick and dirty app written just to test something.

    There should be some officially supported way to close pending handles,
    because users actually need it, the "find and kill" utilites exist and seem
    to work.

    (Conceptually this is like how the windows manager (?) hides not responding
    app window and substitutes it to something surrogate. So the app continues to
    hang or do whatever it does, but it's window can be moved away.)
    Maybe this is even already implemented...
    how chkdsk can forcibly unmout a disk with open files on it?

    Regards,
    --PA
     
    Pavel A., Sep 3, 2008
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.