DDK calls from application
Peter
I'm just wondering if I can make any ddk function calls from the
application space. If so, how do I find out which ones are permissible
or which ones are not allowed. The functions I'm looking at are
PsSetCreateThreadNotifyRoutine and related functions. Please advice.
Thanks
Oliver
you?
There are *some* functions which are available in pairs in both user
mode and kernel mode - usually referred to as the "Native API", but
this is limited to those functions prefixed Nt or Zw (of which only a
minority is documented anyways).
Don't be misled by the statement "Callers of
PsSetCreateThreadNotifyRoutine must be running at IRQL = PASSIVE_LEVEL"
and the fact that user mode code runs at PASSIVE_LEVEL as well ;)
Oliver
PS: If you want to be notified upon thread creation, let your driver
communicate with your app, e.g. via inverted calls.
soviet...@hotmail.com
> application space.
You can not - as simple as that. The only things you can call are Zw..
routines, but even these entry points are different from their
counterparts that are called by drivers - drivers call the ones that
are exported by ntoskrnl.exe, and apps call their counterparts from
ntdll.dll....
Anton Bassov
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Peter" <faithf...@gmail.com> wrote in message
news:1167271380.3...@79g2000cws.googlegroups.com...
Ali
I think you can write a wrapper (diver) for interested functions to use
them with IOCTLs. For example IOCTL_WRITE_PORT_UCHAR can pass the
necessary arguments to PsSetCreateThreadNotifyRoutine and finally
IOCTL_READ_PORT_UCHAR
Would be reading the return status.
ali
Don Burn
argument at a time is a very bad idea, since it requires a bunch of logic
in the driver to track the caller and the function. If the OP needs to
recieve thread notifications, write a simple driver that issues the call
and then returns the parameters of the callback in an inverted call.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
"Ali" <abdul...@gmail.com> wrote in message
news:1167311297.8...@42g2000cwt.googlegroups.com...
Ali
snip:
>write a simple driver that issues the call and then returns the parameters of the callback in an inverted call.
Well it might be or it is simple for you to code inverted call
mechanism but that is in fact pretty much complex stuff. It was just an
another solution with very straight forward implementation.
ali
Don Burn
>
> Don Burn wrote:
>> Why are you recomending IOCTL's from a specific driver? Also, passing
>> one
>> argument at a time is a very bad idea, since it requires a bunch of
>> logic
>> in the driver to track the caller and the function. If the OP needs to
>> recieve thread notifications, write a simple driver that issues the call
>> and then returns the parameters of the callback in an inverted call.
>>
>> >
>> > use
>> > them with IOCTLs. For example IOCTL_WRITE_PORT_UCHAR can pass the
>> > necessary arguments to PsSetCreateThreadNotifyRoutine and finally
>> > IOCTL_READ_PORT_UCHAR
>> > Would be reading the return status.
>> >
>> > ali
>> >
>
> snip:
>>write a simple driver that issues the call and then returns the
>>parameters of the callback in an inverted call.
>
>
> Well it might be or it is simple for you to code inverted call
> mechanism but that is in fact pretty much complex stuff. It was just an
> another solution with very straight forward implementation.
>
So having code to track creates and file objects (since multiple app's
could call your driver), and tracking that all the bytes of the parameters
have been passed (I sure don't know what parameters the app is supposed to
pass for the kernel mode callback function) is easier than taking some
boilerplate code from an example an using it? You didn't address at all
how the user is supposed to get back the results from the asynchronous
callbacks. Sorry, but this suggestion is not simple.
Ali
Ok! i understand. Yeah, in multiple apps case there will be a problem
BUT how about if there will be the only one to manipulate? Do you still
think that inverted call is worth coding than proposed solution?
ali
Don Burn
>> So having code to track creates and file objects (since multiple app's
>> could call your driver), and tracking that all the bytes of the
>> parameters
>> have been passed (I sure don't know what parameters the app is supposed
>> to
>> pass for the kernel mode callback function) is easier than taking some
>> boilerplate code from an example an using it? You didn't address at all
>> how the user is supposed to get back the results from the asynchronous
>> callbacks. Sorry, but this suggestion is not simple.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>
> Ok! i understand. Yeah, in multiple apps case there will be a problem
> BUT how about if there will be the only one to manipulate? Do you still
> think that inverted call is worth coding than proposed solution?
Well if you don't do an inverted call, you have to have another way to
support the asynchronous notifications, you could use an event but then you
don't get the arguments, have to worry about multiple callbacks and queuing
them or otherwise handling them and the exiting of processes etc.
In this case I know that the inverted call is the simplest, since I have
supported the Ps callbacks for customers in simple drivers, including an
idiot who insisted on events (the invent based version was four times the
size of the inverted call!!!!).
Ali
snip:
>Well if you don't do an inverted call, you have to have another way to
>support the asynchronous notifications, you could use an event but then you
>don't get the arguments,
Or just keep polling the certian piece of code
(IOCTL_READ_xxx/file/registry key).
ali
soviet...@hotmail.com
> >support the asynchronous notifications, you could use an event but then you
> >don't get the arguments,
>
>
> Or just keep polling the certian piece of code
> (IOCTL_READ_xxx/file/registry key).
Sorry, but making an app poll driver is really a no-brain
solution......
Concerning events, using them *MAY* be justified is some rare cases.
For example, let's say your driver's actions depend on app's response,
and driver has to process things synchronously, i.e. it cannot return
STATUS_PENDING and proceed with the request at some later point (for
instance, it has to ask user permission within a callback that either
allows or disallows some action). In such case you *MAY* consider using
events. However, even in this scenario, there is no guarantee that
using events is always better than making an the inverse call - again,
everything depends on the particular situation.
Concerning the OP's situation, the whole thing should *DEFINITELY* be
handled as an inverse call - any other solution is just unreasonable in
this situation.....
Anton Bassov
Peter
Thank you all for the suggestions. The reason I want to do
PsCreateThreadNotifyRoutine is to suspend/resume a thread or a process
(I'm trying to find an API to suspend all the threads in a process, or
I'll have to enumerate all the threads in the process) It seems that
the only way I can do it now is in the user space. Is there any way I
can do it in the kernel space?
Also, with inverted calls, I read the article and glance at the code.
http://www.osronline.com/article.cfm?id=94
It seems that I need to have the service make an initial IOCTL call to
the driver. From here on, there seems to be two ways to handle this
issue
#1 is for the driver to just block the IOCTL call and find a way to put
the calling thread to sleep. Once the data is available (in this case
its when the call back function register by
PsCreateThreadNotifyRoutine is invoked to place data in a queue and
wake up the sleeping thread), I can return IOCTL call in addition to
return the data store in the queue. In this case, I need to write a
service to ensure that only thread can make IOCTL call to the driver to
fetch the data and the driver must verify that only that one service
can calls the driver. This would eliminated the need to have a link
list to handle the app that stores multiple thread calls. The service
would handle the multiple app calls.
#2 is by returning IO_Pending in the initial IOCTL call. Store the
initial calling IRP somewhere. The calling service thread would than go
to sleep. Once the call back to PsCreateThreadNotifyRoutine is invoked.
I can complete the first IOCTL and to wake it up the service thread to
come and fetch data stored in a queue in the driver.
Which of this two ways work better.
Ali
I would go for first option as i feel its making more sense to me, and
complete control of activities.
ali
Don Burn
a. If a second thread create occurs while you are in the application, what
are you going to do with it? If you use pending you can create a number of
requests and release them as needed. Note: depending on how critical
things are you may still need additional work to handle no more buffer
cases.
b. If the application calls the driver expecting overlapped I/O which is
native to the OS, it will be unpleasantly surprised by having its thread
pended.
For pending look at the IoCsq functions (and the cancel example in the DDK)
these funtions were not available when the inverted call article was
written and make the world easier.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
"Peter" <faithf...@gmail.com> wrote in message
news:1167813096.3...@48g2000cwx.googlegroups.com...
Ali
Snip:
>Go with option #2. There are a number of problems with #1:
>a. If a second thread create occurs while you are in the application, what
>are you going to do with it?
But its all gonna be in user mode. I mean the application will reside
in user space for waiting on certain event, so; is it really difficult
to write a multithreaded client interface?
ali
Don Burn
>
>>Go with option #2. There are a number of problems with #1:
>>a. If a second thread create occurs while you are in the application,
>>what
>>are you going to do with it?
>
> But its all gonna be in user mode. I mean the application will reside
> in user space for waiting on certain event, so; is it really difficult
> to write a multithreaded client interface?
>
What happens if there are 20 thread creates before the application has a
chance to do the first one? If you have a single IOCTL, then you have to
try to make that code as fast as you can, then issue a second system call
to invoke a pool of threads to handle the event. Even then you are going
to have to be really sure that the driver handles the multiple thread
creates to be reported well, this can get especially complicated since most
applications of this do not want the thread to be running (and possibly
terminating) before the event has been reported.
Now with multiple IOCTL's pended, the interface can be each IOCTL reports a
thread event. The user space code can have a pool of threads (use
completion ports if desired) to handle the responses. Also the driver is
simpler since the return of a specific IOCTL can indicate that thread can
proceed. In this model the system is doing a lot of the work for you, in
the other model you are creating a lot of infastructure the OS could have
done with a different reportng model.
Peter
I do have questions in regarding to thread pause/resume and process
pause/resume
Currently. I can't see any way of pause/resume threads in the kernel
mode. These are ones in the user mode. Are there such APIs such as
pause or resume thread in the kernel mode?
As for the process. It seems that no such API exists any where. It look
like I have to use Thread32 related API in the user space to enumerate
the thread. If such API exists, that would help save time.
I would prefer doing these operations in the kernel mode if possible.
Peter
Maxim S. Shatskih
> PsCreateThreadNotifyRoutine is to suspend/resume a thread or a process
SuspendThread is for you.
Maxim S. Shatskih
> like I have to use Thread32 related API in the user space to enumerate
> the thread.
Correct. You cannot suspend a process. Process does not run, thread does.
So, enumerate all threads within a process.
Also note that suspend is done when the thread returns from kernel to user. You
cannot suspend the thread while it is executing kernel mode code.
Peter
> Also note that suspend is done when the thread returns from kernel to user. You
> cannot suspend the thread while it is executing kernel mode code.
>
Peter