Right, never said it wasn’t possible, said it should be recommended against.
I am adamantly opposed to anything that is not documented, for which there
are no *good* samples, which are not straight forward and that have an
alternative that is/has all these things. I have had NUMEROUS customers
call up with problems using named events incorrectly, especially lately for
whatever reasons. Its easy to get wrong, and once wrong it may not show up
at runtime for months. I actually had a customer that didn’t see a problem
for weeks at a stretch, and out of the blue the driver would crash. It was
a timing issue between the app going away, and the driver signalling the
event. That says to me, avoid the danger.
My personal $0.02.
–
Bill McKenzie
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>
> > ----------
> > From: xxxxx@bsquare.com[SMTP:xxxxx@bsquare.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Friday, May 03, 2002 8:51 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Security Attributes on a Notification Event
> > creat ed at Kernel level
> >
> > There are a lot of problems with named events and they should be avoided
> > if
> > at all possible. A big problem is named events created in the driver in
> > the
> > context of a process will become invalid when that process exits as all
> > handles to the event will be gone. This will completely screw the case
> > you
> > described with potential multiple unknown clients. If you create the
> > event
> > in the context of a system process, then this problem goes away but
> > another
> > arises:
> >
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q228785
> >
> In the case I meant a driver wants to notify user mode apps about some
> event. All what such a client needs is to wait for the event and it is
> possible. Sure, it must be created in system process context.
>
> Also, you can set correct security attributes if necessary. Just use
> ZwCreateEvent instead of IoCreateNotificationEvent which is simple wrapper
> around the first one.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
>
>
>
“Bill McKenzie” wrote in message news:xxxxx@ntdev…
>
>at runtime for months. I actually had a customer that didn’t see a problem
> for weeks at a stretch, and out of the blue the driver would crash. It
was
> a timing issue between the app going away, and the driver signalling the
> event. That says to me, avoid the danger.
>
Hmmm. That says to ME… Driver Writer who doesn’t know what they’re DOING.
If the event is going away, I guess that means it wasn’t referenced by the
driver, right? Let me guess, another one of those “I’ll create a handle and
pass it to the driver to use directly” designs, right? Oh, THAT’s certainly
well thought out.
And THAT’s the fundamental problem, I would argue. Somebody who doesn’t
understand that you can’t access a shared structure that could potentially
go away (via a handle or otherwise) when you’re not holding a reference to
that structure.
I understand that’s easy for me to say, of course, having done this for lo
these many years. But still…
Peter
OSR
Well, the event is created in the driver with IoCreateNotificationEvent in
the context of a user-mode process. I don’t see the DDK docs clarifying
that this event needs to be referenced beyond this or it will cease to exist
when the user-mode process does. But it does.
But, I do see this in the DDK under IoCreateNotificationEvent:
The preferred method to share event objects between user mode and kernel
mode is for the user-mode program to create the event object and pass it to
the driver through an IOCTL.
I don’t know how someone who hasn’t followed this or some other newsgroup
would know to avoid this problem. I honestly still don’t get WHY this works
this way, rather I take it on faith that it does. It makes no sense to me,
but I am probably missing something obvious here??
So, either it should be documented better, or the above preferred method
should stand. That was my only point. As the above preferred method works
and is much easier to get right, that is the way I would go.
–
Bill McKenzie
“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> “Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> >
> >at runtime for months. I actually had a customer that didn’t see a
problem
> > for weeks at a stretch, and out of the blue the driver would crash. It
> was
> > a timing issue between the app going away, and the driver signalling the
> > event. That says to me, avoid the danger.
> >
>
> Hmmm. That says to ME… Driver Writer who doesn’t know what they’re
DOING.
> If the event is going away, I guess that means it wasn’t referenced by the
> driver, right? Let me guess, another one of those “I’ll create a handle
and
> pass it to the driver to use directly” designs, right? Oh, THAT’s
certainly
> well thought out.
>
> And THAT’s the fundamental problem, I would argue. Somebody who doesn’t
> understand that you can’t access a shared structure that could potentially
> go away (via a handle or otherwise) when you’re not holding a reference to
> that structure.
>
> I understand that’s easy for me to say, of course, having done this for lo
> these many years. But still…
>
> Peter
> OSR
>
>
>
>
>