From: Matt Arnold [marnold@motu.com]
Sent: Friday, September 17, 1999 11:31 AM
To: ntdev@atria.com
Subject: Re: [ntdev] calling user mode dlls from kernel mode drivers

From: Maxim S. Shatskih <maxim@storagecraft.com>
Date: Friday, September 17, 1999 1:31 AM


>> does anybody know how to call a USER MODE APPLICATION OR A
>> USER MODE DLL from a kernel mode driver.
>
>You can call the usermode callback directly from the kmode driver & will
end
>up in EIP < 0x80000000 but the CPU is still in kernel mode.

...provided of course that the kernel-mode driver is still running in the
context of the target user-mode process.  Otherwise, the virtual address of
the callback function will be invalid.  That is, you can't just call the
user-mode callback "at random" from some DPC or, heaven forbid, your
interrupt callback routine!  (I'm sure you konw all this Maxim -- I just
wanted to clarify your comments for the original poster.)

>Looks like it is not a good product architecture, but maybe it is the
>solution in
>your case.

BTW, OSR has an "NT Insider" article that descibes, somewhat in passing,
how a kernel-mode driver can call a user-mode function directly.  The
article is titled "Understanding and Using Execution Context in NT Drivers"
and is freely available at http://www.osr.com/insider/1996/context.htm.

However, may I suggest that perhaps the original poster hasn't been made
familiar with the *proper* methods for communicating between kernel-mode
drivers and user-mode applications (calling user-mode code directly is NOT
a proper method).

For example, one common, *proper* technique is for the application to send
an IOCTL that isn't completed until the driver has something to say to the
application, upon which the driver fills the output buffer and completes
the IRP for the IOCTL.  The app then "wakes up" (that is, when the
DeviceIoControl() call the sent the IOCTL finally returns), it can process
the "callback" information returned in the output buffer, after which it
sends the same IOCTL to the driver again (to receive the next callback).
The app typically would use a separate, dedicated thread for all this.
This technique is known as the "blocking IOCTL" technique.


Regards,

Matt Arnold
marnold@motu.com
Professional Music Products
Mark of the Unicorn, Inc.
http://www.motu.com


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ To unsubscribe, send email to ntdev-request@atria.com with body
UNSUBSCRIBE (the subject is ignored). ]