View Processes Running on Windows Server

View Processes Running on Windows Server

This article will help you view all running processes on your Windows server using Task Manager.

The following article applies for Windows Server 2008 and 2012.

View Running Processes on Windows 2008 Server

1

Log in to your server through a Remote Desktop connection.

2

Hold Ctrl+Shift+Esc or right-click on the Windows bar, and choose Start Task Manager

3

In Windows Task Manager, go to the Processes tab.

By default, the Processes tab displays a list of the running processes and their actual resource utilization:

· Image Name – the binary executable file of the running process

· User Name – the user of the current process

· CPU – processor time utilization as a percentage of total CPU resource

· Memory – physical memory utilization in Kilobytes

View Running Processes on Windows 2012 Server

1

Log in to your server through a Remote Desktop connection.

2

Hold Ctrl+Shift+Esc or right-click on the Windows bar, and choose Start Task Manager.

3

In Windows Task Manager, click on More details.

4

The Processes tab displays all running processes and their current resources usage.

To see all processes executed by an individual user, go to the Users tab (1), and expand User (2).

In the above example, all running processes have been started by the user “Administrator.”

Created: October 16, 2017 07:07

Last Updated: October 05, 2020 08:55

Related articles

Have More Questions?

Contact our support instantly via Live Chat

Controlling Processes and Threads

When you are performing user-mode debugging, you activate, display, freeze, unfreeze, suspend, and unsuspend processes and threads.

The current or active process is the process that is currently being debugged. Similarly, the current or active thread is the thread that the debugger is currently controlling. The actions of many debugger commands are determined by the identity of the current process and thread. The current process also determines the virtual address mappings that the debugger uses.

When debugging begins, the current process is the one that the debugger is attached to or that caused the exception that broke into the debugger. Similarly, the current thread is the one that was active when the debugger attached to the process or that caused the exception. However, you can use the debugger to change the current process and thread and to freeze or unfreeze individual threads.

In kernel-mode debugging, processes and threads are not controlled by the methods that are described in this section. For more information about how processes and threads are manipulated in kernel mode, see Changing Contexts.

Displaying Processes and Threads

To display process and thread information, you can use the following methods:

Setting the Current Process and Thread

To change the current process or thread, you can use the following methods:

Freezing and Suspending Threads

The debugger can change the execution of a thread by suspending the thread or by freezing the thread. These two actions have somewhat different effects.

Each thread has a suspend count that is associated with it. If this count is one or larger, the system does not run the thread. If the count is zero or lower, the system runs the thread when appropriate.

Typically, each thread has a suspend count of zero. When the debugger attaches to a process, it increments the suspend counts of all threads in that process by one. If the debugger detaches from the process, it decrements all suspend counts by one. When the debugger executes the process, it temporarily decrements all suspend counts by one.

You can control the suspend count of any thread from the debugger by using the following methods:

n (Suspend Thread) command increments the specified thread’s suspend count by one.

m (Resume Thread) command decrements the specified thread’s suspend count by one.

The most common use for these commands is to raise a specific thread’s suspend count from one to two. When the debugger executes or detaches from the process, the thread then has a suspend count of one and remains suspended, even if other threads in the process are executing.

You can suspend threads even when you are performing noninvasive debugging.

The debugger can also freeze a thread. This action is similar to suspending the thread in some ways. However, «frozen» is only a debugger setting. Nothing in the Windows operating system recognizes that anything is different about this thread.

By default, all threads are unfrozen. When the debugger causes a process to execute, threads that are frozen do not execute. However, if the debugger detaches from the process, all threads unfreeze.

To freeze and unfreeze individual threads, you can use the following methods:

f (Freeze Thread) command freezes the specified thread.

u (Unfreeze Thread) command unfreezes the specified thread.

In any event, threads that belong to the target process never execute when the debugger has broken into the target. The suspend count of a thread affects the thread’s behavior only when the debugger executes the process or detaches. The frozen status affects the thread’s behavior only when the debugger executes the process.

Threads and Processes in Other Commands

You can add thread specifiers or process specifiers before many other commands. For more information, see the individual command topics.

You can add the

e (Thread-Specific Command) qualifier before many commands and extension commands. This qualifier causes the command to be executed with respect to the specified thread. This qualifier is especially useful if you want to apply a command to more than one thread. For example, the following command repeats the !gle extension command for every thread that is being debugged.

Multiple Systems

The debugger can attach to multiple targets at the same time. When these processes include dump files or include live targets on more than one computer, the debugger references a system, process, and thread for each action. For more information about this kind of debugging, see Debugging Multiple Targets.

How can I see processes running in Windows 7?

I found the following sentence:

Many Windows-Users may have wondered about the mDNSResponder.exe process running all the time. It’s Bonjour.

Does anybody know how can I see these processes (I do not mean «mDNSResponder.exe». I mean in general.). It should be some analog of «top» command in Linux.

8 Answers 8

In the windows command line you can use tasklist to list all running processes.

You can pipe the output of tasklist (as well as any other command line tool) using the «|» character. I almost always use tasklist in this manner.

The GUI version is called the Task Manager and there are a number of ways to access it.

What you want may be satisfied by Task Manager (Ctrl-Shift-Esc), but in case you (or others reading this) want more information, another option (not built into Windows but supported by Microsoft) is Process Explorer from the Microsoft SysInternals suite. It is way more useful if you want to do more with that list of processes and see more information. Very very useful to track down tricky system problems.

Process Explorer was developed by Mark Russinovich, author of the various Windows Internals editions and now a Technical Fellow at Microsoft. It has an active support forum.

You can view the processes by running the Task Manager.

Right-click an empty space in the taskbar and select Task Manager. You’ll also find a button to start it by triggering CTRL+ALT+DEL.

Run a process from a windows service as the current user

I currently have a windows service that is running under the System Account. My problem is that i need to start certain processes from within the service as the current logged on user. I have all the code etc to get the current logged on user / Active session.

My problem is that i need spawn a process as the logged on user but will not know the user credentials etc.

The service is .net compiled service and i expect that i need to use some Pinvoke methods to get a handle of one of the current users process in order to duplicate it and lunch as process with the handle.

Unfortunately i cannot find any good documentation / solution on how to implement it?

If someone is able to give me some guidance / example i would highly appreciate it.

* Updated * I think i have explained this incorrectly and need to reajust according to what i actually require. I do not necessarily want to launch a new process, i just want to impersonate the logged on user. I have been so wrapped up at looking at CreateProcess etc i have lead myself down a path of create a new process as the current logged in user (which is not particularly what i want to do).

In turn i just want to run some code under the current user context (Impersonate the current Logged on user)?

2 Answers 2

One option is to have background application that automatically starts when user logs on and listens to commands from your service through WCF, or thrift, or by just monitoring some file and reading command from there.

Another option is to do what you originally asked for — launch using windows API. But the code is quite scary. Here is a sample, that you can use. It will execute any command line under currently active user session, with CreateProcessInConsoleSession method:

As is so common with these types of questions about Windows services, you’re operating in the mindset of a single-user operating system. The whole reason you decided to write your app as a service was because you were running into conflicts between your mental model of a single-user OS and the reality of a multi-user OS. Unfortunately, a service didn’t solve all of your problems and now you’re trying to figure out how to accomplish step two in the ultimately-doomed hacked design.

The fact is, you cannot be guaranteed that there is a «logged on user». If no one has logged on to the workstation, there will be no one logged on, yet your service will still be running.

Even if you somehow got past this by ensuring that someone will always be logged on (impossible), then you would run into the situation where multiple users are logged on. Then which one should your service start the process as? Should it just pick one of them randomly?

And is it necessary in your case to distinguish between users logged on locally to the console and those who are logged on remotely? Remember that remote users won’t have a local console.

If you could somehow get past all of these hurdles (unfortunately, probably by burying your head in the sand and continuing to pretend that Windows is a single-user OS), you could make use of the WTSGetActiveConsoleSessionId function to obtain the current session ID, the WTSQueryUserToken function to obtain the user token corresponding to that session ID, and then finally the CreateProcessAsUser function to launch your process in the context of that user. If there is one. And they have the appropriate privileges. And the physical console is not attached to a dummy session. And you’re not running a server SKU that allows multiple active console sessions. And…

If you could decide on a particular user whose account you wish to use to start the auxiliary process, you could log on that user, manipulate their user token, execute the process, and finally close the process and log out the user. The CreateProcessWithLogonUser function wraps up a lot of this drudgery for you, making the code a lot more svelte. But appearances can be deceiving, and this still has some massive security implications that you probably do not completely understand if you’re asking this question in the first place. And you really cannot afford to not understand security risks like this.

Besides, users that are logged in with LogonUser (which is done for you automatically when you use the CreateProcessWithLogonUser function) lack a window station and desktop on which they can launch interactive processes. So if the process you wish to launch in the context of that user will show any kind of UI, you’re out of luck. Windows will kill your app as soon as it tries to access a desktop for which it lacks the requisite permissions. There is no way, from a Windows service, to obtain the handle of a desktop that will be useful to you (which goes a long way towards explaining the general rule you probably already know, that services cannot display any type of UI).

C++, How to determine if a Windows Process is running?

This is concerning Windows XP processes.

I have a process running, let’s call it Process1. Process1 creates a new process, Process2, and saves its id.

Now, at some point Process1 wants Process2 to do something, so it first needs to make sure that Process2 is still alive and that the user has not not killed it.

How can I check that this process is still running? Since I created it, I have the Process ID, I would think there is some library function along the lines of IsProcessIDValid( id ) but I can’t find it on MSDN

12 Answers 12

You can use GetExitCodeProcess . It will return STILL_ACTIVE (259) if the process is still running (or if it happened to exit with that exit code 🙁 ).

The process handle will be signaled if it exits.

So the following will work (error handling removed for brevity):

Note that process ID’s can be recycled — it’s better to cache the handle that is returned from the CreateProcess call.

You can also use the threadpool API’s (SetThreadpoolWait on Vista+, RegisterWaitForSingleObject on older platforms) to receive a callback when the process exits.

EDIT: I missed the «want to do something to the process» part of the original question. You can use this technique if it is ok to have potentially stale data for some small window or if you want to fail an operation without even attempting it. You will still have to handle the case where the action fails because the process has exited.

The solution provided by @user152949, as it was noted in commentaries, skips the first process and doesn’t break when «exists» is set to true. Let me provide a fixed version:

Another way of monitoring a child-process is to create a worker thread that will :

1. call CreateProcess()
2. call WaitForSingleObject() // the worker thread will now wait till the child-process finishes execution. it’s possible to grab the return code (from the main() function) too.

I found this today, it is from 2003. It finds a process by name, you don’t even need the pid.

You can never check and see if a process is running, you can only check to see if a process was running at some point in the recent past. A process is an entity that is not controlled by your application and can exit at any moment in time. There is no way to guaranteed that a process will not exit in between the check to see if it’s running and the corresponding action.

The best approach is to just do the action required and catch the exception that would be thrown if the process was not running.

call EnumProcesses() and check if the PID is in the list.

JaredPar is right in that you can’t know if the process is running. You can only know if the process was running at the moment you checked. It might have died in the mean time.

You also have to be aware the PIDs can be recycled pretty quickly. So just because there’s a process out there with your PID, it doesn’t mean that it’s your process.

Have the processes share a GUID. (Process 1 could generate the GUID and pass it to Process 2 on the command line.) Process 2 should create a named mutex with that GUID. When Process 1 wants to check, it can do a WaitForSingleObject on the mutex with a 0 timeout. If Process 2 is gone, the return code will tell you that the mutex was abandoned, otherwise you’ll get a timeout.

You may find if a process (given its name or PID) is running or not by iterating over the running processes simply by taking a snapshot of running processes via CreateToolhelp32Snapshot, and by using Process32First and Process32Next calls on that snapshot.

Then you may use th32ProcessID field or szExeFile field of the resulting PROCESSENTRY32 struct depending on whether you want to search by PID or executable name. A simple implementation can be found here.

While writing a monitoring tool, i took a slightly different approach.

It felt a bit wasteful to spin up an extra thread just to use WaitForSingleObject or even the RegisterWaitForSingleObject (which does that for you). Since in my case i don’t need to know the exact instant a process has closed, just that it indeed HAS closed.

I’m using the GetProcessTimes() instead:

GetProcessTimes() will return a FILETIME struct for the process’s ExitTime only if the process has actually exited. So is just a matter of checking if the ExitTime struct is populated and if the time isn’t 0;

This solution SHOULD account the case where a process has been killed but it’s PID was reused by another process. GetProcessTimes needs a handle to the process, not the PID. So the OS should know that the handle is to a process that was running at some point, but not any more, and give you the exit time.