[Alex]

I've just found one chapter of "Undocumented Windows..." - or something like that... - book. At the 33 page there is a description of something which is called "Quick LPC" - did you heard about this/used it to communicate KM-UM?

Anyway, sticking with APC is ok Alex :mrgreen:

I know, but I'd like to know something more about methods I didn't use earlier.

[t4L]

According to Wikipedia:

Quick LPC was introduced in version 3.51 of Windows NT to make these calls faster. This method was largely abandoned in version 4.0 in favor of moving the performance critical server portions into kernel mode (win32k.sys).

[Tigzy]

Hello

I need to do nearly the same. My driver is quite simple, for the moment I'm just trying to send data from UL to KM (done with IRP buffer) and from KM to UL.
Any code snippet for the use of LPC communication?

[Alex]

Here is a good description of LPC with sources - LPC Communication. You can simply move code of client thread from user mode to your driver (Nt* -> Zw*)...

[Tigzy]

Thanks

Is it a really better method than shared buffer?
What are the major differences?

[Tigzy]

I've tested the code, it works well...... in userland.

When trying to adapt the code for kernelmode, it becomes tricky.
All the APIs NtXxxxPort are undefined. How can I import them?

PS : the ntdll.h provided works only under userland app

[EP_X0FF]

ntoskrn.exe exports only client LPC routines afair - NtConnectPort, NtRequestWaitReplyPort, something else don't remember. If they exists in lib but not present in headers - declare them yourself.
Why you should use this method to do such trivial task? There are exists more simple ways like shared memory, pipes.

[Tigzy]

There are exists more simple ways like shared memory, pipes.

You're right, I'm always using shared memory, but I guessed a synchronized thing like LPC would be cleaner.
For the moment, I use a polling thread in my user app checking if there's a new "message", and my driver is constantly writing over this shared memory.

Maybe my code needs some improvements (such as message queue and mutexs -don't know if mutex can fly over from UL to KM-) , but I was convainced it was more a temporary solution than the right way to do...
Maybe I'm wrong. So was my previous question:

Is it a really better method than shared buffer?
What are the major differences?

EDIT:

For the import function, the problem is solved.
I took all the missing defs from the ntdll.h and copy/paste into my .h
Now I'll try to make it work :)

[0xC0000022L]

How about hanging IRPs? It's a pretty universal method. What you do is to send "down" some IRPs to the device, and the driver marks them as pending and returns them whenever data becomes available. Quick, easy and universal across the mentioned OS versions.

[Tigzy]

Yep, I use IRPs, that's a good stuff for communication where all comes from userland.
In my case, the problem is all comes from a hook proxy function. So there's no Irps...

BTW, is anybody got an idea about how to put my proxy function in a wait state, the time my UL process checks whether it should return SUCCESS or not?
And how resume it from UL? (with IRPs I guess) . that's for CreateSection hook