Hi all

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

Re: DDK calls from application by Oliver

Oliver
Wed Dec 27 22:08:28 CST 2006

Ehrm, you noticed the difference between kernel mode and user mode, did
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.


Re: DDK calls from application by soviet_bloke

soviet_bloke
Wed Dec 27 22:36:34 CST 2006

> I'm just wondering if I can make any ddk function calls from the
> 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

Peter wrote:
> Hi all
>
> 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


Re: DDK calls from application by Maxim

Maxim
Thu Dec 28 05:10:32 CST 2006

You cannot. Syscalls are the only way to call from app to the kernel.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Peter" <faithfulpeter@gmail.com> wrote in message
news:1167271380.300261.183050@79g2000cws.googlegroups.com...
> Hi all
>
> 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
>


Re: DDK calls from application by Ali

Ali
Thu Dec 28 07:08:17 CST 2006


Peter wrote:
> Hi all
>
> 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


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


Re: DDK calls from application by Don

Don
Thu Dec 28 07:26:35 CST 2006

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.


--
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" <abdulrazaq@gmail.com> wrote in message
news:1167311297.829640.215340@42g2000cwt.googlegroups.com...
>
> Peter wrote:
>> Hi all
>>
>> 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
>
>
> 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
>



Re: DDK calls from application by Ali

Ali
Thu Dec 28 07:36:10 CST 2006


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.
>
>
> --
> 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" <abdulrazaq@gmail.com> wrote in message
> news:1167311297.829640.215340@42g2000cwt.googlegroups.com...
> >
> > Peter wrote:
> >> Hi all
> >>
> >> 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
> >
> >
> > 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
> >

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


Re: DDK calls from application by Don

Don
Thu Dec 28 07:43:22 CST 2006


"Ali" <abdulrazaq@gmail.com> wrote in message
news:1167312970.780734.88480@n51g2000cwc.googlegroups.com...
>
> 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.
>>
>> >
>> > 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
>> >
>
> 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.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply





Re: DDK calls from application by Ali

Ali
Thu Dec 28 07:55:53 CST 2006


Don Burn wrote:
> "Ali" <abdulrazaq@gmail.com> wrote in message
> news:1167312970.780734.88480@n51g2000cwc.googlegroups.com...
> >
> > 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.
> >>
> >> >
> >> > 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
> >> >
> >
> > 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.
>
>
> --
> 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?


ali


Re: DDK calls from application by Don

Don
Thu Dec 28 08:16:06 CST 2006


"Ali" <abdulrazaq@gmail.com> wrote in message
news:1167314153.495680.305080@a3g2000cwd.googlegroups.com...
>> 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!!!!).


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




Re: DDK calls from application by Ali

Ali
Thu Dec 28 08:28:44 CST 2006


Don Burn wrote:
> "Ali" <abdulrazaq@gmail.com> wrote in message
> news:1167314153.495680.305080@a3g2000cwd.googlegroups.com...
> >> 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!!!!).
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply



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


Re: DDK calls from application by soviet_bloke

soviet_bloke
Thu Dec 28 16:46:53 CST 2006

> >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).


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


Ali wrote:
> Don Burn wrote:
> > "Ali" <abdulrazaq@gmail.com> wrote in message
> > news:1167314153.495680.305080@a3g2000cwd.googlegroups.com...
> > >> 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!!!!).
> >
> >
> > --
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > http://www.windrvr.com
> > Remove StopSpam from the email to reply
>
>
>
> 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


Re: DDK calls from application by Peter

Peter
Wed Jan 03 02:31:36 CST 2007

Hi

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.


Re: DDK calls from application by Ali

Ali
Wed Jan 03 08:11:28 CST 2007


Peter wrote:
> Hi
>
> 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.

I would go for first option as i feel its making more sense to me, and
complete control of activities.


ali


Re: DDK calls from application by Don

Don
Wed Jan 03 09:08:02 CST 2007

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? 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" <faithfulpeter@gmail.com> wrote in message
news:1167813096.309943.313740@48g2000cwx.googlegroups.com...
> Hi
>
> 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.
>



Re: DDK calls from application by Ali

Ali
Wed Jan 03 09:19:08 CST 2007


Don Burn wrote:
> 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? 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" <faithfulpeter@gmail.com> wrote in message
> news:1167813096.309943.313740@48g2000cwx.googlegroups.com...
> > Hi
> >
> > 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.
> >



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


Re: DDK calls from application by Don

Don
Wed Jan 03 09:36:39 CST 2007


"Ali" <abdulrazaq@gmail.com> wrote in message
news:1167837548.392709.262680@a3g2000cwd.googlegroups.com...
>
>>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.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




Re: DDK calls from application by Peter

Peter
Wed Jan 03 13:46:01 CST 2007

Thank you all. Your responses really are helping me.

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


Re: DDK calls from application by Maxim

Maxim
Wed Jan 03 16:57:31 CST 2007

> Thank you all for the suggestions. The reason I want to do
> PsCreateThreadNotifyRoutine is to suspend/resume a thread or a process

SuspendThread is for you.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


Re: DDK calls from application by Maxim

Maxim
Wed Jan 03 17:00:28 CST 2007

> 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.

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.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


Re: DDK calls from application by Peter

Peter
Wed Jan 03 19:53:02 CST 2007


> 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.
>
Why can I not suspend the thread if the IRQL is at PASSIVE_LEVEL?

Peter