Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

0 views
Skip to first unread message

Kerem Gümrükcü

unread,
Sep 1, 2008, 10:38:30 PM9/1/08
to
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


--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."


David Craig

unread,
Sep 2, 2008, 12:28:00 AM9/2/08
to
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.


"Kerem Gümrükcü" <kare...@hotmail.com> wrote in message
news:uehwNdKD...@TK2MSFTNGP06.phx.gbl...

Alexander Grigoriev

unread,
Sep 2, 2008, 9:54:06 AM9/2/08
to
RegisterDeviceNotification for the file handle,

IoReportTargetDeviceChange/TARGET_DEVICE_CUSTOM_NOTIFICATION

"Kerem Gümrükcü" <kare...@hotmail.com> wrote in message
news:uehwNdKD...@TK2MSFTNGP06.phx.gbl...

Doron Holan [MSFT]

unread,
Sep 2, 2008, 3:41:43 PM9/2/08
to
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

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Kerem Gümrükcü" <kare...@hotmail.com> wrote in message
news:uehwNdKD...@TK2MSFTNGP06.phx.gbl...

Pavel A.

unread,
Sep 2, 2008, 6:18:07 PM9/2/08
to
Doron Holan [MSFT] wrote:
> 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

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

Alexander Grigoriev

unread,
Sep 2, 2008, 10:26:36 PM9/2/08
to

"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:uMVEOoUD...@TK2MSFTNGP02.phx.gbl...

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.


Doron Holan [MSFT]

unread,
Sep 2, 2008, 11:13:19 PM9/2/08
to
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

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Pavel A." <pav...@NOfastmailNO.fm> wrote in message
news:uMVEOoUD...@TK2MSFTNGP02.phx.gbl...

Pavel A.

unread,
Sep 3, 2008, 11:38:02 AM9/3/08
to
>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

0 new messages