detecting if a process is suspended or resumed

Hi community, how can i determine if a process is suspended or not? the
following gives me the access right for the process handle, but when the IF
statement is true I want to determine if the process is active and going to
be suspended, or the process is suspended and going to be resumed, relevant
code below is my edits to obcallback msdn wdk example running on windows 10
and build with VS 2019, thanks.

HANDLE pid = PsGetCurrentProcessId();//writer
HANDLE targetpid = PsGetProcessId((PEPROCESS)PreInfo->Object);//target

if ((PreInfo->Parameters->CreateHandleInformation.OriginalDesiredAccess &
PROCESS_SUSPEND_RESUME) == PROCESS_SUSPEND_RESUME)
DbgPrint(“@@@ Proces-suspend-resume-accessattempt, target pid: %d,
writer pid: %d, desired access: PROCESS_SUSPEND_RESUME\r\n”, targetpid,
pid);

thanks, Jose

I’m not sure your question makes sense. processes are not suspended or resumed - threads are. I suppose that if all of the threads of a process where suspended, then the process might be considered to be suspended.

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-suspendthread

From your code, it looks like you are detecting when a given handle has certain privileges. The existence of a certain privilege does not imply in any way when, if or how it might be used

I don’t know the sample you are referring to so can’t provide anything more specific

I’m not sure your question makes sense. processes are not suspended or resumed - threads are.

In the traditional Windows world, that’s true. In the UWP world, it’s not. UWP works like apps on your cell phone (which is partly what it was designed for). A process can be suspended when it goes into the background.

https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/optimize-suspend-resume

if that is what he is asking about, it is very off topic for this forum

In the traditional Windows world, that’s true. In the UWP world, it’s not. UWP works like apps on your cell phone (which
is partly what it was designed for). A process can be suspended when it goes into the background.

Well, I don’t really know what the “traditional Windows world” may even mean in this context, taking into consideration the differences between Win32 concept of a process and the way it is understood by the kernel. For example, Win32 subsystem thinks that a process has its “primary thread”, and that terminating this thread automatically implies process termination. However, from the NT kernel’s perspective all the threads of a process are equal (none of them is more equal than any other one), so that terminating any particular thread does not affect
any other thread of a given process. Therefore, a process is “alive and kicking” as long as it has any threads running.

Furthermore, Win32 thinks of a process creation as of an atomic operation that automatically implies creating its primary thread.
However, from the kernel’s perspective, a newly-created process does not have any threads in it, so that creating a process in Win32 sense is quite a laborious process (no pun intended) that spans across several system calls and involves opening a file,creating an executable section that is backed up by it, then creating a process address space that is backed up by this section, then a thread in a newly-created process, and, finally,informing Win32 subsystem about the new process.

Taking into consideration the specifics of this NG, I think it makes sense to look at the things from the kernel’s perspective and not from the one of the one of this or that API that is built on top of it…

Anton Bassov

That’s all interesting, but your post is totally irrelevant in the context of the original poster’s question.

That’s all interesting, but your post is totally irrelevant in the context of the original poster’s question.

In a way, this is true, but if we recall that the post in question was made in response to your reference to something as irrelevant to the system-level development in general and to the OP’s question in particular as Universal Windows Platform…am I the only one who finds the above statement “funny”, so to say, under these circumstances???

Anton Bassov

I see Anton is back from his holidays.

Or, you know, perhaps he’s quarantined with the Coronavirus and bored…

Peter

see Anton is back from his holidays.

Or, you know, perhaps he’s quarantined with the Coronavirus and bored…

As I can see,“The Hanging Judge”, took my “comeback” seriously, and decided to launch a “preemptive” personal attack right on the spot…

Anton Bassov

Hi, OP here, the code is from the ObCallback sample provided in the WDK.
more relevant code is below. I am trying to determine if the threads of a
process are suspended or not at the time the process handle request comes
in with ‘suspend-resume’ access. When the if statement below is true i
want to determine if the process’s threads are already suspended or not.
This actually creates two questions for me:

  1. does a process need to request anothr process’s handle with
    ‘suspen-resume’ when to suspend and resume the process’s threads? or only
    needs to request for suspend and retains the handle and access right for
    resume.

  2. how can i use the process handle ‘targetpid’ to access the threads and
    check their suspend state?

//
// CBTdPreOperationCallback
//
OB_PREOP_CALLBACK_STATUS
CBTdPreOperationCallback (
In PVOID RegistrationContext,
Inout POB_PRE_OPERATION_INFORMATION PreInfo
)
{ PTD_CALLBACK_REGISTRATION CallbackRegistration;
ACCESS_MASK AccessBitsToClear = 0;
ACCESS_MASK AccessBitsToSet = 0;
ACCESS_MASK InitialDesiredAccess = 0;
ACCESS_MASK OriginalDesiredAccess = 0;
PACCESS_MASK DesiredAccess = NULL;
LPCWSTR ObjectTypeName = NULL;
LPCWSTR OperationName = NULL;

// Not using driver specific values at this time
CallbackRegistration = (PTD_CALLBACK_REGISTRATION)RegistrationContext;

TD_ASSERT (PreInfo->CallContext == NULL);

HANDLE pid = PsGetCurrentProcessId();//writer
HANDLE targetpid = PsGetProcessId((PEPROCESS)PreInfo->Object);//target

if ((PreInfo->Parameters->CreateHandleInformation.OriginalDesiredAccess
& PROCESS_SUSPEND_RESUME) == PROCESS_SUSPEND_RESUME)
DbgPrint(“@@@ Proces-suspend-resume-accessattempt, target pid: %d,
writer pid: %d, desired access: PROCESS_SUSPEND_RESUME\r\n”, targetpid,
pid);

On Sun, Mar 15, 2020 at 5:56 AM anton_bassov
wrote:

> OSR https://community.osr.com/
>
> anton_bassov commented on detecting if a process is suspended or resumed
>
> > see Anton is back from his holidays.
> >
> > Or, you know, perhaps he’s quarantined with the Coronavirus and
> bored…
>
> As I can see,“The Hanging Judge”, took my “comeback” seriously, and
> decided to launch a “preemptive” personal attack right on the spot…
>
> Anton Bassov
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/296466#Comment_296466
>
> Check it out:
> https://community.osr.com/discussion/comment/296466#Comment_296466
>

When the if statement below is true i want to determine if the process’s threads are already suspended or not.

What are you going to do with this info, to begin with? Look- once the process/thread is not the kind of a resource that you may claim an ownership to, the state of the target process may have been changed already by the time you try to make use of this info. Therefore, this info is of no use for anything other than reporting/statistics/etc purposes - you cannot make programming decisions that are based upon it.

If you want to gather the statistical data on the process, it is better to do it in the userland.More on it below

  1. how can i use the process handle ‘targetpid’ to access the threads and check their suspend state?

Another point to consider here is that a “handle” returned by PsGetProcessId() is not really a handle, at least not a way it is understood by the Object Manager. If you need to control a process or gather an info on it, you should open a handle with the corresponding access rights to it (this part should be done by ZwOpenProcesss()), and then query/control the target process by means of the appropriate API.

However, it is better to do this part in the userland using a well-defined and documented API exported by kernel32.dll, rather than
by means of native API, which is largely undocumented and is a subject to change.

Anton Bassov

id like to check at the point of that if statement which is in the kernel,
its for logging purposes, just to know if the process (threads) are already
suspended or not. I will try the zwopenprocess approach, though im not sure
it will get me access to the threads.

On Mon, Mar 16, 2020 at 4:19 AM anton_bassov
wrote:

> OSR https://community.osr.com/
>
> anton_bassov commented on detecting if a process is suspended or resumed
>
> > When the if statement below is true i want to determine if the process’s
> threads are already suspended or not.
>
> What are you going to do with this info, to begin with? Look- once the
> process/thread is not the kind of a resource that you may claim an
> ownership to, the state of the target process may have been changed already
> by the time you try to make use of this info. Therefore, this info is of no
> use for anything other than reporting/statistics/etc purposes - you cannot
> make programming decisions that are based upon it.
>
> If you want to gather the statistical data on the process, it is better to
> do it in the userland.More on it below
>
> > * how can i use the process handle ‘targetpid’ to access the threads and
> check their suspend state?
>
> Another point to consider here is that a “handle” returned by
> PsGetProcessId() is not really a handle, at least not a way it is
> understood by the Object Manager. If you need to control a process or
> gather an info on it, you should open a handle with the corresponding
> access rights to it (this part should be done by ZwOpenProcesss()), and
> then query/control the target process by means of the appropriate API.
>
> However, it is better to do this part in the userland using a well-defined
> and documented API exported by kernel32.dll, rather than
>
> by means of native API, which is largely undocumented and is a subject to
> change.
>
> Anton Bassov
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/296469#Comment_296469
>
> Check it out:
> https://community.osr.com/discussion/comment/296469#Comment_296469
>

Again, opening a handle with specific privledges has no bearing on this. if you want to log wether a given process is in the run / suspend state, you probably want to do that all the time, but regardless, check out PROCESS_EXTENDED_BASIC_INFORMATION

https://docs.microsoft.com/en-ca/windows/win32/procthread/isolated-user-mode--ium--processes?redirectedfrom=MSDN

if you want to log wether a given process is in the run / suspend state, you probably want to do that all the time,

…and still may be getting outdated data from time to time - even if you monitor it in a tight polling loop. This applies to monitoring the state of any resource that you don’t own. Judging from the OP’s latest post, this is not critical for him once he wants to do it for the logging purposes only, but anyway…

Anton Bassov

it may be the case that i should only focus on the ‘suspend-resume’ access
request, and question if that should be granted based on the requesting
process.

On Wed, Mar 18, 2020 at 11:00 AM anton_bassov
wrote:

> OSR https://community.osr.com/
>
> anton_bassov commented on detecting if a process is suspended or resumed
>
> > if you want to log wether a given process is in the run / suspend state,
> you probably want to do that all the time,
>
> …and still may be getting outdated data from time to time - even if
> you monitor it in a tight polling loop. This applies to monitoring the
> state of any resource that you don’t own. Judging from the OP’s latest
> post, this is not critical for him once he wants to do it for the logging
> purposes only, but anyway…
>
> Anton Bassov
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/296484#Comment_296484
>
> Check it out:
> https://community.osr.com/discussion/comment/296484#Comment_296484
>

Again, I am confused by your statement

‘suspend-resume’ access request

Are you thinking that each time some process wants to suspend / resume another, they will open a new handle to that process? If so, that would explain some of the difficulty because that is not true at all. A given process can open a handle with this kind of permission, never use it, or keep it open for a month and suspend / resume a million times.