hi,
I have a simple question :
Can we call a kernel driver function directly from the user mode App in NT
4.0/2K? or DeviceIOControl() function of IOCTL is the only way?
Is the other way round possible, means, can kernel driver call user mode
function directly?
I am assuming that in either case, the function entry points will be exposed
by either side.
thanks a lot,
Rajinder
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
From: “rajinder sharma”
Sent: Wednesday, August 16, 2000 6:01 PM
> hi,
> I have a simple question :
>
> Can we call a kernel driver function directly from the user mode App in NT
> 4.0/2K?
No.
> or DeviceIOControl() function of IOCTL is the only way?
That’s right.
>
> Is the other way round possible, means, can kernel driver call user mode
> function directly?
It is “possible” (see the excellent OSR NT Insider article “Understanding
and Using Execution Context in NT Drivers”,
http://www.osr.com/ntinsider/1996/context/context.htm), but is highly
dangerous and prone to breakage in some future version of the operating
system. Calling user-mode code directly also can only be done under just
the right circumstances and is by no means a general-purpose technique of
notifying application-level code. It is not actually “supported” by the
OS – it just happens to work in the current implementation.
Anywya, the most common (and supported) techinque for notifying user-mode
code from a kernel-mode driver is to use “a blocking IOCTL” (more on this
below). An alternate, but less common techninque, is to share an event
object between kernel-mode and user-mode. In either case, it is always the
user-mode code that purposely waits for something to happen – a driver
doesn’t “call” user-mode code directly and unannounced.
The “blocking IOCTL” method involves creating a dedicated user-mode thread
which sends an IOCTL to the driver, for which the driver initially returns
STATUS_PENDING. The thread then waits for the IOCTL to be completed (the
thread is then “blocked”, which is why it must be a thread dedicated to this
task). When the driver wishes to “tell” the user-mode about some
interesting event, it simply ompletes the IOCTL, waking up the thread. The
thread can then examine the information returned with the IOCTL to find out
which event has occurred. If multiple such events are needed, the thread
simply issues and waits for the IOCTL again.
>
> I am assuming that in either case, the function entry points will be
exposed
> by either side.
You are assuming wrong. Designing around the assumption that it is possible
to make direct calls in either direction is simply a flawed approach.
WDM/NT drivers are not designed this way. Use blocking IOCTLs or some other
proper technique that is supported by the operating system.
- Matt