Windows 7 Task Manager: Difference between applications, processes, and services

Question

I would like to know the difference between Applications, Processes, and Services, as listed in the Windows 7 Task Manager. Under UNIX/Linux, these terms work as follows: processes refer to executable files which are running in the sense that they have been loaded in memory and are executing, and the same executable can be run several times to create multiple processes in memory running the same executable; applications usually are processes which have an associated graphical user interface; and services are usually headless processes which do not display a GUI but run in the background.

I would like to know whether the Windows 7 Task Manager application uses these terms in the same way as on UNIX/Linux as listed above.

Thanks.

Answer 1

Most of the question posed here are answered fine here so I'm not going to cover old ground now.

for services that do not run as svchost.exe, what is it that differentiates them from other non-service processes?

The only thing that makes a service different from any other process is that it remains open in order respond to something. There is nothing else different about them but this does mean that they often have certain characteristics. They are usually CLI apps because they generally don't need (or want) a GUI. They can also be DLLs if a host process is meant to manage them (such as svchost.exe); very generally speaking, a DLL is code which doesn't have an entry point (meaning it cannot be ran directly but a program can load it into memory and run the code).

In order to explain this better we need to introduce a new term, threads. A process can spawn new threads. The main thing to understand about threads is that each thread gets it's own execution pointer and acts like a process within the parent process. svchost.exe is a process which you can register a service with. When you do that, the service will be ran as a thread within the svchost.exe process. Another important thing to understand about threads is that they don't show up in Task Manager (only the parent process does).

There are actually two instances of svchost.exe on your system. One is a user mode process and the other is owned by SYSTEM. The SYSTEM copy allows services which run before anyone logs in (which is something that most services will want to be able to do).

In order for svchost.exe to know what to do with a service, it must be capable of acting like a DLL. This means that it needs to implement DLLMain. Additionally, it must also have a HandlerEx method which responds to the events which svchost.exe fires (SERVICE_CONTROL_STOP, SERVICE_CONTROL_SHUTDOWN, SERVICE_CONTROL_PAUSE, SERVICE_CONTROL_CONTINUE, SERVICE_CONTROL_INTERROGATE).

If the service has implemented those then it simply needs to be registered with svchost.exe so that it knows about it. This is done with the applications sc.exe and installutil.exe.

Now that I've explained how it all works I've got to mention that much of this is deprecated in newer versions of Windows. I believe that the current suggested approach is for service devs to also create their own host process (their own svchost.exe). This is because svchost.exe has been the perfect hiding place for malware since its inception. The majority of users have no idea how to reg\unreg services with svchost.exe and only sort of know how to even see them (the services manager).

By not allowing devs to attach to svchost.exe it means that they must create a new process for their services which means that this new process will show up in task manager. Still, I believe that even in the latest versions of Windows, the old method of using sc.exe will still work for backwards compatibility. Considering that Windows users are still dealing with bugs which have existed since DOS, I'd imagine that it'll still be possible for a long time to come. Officially, svchost.exe is only for Windows services now.

Answer 2

Your understanding of the different kinds of programs maps pretty well to Windows. You start executables to create a process, and applications are processes that show a window.

However, a service is more than just a windowless process. (I'm not an expert, but here's some more information from what's I've seen with Windows.)

A windowless process can bring up a window whenever it wants, but a service is isolated from the desktop.

You can easily set services to automatically start up with the computer. When you stop a service, it seems to take the time to shut down gracefully, as opposed to just killing the process.

If you go to Services, you'll see several services are listed, but with a Stopped status --Windows doesn't keep track of stopped applications like that!

If you open the Services program you can see that the properties for a service specify running an executable with certain command line arguments.

While you can have multiple processes running the same executable, I've never seen duplicate services. If you sort services by PID, you'll see that many services can be running from one process.