PsSetCreateProcessNotifyRoutine callback context

NTDEV
1

Upon each process creation I want to stall the process whilst I do some
background work.

My current method is to register for process notify callback and on
receiving these, I schedule a DPC to do my work and stall the thread in the
context of the callback. I then release the thread when my work is complete
and the process is created.

Is this the preferred method?
If so, is the callback for PsSetCreateProcessNotifyRoutine always called in
the context of the thread which is creating the process?

Thanks.

2

From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm

“The driver’s process-creation notify routine runs at IRQL PASSIVE_LEVEL, either in the context of the initial thread within a newly created process or in the context of a system thread.”

3

Wow, I have no idea how I missed that. Thanks.
It’s interesting, MSDN has a slightly different take on this (I assume the
OSR docs are slightly outdated)

" When a process is created, the process-notify routine runs in the context
of the thread that created the new process. When a process is deleted, the
process-notify routine runs in the context of the last thread to exit from
the process"

Is it enough/correct to stall the calling thread?
Obviously this isn’t stalling the process itself, but it’s stalling the
return to CreateProcessInternalW which completes the call and creates the
first thread.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 19 May 2010 12:16
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm

“The driver’s process-creation notify routine runs at IRQL PASSIVE_LEVEL,
either in the context of the initial thread within a newly created process
or in the context of a system thread.”

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Yes you are stalling the completion of the CreateProcess by I cannot
understand your design. You block this function and schedule a DPC to
do something and when completed you continue with this function? Why
are you adding the overhead of the DPC? You do realize also you are
blocking any other CreateProcess or TerminateProcess on the system,
since there is lock on the list of routines to call?

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 8:51 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

Wow, I have no idea how I missed that. Thanks.
It’s interesting, MSDN has a slightly different take on this (I assume
the OSR
docs are slightly outdated)

" When a process is created, the process-notify routine runs in the
context of
the thread that created the new process. When a process is deleted,
the
process-notify routine runs in the context of the last thread to exit
from the
process"

Is it enough/correct to stall the calling thread?
Obviously this isn’t stalling the process itself, but it’s stalling
the return
to CreateProcessInternalW which completes the call and creates the
first
thread.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 19 May 2010 12:16
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm

“The driver’s process-creation notify routine runs at IRQL
PASSIVE_LEVEL,
either in the context of the initial thread within a newly created
process or
in the context of a system thread.”

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

5

My original understanding was wrong, hence so was my design.
I also didn’t realise there was a lock.
Whilst this in itself isn’t a problem, it’s not ideal from a speed
perspective.

I can see two improved designs:

The first is to pass the PID from the notification back into usermode. Here
I can get a handle to the process, loop the threads and stall them all, then
resume when the additional work is complete. (or call NtSuspendProcess,
although that’s undocumented…)

The second is to forget PsSetCreateProcessNotifyRoutine and instead use
PsSetCreateThreadNotifyRoutine.
When I get notification of the first thread being created in a process, I
can call ZwSuspendThread on that thread and release it when the additional
work is complete.

Any comments are greatly appreciated.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 13:57
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Yes you are stalling the completion of the CreateProcess by I cannot
understand your design. You block this function and schedule a DPC to
do something and when completed you continue with this function? Why
are you adding the overhead of the DPC? You do realize also you are
blocking any other CreateProcess or TerminateProcess on the system,
since there is lock on the list of routines to call?

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 8:51 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

Wow, I have no idea how I missed that. Thanks.
It’s interesting, MSDN has a slightly different take on this (I assume
the OSR
docs are slightly outdated)

" When a process is created, the process-notify routine runs in the
context of
the thread that created the new process. When a process is deleted,
the
process-notify routine runs in the context of the last thread to exit
from the
process"

Is it enough/correct to stall the calling thread?
Obviously this isn’t stalling the process itself, but it’s stalling
the return
to CreateProcessInternalW which completes the call and creates the
first
thread.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 19 May 2010 12:16
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm

“The driver’s process-creation notify routine runs at IRQL
PASSIVE_LEVEL,
either in the context of the initial thread within a newly created
process or
in the context of a system thread.”

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

Be aware that PsSetCreateProcessNotifyRoutine is called before the
process is valid so it is possible to get the PID before the process can
be opened. PsSetCreateThreadNotifyRoutine also has a lock on the list,
so you have that problem with this approach.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 9:42 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

My original understanding was wrong, hence so was my design.
I also didn’t realise there was a lock.
Whilst this in itself isn’t a problem, it’s not ideal from a speed
perspective.

I can see two improved designs:

The first is to pass the PID from the notification back into usermode.
Here I
can get a handle to the process, loop the threads and stall them all,
then
resume when the additional work is complete. (or call
NtSuspendProcess,
although that’s undocumented…)

The second is to forget PsSetCreateProcessNotifyRoutine and instead
use
PsSetCreateThreadNotifyRoutine.
When I get notification of the first thread being created in a
process, I can
call ZwSuspendThread on that thread and release it when the additional
work is
complete.

Any comments are greatly appreciated.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 13:57
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Yes you are stalling the completion of the CreateProcess by I cannot
understand your design. You block this function and schedule a DPC to
do
something and when completed you continue with this function? Why are
you
adding the overhead of the DPC? You do realize also you are blocking
any
other CreateProcess or TerminateProcess on the system, since there is
lock on
the list of routines to call?

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

> -----Original Message-----
> From: Ged [mailto:xxxxx@googlemail.com]
> Posted At: Wednesday, May 19, 2010 8:51 AM Posted To: ntdev
> Conversation: PsSetCreateProcessNotifyRoutine callback context
> Subject: RE: PsSetCreateProcessNotifyRoutine callback context
>
> Wow, I have no idea how I missed that. Thanks.
> It’s interesting, MSDN has a slightly different take on this (I
assume
the OSR
> docs are slightly outdated)
>
> " When a process is created, the process-notify routine runs in the
context of
> the thread that created the new process. When a process is deleted,
the
> process-notify routine runs in the context of the last thread to
exit
from the
> process"
>
>
> Is it enough/correct to stall the calling thread?
> Obviously this isn’t stalling the process itself, but it’s stalling
the return
> to CreateProcessInternalW which completes the call and creates the
first
> thread.
>
> Thanks.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
> Sent: 19 May 2010 12:16
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context
>
> From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm
>
> “The driver’s process-creation notify routine runs at IRQL
PASSIVE_LEVEL,
> either in the context of the initial thread within a newly created
process or
> in the context of a system thread.”
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 5128 (20100519) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

7

With regards to the thread approach, I’d be suspending the actual thread not
the calling thread.
I assumed this would bypass the lock you mentioned as I wouldn’t be holding
up the creation of more threads?
Or is the lock you mention held via the newly created thread?

If so, do you have any suggestions on a design that would work?
Should I be forgetting to do this in the kernel and maybe use detours to
hook CreateProcessInternalW and do my work after I call the real function?

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 14:53
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Be aware that PsSetCreateProcessNotifyRoutine is called before the
process is valid so it is possible to get the PID before the process can
be opened. PsSetCreateThreadNotifyRoutine also has a lock on the list,
so you have that problem with this approach.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 9:42 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

My original understanding was wrong, hence so was my design.
I also didn’t realise there was a lock.
Whilst this in itself isn’t a problem, it’s not ideal from a speed
perspective.

I can see two improved designs:

The first is to pass the PID from the notification back into usermode.
Here I
can get a handle to the process, loop the threads and stall them all,
then
resume when the additional work is complete. (or call
NtSuspendProcess,
although that’s undocumented…)

The second is to forget PsSetCreateProcessNotifyRoutine and instead
use
PsSetCreateThreadNotifyRoutine.
When I get notification of the first thread being created in a
process, I can
call ZwSuspendThread on that thread and release it when the additional
work is
complete.

Any comments are greatly appreciated.

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 13:57
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Yes you are stalling the completion of the CreateProcess by I cannot
understand your design. You block this function and schedule a DPC to
do
something and when completed you continue with this function? Why are
you
adding the overhead of the DPC? You do realize also you are blocking
any
other CreateProcess or TerminateProcess on the system, since there is
lock on
the list of routines to call?

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

> -----Original Message-----
> From: Ged [mailto:xxxxx@googlemail.com]
> Posted At: Wednesday, May 19, 2010 8:51 AM Posted To: ntdev
> Conversation: PsSetCreateProcessNotifyRoutine callback context
> Subject: RE: PsSetCreateProcessNotifyRoutine callback context
>
> Wow, I have no idea how I missed that. Thanks.
> It’s interesting, MSDN has a slightly different take on this (I
assume
the OSR
> docs are slightly outdated)
>
> " When a process is created, the process-notify routine runs in the
context of
> the thread that created the new process. When a process is deleted,
the
> process-notify routine runs in the context of the last thread to
exit
from the
> process"
>
>
> Is it enough/correct to stall the calling thread?
> Obviously this isn’t stalling the process itself, but it’s stalling
the return
> to CreateProcessInternalW which completes the call and creates the
first
> thread.
>
> Thanks.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
> Sent: 19 May 2010 12:16
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context
>
> From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm
>
> “The driver’s process-creation notify routine runs at IRQL
PASSIVE_LEVEL,
> either in the context of the initial thread within a newly created
process or
> in the context of a system thread.”
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 5128 (20100519) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

The call to the callback functions for the PsCreateXXXNotifyRoutine have
locks around the list of functions to call. So in the case of
PsSetCreateThreadNotifyRoutine the newly created thread takes the lock,
then calls each callback function in turn. While the lock is held the
processing of any addition thread create or termination is going to get
blocked.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 10:01 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

With regards to the thread approach, I’d be suspending the actual
thread not
the calling thread.
I assumed this would bypass the lock you mentioned as I wouldn’t be
holding up
the creation of more threads?
Or is the lock you mention held via the newly created thread?

If so, do you have any suggestions on a design that would work?
Should I be forgetting to do this in the kernel and maybe use detours
to hook
CreateProcessInternalW and do my work after I call the real function?

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 14:53
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Be aware that PsSetCreateProcessNotifyRoutine is called before the
process is
valid so it is possible to get the PID before the process can be
opened.
PsSetCreateThreadNotifyRoutine also has a lock on the list, so you
have that
problem with this approach.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

> -----Original Message-----
> From: Ged [mailto:xxxxx@googlemail.com]
> Posted At: Wednesday, May 19, 2010 9:42 AM Posted To: ntdev
> Conversation: PsSetCreateProcessNotifyRoutine callback context
> Subject: RE: PsSetCreateProcessNotifyRoutine callback context
>
> My original understanding was wrong, hence so was my design.
> I also didn’t realise there was a lock.
> Whilst this in itself isn’t a problem, it’s not ideal from a speed
> perspective.
>
> I can see two improved designs:
>
> The first is to pass the PID from the notification back into
usermode.
Here I
> can get a handle to the process, loop the threads and stall them
all,
then
> resume when the additional work is complete. (or call
NtSuspendProcess,
> although that’s undocumented…)
>
> The second is to forget PsSetCreateProcessNotifyRoutine and instead
use
> PsSetCreateThreadNotifyRoutine.
> When I get notification of the first thread being created in a
process, I can
> call ZwSuspendThread on that thread and release it when the
additional
work is
> complete.
>
> Any comments are greatly appreciated.
>
> Thanks.
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: 19 May 2010 13:57
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context
>
> Yes you are stalling the completion of the CreateProcess by I cannot
> understand your design. You block this function and schedule a DPC
to
do
> something and when completed you continue with this function? Why
are
you
> adding the overhead of the DPC? You do realize also you are
blocking
any
> other CreateProcess or TerminateProcess on the system, since there
is
lock on
> the list of routines to call?
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> > -----Original Message-----
> > From: Ged [mailto:xxxxx@googlemail.com]
> > Posted At: Wednesday, May 19, 2010 8:51 AM Posted To: ntdev
> > Conversation: PsSetCreateProcessNotifyRoutine callback context
> > Subject: RE: PsSetCreateProcessNotifyRoutine callback context
> >
> > Wow, I have no idea how I missed that. Thanks.
> > It’s interesting, MSDN has a slightly different take on this (I
assume
> the OSR
> > docs are slightly outdated)
> >
> > " When a process is created, the process-notify routine runs in
the
> context of
> > the thread that created the new process. When a process is
deleted,
> the
> > process-notify routine runs in the context of the last thread to
exit
> from the
> > process"
> >
> >
> > Is it enough/correct to stall the calling thread?
> > Obviously this isn’t stalling the process itself, but it’s
stalling
> the return
> > to CreateProcessInternalW which completes the call and creates the
> first
> > thread.
> >
> > Thanks.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> > Sent: 19 May 2010 12:16
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback
context
> >
> > From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm
> >
> > “The driver’s process-creation notify routine runs at IRQL
> PASSIVE_LEVEL,
> > either in the context of the initial thread within a newly created
> process or
> > in the context of a system thread.”
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> >
> > __________ Information from ESET Smart Security, version of virus
> signature
> > database 5128 (20100519) __________
> >
> > The message was checked by ESET Smart Security.
> >
> > http://www.eset.com
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 5128 (20100519) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

9

I’m a bit lost as to the best way to best to this then.
Does anyone have any ideas?

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 15:03
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

The call to the callback functions for the PsCreateXXXNotifyRoutine have
locks around the list of functions to call. So in the case of
PsSetCreateThreadNotifyRoutine the newly created thread takes the lock,
then calls each callback function in turn. While the lock is held the
processing of any addition thread create or termination is going to get
blocked.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Ged [mailto:xxxxx@googlemail.com]
Posted At: Wednesday, May 19, 2010 10:01 AM
Posted To: ntdev
Conversation: PsSetCreateProcessNotifyRoutine callback context
Subject: RE: PsSetCreateProcessNotifyRoutine callback context

With regards to the thread approach, I’d be suspending the actual
thread not
the calling thread.
I assumed this would bypass the lock you mentioned as I wouldn’t be
holding up
the creation of more threads?
Or is the lock you mention held via the newly created thread?

If so, do you have any suggestions on a design that would work?
Should I be forgetting to do this in the kernel and maybe use detours
to hook
CreateProcessInternalW and do my work after I call the real function?

Thanks.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: 19 May 2010 14:53
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context

Be aware that PsSetCreateProcessNotifyRoutine is called before the
process is
valid so it is possible to get the PID before the process can be
opened.
PsSetCreateThreadNotifyRoutine also has a lock on the list, so you
have that
problem with this approach.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

> -----Original Message-----
> From: Ged [mailto:xxxxx@googlemail.com]
> Posted At: Wednesday, May 19, 2010 9:42 AM Posted To: ntdev
> Conversation: PsSetCreateProcessNotifyRoutine callback context
> Subject: RE: PsSetCreateProcessNotifyRoutine callback context
>
> My original understanding was wrong, hence so was my design.
> I also didn’t realise there was a lock.
> Whilst this in itself isn’t a problem, it’s not ideal from a speed
> perspective.
>
> I can see two improved designs:
>
> The first is to pass the PID from the notification back into
usermode.
Here I
> can get a handle to the process, loop the threads and stall them
all,
then
> resume when the additional work is complete. (or call
NtSuspendProcess,
> although that’s undocumented…)
>
> The second is to forget PsSetCreateProcessNotifyRoutine and instead
use
> PsSetCreateThreadNotifyRoutine.
> When I get notification of the first thread being created in a
process, I can
> call ZwSuspendThread on that thread and release it when the
additional
work is
> complete.
>
> Any comments are greatly appreciated.
>
> Thanks.
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: 19 May 2010 13:57
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback context
>
> Yes you are stalling the completion of the CreateProcess by I cannot
> understand your design. You block this function and schedule a DPC
to
do
> something and when completed you continue with this function? Why
are
you
> adding the overhead of the DPC? You do realize also you are
blocking
any
> other CreateProcess or TerminateProcess on the system, since there
is
lock on
> the list of routines to call?
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> > -----Original Message-----
> > From: Ged [mailto:xxxxx@googlemail.com]
> > Posted At: Wednesday, May 19, 2010 8:51 AM Posted To: ntdev
> > Conversation: PsSetCreateProcessNotifyRoutine callback context
> > Subject: RE: PsSetCreateProcessNotifyRoutine callback context
> >
> > Wow, I have no idea how I missed that. Thanks.
> > It’s interesting, MSDN has a slightly different take on this (I
assume
> the OSR
> > docs are slightly outdated)
> >
> > " When a process is created, the process-notify routine runs in
the
> context of
> > the thread that created the new process. When a process is
deleted,
> the
> > process-notify routine runs in the context of the last thread to
exit
> from the
> > process"
> >
> >
> > Is it enough/correct to stall the calling thread?
> > Obviously this isn’t stalling the process itself, but it’s
stalling
> the return
> > to CreateProcessInternalW which completes the call and creates the
> first
> > thread.
> >
> > Thanks.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> > Sent: 19 May 2010 12:16
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] PsSetCreateProcessNotifyRoutine callback
context
> >
> > From: http://www.osronline.com/ddkx/kmarch/k108_5lwy.htm
> >
> > “The driver’s process-creation notify routine runs at IRQL
> PASSIVE_LEVEL,
> > either in the context of the initial thread within a newly created
> process or
> > in the context of a system thread.”
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> >
> > __________ Information from ESET Smart Security, version of virus
> signature
> > database 5128 (20100519) __________
> >
> > The message was checked by ESET Smart Security.
> >
> > http://www.eset.com
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature
> database 5128 (20100519) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

__________ Information from ESET Smart Security, version of virus
signature
database 5128 (20100519) __________

The message was checked by ESET Smart Security.

http://www.eset.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer