PC too slow, possible malware infection, just not behaving as it should? Then you'll probably launch Task Manager or something similar to figure out what’s going on.
Sounds great, until you find 50 or more cryptically-named background processes and realize you’ve barely any idea what most of them do.
At this point, most people start taking short cuts. This process name looks familiar, that one’s running in the Windows folder, let’s just assume they’re okay…
Unfortunately malware authors understand this only too well, and employ a range of tricks to make their processes blend in with everything else.
A better approach is to spend a little time learning about common PC processes. This doesn't have to be to any great depth, or require any low-level, developer-type knowledge -- it's just a matter of understanding a few basic rules, to help you spot when something’s wrong.
We're going to start by looking at some common Windows processes. Here's what you need to know.
Getting equipped
You could make do with Task Manager if there’s no alternative, but to properly understand what's running on your system requires something more.
We're going to use Process Explorer here, but Process Hacker is just as good – arguably better -- and any tool which displays processes in tree form, so you can see their parents, will prove useful.
Make sure whatever you’re using is configured to show key process information. In Process Explorer, click View > Select Columns and check at least User Name, Verified Signer, Image Path, Command Line, Session and Virus Total.
Relaunch your app as an administrator, giving you the privileges to view all this data, and then start browsing the list of processes.
System, Idle
These are created by the Windows kernel as your system starts. They're not regular processes -- they don't have an image name or an address space -- but it’s normal for them to generate CPU and other activity.
System Idle Process should have a PID (Process ID) of 0, System will be 4, and both will be running as SYSTEM (User will be displayed as NT AUTHORITY\SYSTEM or just SYSTEM, depending what you’re using).
Neither System or System Idle Process have a parent, but System will be the parent for smss.exe and Interrupts.
SMSS
SMSS.EXE is the Windows Session Manager, the application used to manage the desktop and all the processes belonging to an individual user.
SMSS is the first user-mode process launched by System, so it should appear as a child of System on the tree, and be running as SYSTEM, in Session 0, from the %SystemRoot%\System32 folder.
Malware might try to disguise itself by using a similar name -- smmss.exe -- so once you’ve selected it in the Process Explorer tree, click the Process column header to sort the list into alphabetical order and check for lookalikes. (Which may be entirely innocent, of course, but are worth investigating further.)
Click the PID column header to sort by Process ID, too. The real System, Idle, SMSS processes are clustered together with low PIDs, while programs running in your user account are much higher.
Scroll down the process list, checking the Session column. On a regular stand-alone PC you should see only sessions 0 and 1. Other sessions could be entirely legitimate -- you’ve switched to a second account, a trusted user on your network has made a remote desktop connection -- but if you don't understand the reason, might be worth further investigation.
CSRSS, WININIT
CSRSS is the Client/ Server runtime, a Windows management process
CSRSS is launched by an instance of SMSS which then exits, so the legitimate processes (one per session) won’t have any parent.
Otherwise CSRSS has all the usual system-type attributes: an image in %SystemRoot%\System32, running as SYSTEM, with a PID clustering around the other core system processes.
It’s another candidate for process name spoofing, so sort the Process list alphabetically again to look for anything similar.
WININIT
WININIT kick-starts Windows by launching processes to handle security (LSASS), run drivers and services (SERVICES).
It’s launched from an instance of SMSS, and won’t have any parent, but should be the parent for services.exe and lsass.exe.
There's one instance only, running as SYSTEM, in session 0.
SERVICES
The Service Control Manager -- SERVICES.EXE -- finds and runs all the non-boot drivers and services you’ve installed (boot drivers and services have already been launched).
The legitimate SERVICES will appear once, running as SYSTEM, and be a child of WININIT.
SERVICES is also going to be the parent for a lot of processes, some managed by the standard hosting process (SVCHOST), others working on their own (like AppleMobileDeviceService.exe).
SVCHOST
SVCHOST is the Host Process for many Windows and third-party services.
There will be multiple SVCHOST instances running on every PC, and malware commonly uses similar names to dodge any attention.
The real SVCHOSTs will be a parent of SERVICES, and running in Session 0 as SYSTEM, LOCAL SERVICE or NETWORK SERVICE.
The executable runs from %SystemRoot%\System32, with a command-line -k switch indicating its account or service name.
LSASS
The Local Security Authority process (LSASS.EXE) is responsible for all kinds of authentication and security management tasks, which makes it a regular target for attackers.
Normally you’ll have a single LSASS, a child of WININIT, which doesn't have any child processes itself.
The regular LSASS process runs as SYSTEM, in session 0, and typically won’t do much apart from generate a little CPU activity (and you’ll only notice that if you look closely).
Malware sometimes tries to disguise itself with similar names, so pay attention to any lookalikes.
WINLOGON
WINLOGON is the Windows Log-on Application, the process which manages access to your desktop(s).
WINLOGON runs as SYSTEM in Session 1, and will appear again if you have any additional sessions (although if you do, as we mentioned before, it’s worth investigating why).
The process may have a child process of LogonUI if authentication is ongoing, or DWM.EXE – the Desktop Window Manager – on Windows 8 or later, with a user of DWM-1.
Once you’ve authenticated, WINLOGON checks the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon for the name of any initialisation processes it needs to run next.
Normally this specifies only one -- C:\Windows\system32\userinit.exe, -- but malware may add others after the comma. Check if you’re in any doubt.
USERINIT
The User Initialisation process is launched by WINLOGON, and sets up the user environment.
After running logon scripts and other startup tasks, USERINIT launches the shell process specified at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell.
Typically this is Explorer.exe, which then sets up your desktop, start menu or whatever else your version of Windows provides, as well as launching as any startup programs.
But this provides another way for malware to infect your system. Again, take a look if you’re in any doubt.
USERINIT should close down after launching the shell, which means it won’t appear on your task list (but it’s important enough that we’re listing it here anyway).
EXPLORER
The end result of all this activity is the EXPLORER process, the front end for much of your PC activity.
It’s launched from the Windows folder, in session 1, and in your own user account.
EXPLORER has no parent, but just about every program you’ve launched -- manually, or as a startup application – will appear as a child.
There are no simple process rules to detect EXPLORER attacks, and that’s outside the scope of this list anyway, but a good place to start is by looking for infected modules.
In Process Explorer, click View > Show Lower Pane, then View > Lower Pane View > DLLs.
Click EXPLORER.EXE and browse the lower pane, checking each file for its VirusTotal score.
CONHOST
It’s not an essential part of Windows launch, but you might still find the Console Window Host running on your system.
This isn’t likely to be impersonated by malware, so as long as it’s running from \Windows\System32 and signed by Microsoft then the process itself is going to be safe.
What’s more interesting is why it’s been launched, as the presence of CONHOST indicates some console-based activity. That might be completely safe and legitimate – you’ve just opened a command window, an application has used the shell for something – but take a closer look anyway. Which process was the parent, what’s the user account, when was it launched?
General rules
You won’t remember every detail of every system process, but just following a few basic principles will take you a long way.
Check the parent and children of interesting processes, then click the Process column header to sort the list alphabetically and look for similar names.
Check the User Name for a process to see if it’s being run with SYSTEM privileges.
Look at the process path. Something trying to match a system process but running from an odd location like \Windows\Temp is a definite red flag, but don’t automatically assume that something in \Windows\System32 is an “official” process, either. Check for a Microsoft Corporation digital signature via Process Explorer’s “Verified Signer” column (double-click the process if this is blank and it should be filled in).
Pay close attention to the Command Line, too -- not only does this tell you what a process is called, and where it’s being launched from, but you’ll sometimes spot odd switches or arguments which tell you something is wrong.
Whatever you find, remember that most of these are general rules of thumb only. A 57/57 VirusTotal score might be reason to panic, but otherwise it’s best to investigate any issues before taking drastic action.
