Currently Running Software

[#whatruns]: Seeing what is running

One option is to see a list of what is currently running. (Other options may be to see what is using up resources, such as (low amounts of free) memory, CPU time (“CPU usage”), or files being used.)

Checking for a PID file

The nicest way, although (unlike at least some other methods) this method does not always work, may be to find the PID by looking in a text file stored in /var/run/. The main reason that this may be nicer than finding the PID another way is because the process may not need much customizing, and so is fairly automatable. (This can be useful when creating scripts, but can also allow for performing a task with few steps when quickly typing on the command line.)

For instance, in OpenBSD, the BIND name server may be stopped by using:

kill $( cat /var/run/ )

If a background service/process/daemon doesn't make a PID file (which many don't by default), check documentation to see if there is a way to create a PID file when the program starts in the future.

[#pscmd]: the ps (from Unix)
[#pscmdiff] : Implementation differences

The parameters may vary a bit among different operating systems. For example, the manual page for the version of ps bundled with the procps package has quite a few details (found from version 3.2.8). The manual page refers to “the many standards and ps implementations”, and notes compatability with “several kinds of options” emulated with different command line parameters. However, procps's support for BSD-style options may require that the options are not preceeded by a hyphen (because that would indicate using a different style), even though BSD's documentation does show the hyphen as if it is required by the options (as noted by OpenBSD's manual page for ps). Despite that BSD documentation indicating the hyphen looks like a required part of the option, trying to run without the hyphen may or may not actually work. (It seemed optional when tested in “OpenBSD 4.9”.)

For some operating systems, ps -auxww may be a nice choice. Some documentation may suggest that leaving off the hyphen is preferred, although the hyphen may be required in other implementations (which will complain about a syntax error if the hyphen is left off). Actually, the manual page for the version of ps bundled with the procps package states (quoting version 3.2.8),

“Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.”

(That quoted text may also be seen by: Unix help for ps.)

Some implementations, especially seen in embedded devices (using busybox rather than crunchgen), may support fewer parameters. Very often, the output by ps contains more details than just the desired information that is being sought.

To elaborate, Debian manual page for the ps command's “RATIONALE” section says, “There is very little commonality between BSD and System V implementations of ps. Many options conflict or have subtly different usages.” (Quoted text may have been de-hyphenated.)

As noted earlier, a manual page from the psprocs software says, “Note that "ps -aux" is distinct from "ps aux".” That software supports treating an option preceded by a hyphen like an old “Unix option”, while an option without a hyphen may be treated like a “BSD option”. The irony there is that BSD documents the hyphen as required, so trying to mimic BSD behavior may not be very reflective of BSD compatibility.

Even just relying on the software called “procps” does not necessarily simplify things entirely: procps FAQ has a question that states, “Why are there so many procps projects?” The procps package appears to have multiple derivative forks, meaning that other people have spent some effort to independently evolve the software.


See: OpenBSD manual page for ps: “Caveats” section.

Try running:

ps -auxww | $PAGER

(It may be necessary to press Ctrl-C or q to quit the pager.)

After identifying which column has the desired information (e.g. perhaps the PID, which may be second row, right after the username which may be in the first row), narrow down the output. For instance, if the desired program was dhclient, use something like:

ps -auxww | grep dhclient | grep -v grep
[#grepxslf]: Having grep exclude itself

The point to the second redirection is so that the first grep command doesn't show in the list. Otherwise, the grep command may randomly appear on the list.

Note that because this effect can happen rather randomly (possibly depending on factors like some specific behavior of the multitasking operating system), this might have no impact (because it was, simply, completely unnecessary)... sometimes.

Why grep command may show up randomly

In practice, the grep command might appear to show up in the list randomly. Here is an explanation of what is happening.

In Unix, the pipe redirection symbol will cause both programs to start up at nearly the same time. However, the multitasking operating system may vary a bit in how it handles multiple programs that are running. The specific details may vary based on what operating system is used, as well as what other activities the multitasking operating system might be performing. In some cases, the ps command might be started up more quickly. In other cases, the grep command might be started up a bit more quickly. The ps command can be a very quick command, so either one of the following are possibilities:

  1. The ps command starts up slightly before the grep command. In this case, the ps command might even complete its entire task before the grep command is fully started. As a result, the ps command might not even show the grep command. This is simply because the ps command finished checking what processes exist, and did this before grep started up fully enough for ps to notice that it is running.
  2. Another possibility is that the grep command starts up a bit sooner, or more quickly, then the ps command. In this case, the grep command is just going to end up waiting for input to be generated, so the grep command will end up waiting for the ps command. In this case, the ps command will notice that the grep command is running, so the grep command will show up in the list of what ps outputs.

Whether or not the ps command will show the grep depends on how the operating system runs the programs. For instance, running the following command...

ps -auxww | grep

... and then pressing Up Arrow and Enter over and over again, to run the command frequently, may sometimes show the grep command, and other times might not show the grep command. (This is not guaranteed to happen, because all of the results depend on how the multitasking operating system is handling the processes. However, in practice, this can frequently happen on at least some systems.)

So, running:

ps -auxww | grep dhclient | grep -v grep

Will remove any command that includes the word “grep”. (In theory, creators of malicious software could include the word “grep” to help hide the command. However, when people are dealing with normal software that is not trying to hide itself, this technique can very often accomplish the desired result.)


This may take a program name as a parameter. However, not as many operating systems include the pgrep command compared to some alternatives like ps or perhaps even top.

[#pstree]: pstree
This may exist, being pre-installed on some operating systems, and/or be downloadable. pstree at freecode (hyperlinked to by Wikipedia's article on pstree) may have a hyperlink to an FTP site which has pstree files. This may help to more easily show which programs have started other programs, and what those programs are.
Other options

See: finding out what is using the CPU.

[#uxwusrun]: Seeing what people are actively doing

Note: This is simply a collection of some ideas. If the goal is to catch an attacker, then know that some attackers are quite skilled, and can use automation to cause attacks to be performed very quickly. An attack may be successfully completed within seconds, or less. So, trying to catch an attack with these techniques may not be the most effective method against some very skilled attackers. (Attackers might also try to have their attacks being hidden.) Logging may be necessary to really understand what actions an attacker has taken (and, that only works if the logging contains details about the activity, and if the logs do not get altered.) However, these techniques might, at least in some theory, reveal the presense of a slow novice attacker.

what to look for:

Any logged in users other than the account being used so far.


Note: This is using OpenBSD's syntax for ps. Unfortunately, there is no detailed syntax that is universally compatible. (See: ps command implementation differences, seeing what is running.)

Command to run:
ps -auxww | head -1
ps -auxww | grep sshd
What to look for:

Presumably root will own a process which will show the sshd command line. What other users have SSH sessions. Multiple sshd processes per SSH session is a legitimate possibility. If there is continued doubt, try using:

netstat -na | grep \.22

That is for looking for TCP port 22, which is IANA's standard. If a customized TCP port is being used, check that port number instead.)

The second column that has IP addresses will show where the connection is coming from.


Note: This is using OpenBSD's syntax for ps. Unfortunately, there is no detailed syntax that is universally compatible. See: ps command implementation differences, seeing what is running.)

Command to run:
ps -auxww | less
What to look for:

Anything in the TT column which does not show “??”.

In fact, the following might trim down the useless output (but could potentially hide some attacks designed to exploit this technique).

ps -auxww | grep -v \?\?

This tends to show programs that have been manually started (including shells), including items that might be attached via a terminal multiplexer (tmux or the older screen). Although very skilled attackers might have less need for an interactive console, this may show some activities.

Microsoft Windows
[#runinprg]: Listing what is running
Command line options

TaskList.EXE may come with the operating system. MS KB 314056: Description of svchost.exe mentions TaskList, and says, Tasklist is not included in Windows XP Home Edition. This” ... “is intended for advanced users in commercial environments.” The software is included in Win7 Home Premium.

(Note to JP Software users: A trimmed-down version of TaskList may come with the JP Software product. Users of such a product may run the external program by being careful to reference TaskList.exe instead of just TaskList. Alternatively, a bit of a more convoluted syntax like the following may be used:

cmd /c TaskList /? | list /s
Using WMI

Command lines may be able to be seen by using: “ wmic process GET CommandLine ” That command shows the command lines of what is running. More details about the commands are also available from the WMI object. Some examples are shown in the section about using information from Microsoft Windows command line programs to determine CPU usage.

One potentially nice thing about WMI is that this approach might help to get information about remote systems. (See WMI for details on interacting with remote systems.)

Using the Unix-like command ps may run the Get-Process cmdlet. (This hasn't been recently confirmed, although seems likely.)
Other software
see: LTR-DATA Tools and utilities for Windows (Warning: This software hasn't been tested by the author of this text, at the time of this writing. As a standard disclaimer, please determine any sort of security/stability impacts before using it.)
Microsoft KB Q927229: Win2KRK Tools for Administrative Tasks discusses PuList, which works on the local computer and also remote systems. Q927229 states, “PuList resembles TList. TList is a Support Tool on the Windows 2000 CD. But PuList also lists the user name that is associated with each process on a local computer.” PuList Installer.

TList has been found as part of Debugging Tools for Windows 64-bit Version. article on Windows 2003 Server Emergency Management Services has a screenshot showing that tlist may be run from “Special Administrative Console” (“SAC”). Larry Osterman's “Shared Services” blog posting mentions the software. Someone named Steve Eck left a comment to that blog. That comment states, “"tasklist /svc" will show similar information to "tlist -s".”

The Windows 98 Resource Kit came with “Microsoft's “Task List Viewer (Tlist.exe)” (using the name shown by MS KB 274024). (This has been known to be bundled with the SSVNC files for Microsoft Windows.)

Another approach

Another option is listed in the section about determining what is using up memory. (See: Low memory.)

PSList (by Sysinternals)
Graphical interface
[#wnprctab]: Task Manager (Processes tab)

In Windows XP and newer, and possibly some older version(s), the simple solution is to run the Task Manager. This may be done from the command line by running TaskMgr. Pressing the three finger salute may also show the Task Manager or, more commonly, a screen that presents multiple options, one of which is to run the Task Manager.

In the “Processes” tab, see if the bottom has a checkbox or button called something like “Show processes from all users”. If so, press that button or make sure that checkbox is checked.

Matching PIDs to what is running

When a PID is being shown, Windows will very often show the “Image Name”. In some cases, that is plenty good. In other cases, it may be less clear what that PID refers to.

[#wngtcmdl]: Seeing what command line is being used with a specific PID
Using WMI
WMIC Process Get CommandLine,ParentProcessID,ProcessID
Graphical tools
Using the Task Manager

Run TaskMgr and check out the Processes tab. A very common thing to do with this software is to go to the Options menu and turn off the “Always on top” option. If there is a button or checkbox to help “Show processes from all users”, be sure to use that.

In Windows Vista and (Server 2008 and) newer, the entire Command Line of each process may be seen. By default, this column will only show if it was being shown the last time Task Manager was running. To make this visible, go to View, and “Select Columns...”. Scroll down to find the “Command Line” checkbox. (Also, to match the command line to a specific PID, make sure the “PID (Process Identifier)” checkbox is checked.)

Another column, “Image Path Name”, may usually be redundant with the “Command Line” column. However, sometimes an executable is called without referencing its full path, in which case the “Image Path Name” column can also be useful to show. (This column's existance has been confirmed in Windows 7, and probably is not available for Windows XP.)

System Information tool

This will not show the entire command line, but it will show the paths of the executables, which may be useful. It also may be the best option that uses a graphical interface and which is available in Windows XP or Windows Server 2003. (These operating systems may still have more informative solutions involving using command line programs.)

You may run the system information tool. Try running msinfo32.exe, or go to the Start Menu and choose (All) Programs, and then Accessories, and then “System Tools”, and then System Information. On Windows XP 64-bit, the exectable file has been known to be the "C:\Program Files\Common Files\Microsoft Shared\MSInfo\msinfo32.exe" file. This may end up running an executable called helpctr.exe.

In the System Information Tool (under “System Summary”, expand “Software Environment” and then choose “Running Tasks”.

Other options

Windows XP and Server 2003 may not have a real way to use graphical tools to see the entire command line that is running. Either just get by with the visible Image Name shown in Task Manager, or the Image Name and Image's Path from the System Information tool, or rely on WMI (using a command line option to get the data quickly), or use downloaded software such as the freely available Process Explorer. (See information about Process Explorer (by Sysinternals).

Using Process Explorer
In Process Explorer, the command line may be obtained from the column called Command Line. If that isn't visible, it may become visible by using the View menu and choosing to “Select Columns...”. (The option is in the default tab that is shown, which is the tab called “Process Image”.) The command line may also be seen by selecting an image, accessing the shortcut/context/right-click menu, and choosing “Properties...” (and viewing the default tab, which is the tab called “Image”). The “Image File” section of the “Image” tab shows the “Command line”.
Seeing what folder a running executable is in
Commands are run from a location. This information is often provided by the tools that will show a command line. Another way that may help is to just locate any files that have the name of the file that was run. There are multiple possible reasons that an executable no longer exists at the location that it started running from, such as a network drive becoming inaccessible. If an unknown executable seems to be missing for unknown reasons, it may be malware that is trying (successfully?) to hide itself. (It may be that some other malware made a temporary file that was executed and then removed. So just because the temporary file doesn't seem to exist anymore does not mean that the system will be clean of malware after the system reboots again.)
Seeing what PID is related to an entry on the task bar

The task bar should show the official window title. Run:

TaskList.exe /FI "WINDOWTITLE eq Untitled - Notepad"

Note: Do not try to use a value like “* - Notepad” to find all Notepad windows. Although TaskList.exe has some support of identifying a value ending with *, it may not support a value starting with * (when tested with Windows Vista).

[#pidsvchs]: Matching services to a PID (in Microsoft Windows)

A PID that is related to svchost.exe might be related to multiple specific services, but not others. Here is a way to determine which ones may be related.

TaskList.exe /SVC | find /V "N/A"

Note to JP Software users: Be sure to specify TaskList.exe instead of just TaskList, so that the internal command isn't being run. (Alternatively, preface the command line with “CMD /C ”.)

[#winsvcnm]: Getting the service names

(This may show names of services, regardless of whether or not they are currently running.)

Each service will have a “Service Name”, which is generally fairly short (and does not include any spaces, so conveniently they are usually/always look like a single word even if the name actually consists of multiple words using some form of camelCase).

Using the command line
sc queryex >> output.txt

MS KB Q166819: “Using Sc.exe and Netsvc.exe to Control Services Remotely” states that these “two new administrative utilities to work remotely with Windows NT services” came with Windows NT Server 4.0 Resource Kit Supplement 1. The main reason why Sc.exe is likely preferred over Netsvc.exe is that Sc.exe comes bundled with newer operating systems. Windows XP documentation for SC provides many other commands that can be performed using this program.


Or, use WMI. For example, use:

WMIC service /OUTPUT:"output.txt" get Caption,Description,DisplayName,Name,ProcessId,ServiceType,Started,StartMode,State,Status/FORMAT:VALUE

... and then look under the column called Name. Or, for even more (possibly/probably useless) details:

WMIC service get /OUTPUT:"output.txt" GET /all

The following shows which account is used to start a service:

WMIC service get /OUTPUT:"output.txt" GET Name,StartName/FORMAT:TABLE

For further information related to WMI, see Common Information Model (“CIM”): “Web-Based” Enterprise Management (“WBEM”), section on Windows Management Instrumentation (“WMI”) for Microsoft Windows.


MS KB Q166819: “Using Sc.exe and Netsvc.exe to Control Services Remotely” states that these “two new administrative utilities to work remotely with Windows NT services” came with Windows NT Server 4.0 Resource Kit Supplement 1.

From the just-referenced documentation, it seems like this software has some capabilities similar to SC. However, this software does not seem to be bundled with newer operating systems.

Using the graphical interface

Run the Services manager. This may be run by using “ MMC services.msc ” or by using Computer Management or other methods.

If not all services are showing up, that usually indicates something is wrong (possibly due to malware), but do note that there may be tabs on the bottom of the window. The “Extended” tab is generally the default tab.

To locate the Service name of a service, view the properties of a service. This interface does not seem to provide a way to list all of the service names (easily, at once). (Using an option that involves the command line interface may be the faster way to get that sort of information.)

More notes

Some additional information that may be a bit related: finding out what is using the CPU

[#adjrunsw]: Adjusting what is running
Stopping software
Using registered services

If the program is a registered service, the nicest way may be use the framework of services to restart the program.


See if the rc.d functionality is implemented.

Microsoft Windows

First, get the service names of a system running Microsoft Windows.


To stop software, use “ net stop ”. (To restart it, use net start.)


This command exists in Windows Vista and newer (and maybe older?). The program describes itself as being designed to communicate “with the Service Control Manager and services”, so presumably the program's name means “Service Control”.

sc stop serviceName

To specify a host name:

sc \\. stop serviceName

The “.” (a period) is customizable. A period refers to the local computer, but other host names may be specified.



WMIC service WHERE "name='serviceName'" call StopService


C:\>WMIC service WHERE "name='serviceName'" GET Name,Started
DisplayName  Name         Started  StartName
LongName     serviceName  TRUE     LocalSystem
C:\>WMIC service WHERE "name='serviceName'" call StopService
Executing (\\SysName\ROOT\CIMV2:Win32_Service.Name="serviceName")->StopService()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
ReturnValue = 0;

C:\>WMIC service WHERE "name='serviceName'" GET Name,Started
LongName     serviceName  TRUE     LocalSystem

The part in the quotation marks should be customized. The first and third lines are identical and optional.

Note that the output of “Method execution successful.” just means that WMIC successfully told the object to stop the service. This does not mean that the service successfully stopped. For instance, if the Result is 2, that could mean that the service was not stopped because of UAC (see: Interacting with UAC from the command line).

WMIC can be used to affect remote systems. See details in the section about interacting with a remote service on a system running Microsoft Windows, in the sub-section about WMIC (which basically just refers to WMI; especially using WMIC with remote systems which points out the /NODE: switch).

Closing applications

For this section, the term “application” refers to any software which is not a service that can be shut down nicely. (This could include a visible program, or a background task, or even a registered service that refuses to shut down nicely.)

In general, there's four ways to shut down a program. One is to use the interface of the program. Another is to use the operating system to ask the program to shut down nicely. Another is to have the operating system forcibly shut down the program. That may or may not cause problems such as data corruption and/or system instability. Another way may be to restart the GUI used by the operating system. (In Windows NT, this involves restarting the operating system. In Unix, this means shutting down X Windows. In Win9x, the GUI can be restarted without restarting the copy of MS-DOS 7 that is bundled with the operating system.)


If the PID is known, use “ kill # ” to send the program a SIGTERM. The program should kindly close. If the program still doesn't want to close, force the issue with “ kill -9 # ” If the program still doesn't want to close, verify that this isn't a Zombie process.

If the PID isn't known, a standard method to successfully stop the program involves starting by finding the PID (and then performing the process using the known PID). (For other methods of finding what PID is running, see the section about finding what programs are running. For instance, ps can output a column showing the PID.)

If the process has been backgrounded, some shells may provide an internal kill command that allows a job number to be specified. For example, “ kill %1 ” stops job number one, and “ kill %?nano ” can kill a job that has a command line that includes the word “nano”. Some of this is covered by the documentation of OpenBSD's manual page for ksh: “Job control” section. Other commands related to jobs can include jobs, bg, and fg. Also, pressing the suspend key sequence, Ctrl-Z, may also be related.

There may also be a command called pkill. That may actually be more convenient. (However, it may be less desirable for automation than interacting with the PID file, mainly because less operating systems may come with this by default.) (A computer that has a functional pkill command might also have a command called pgrep installed. In that case, if just one instance of the program is running, then “ pkill programName ” may have a similar effect to “ kill $( pgrep programName ) ”.)

There may be a command called killall which is similar to pkill on other systems.

X Windows

There is a program called xkill. Running this program may alter the cursor, depending on the implementation. For instance, the cursor may look like a skull over crossbones. Then, click (with the primary/left mouse button) on the program to be executed.

Microsoft Windows

If the program is a service, the nicest way way may be to restart the service (or to just stop the service, if that's really preferred). (For details, see adjusting what software is running, “Using registered services” section.)

Here are some other options (which may be needed if the software is not a service).


This can stop software on the system that runs TaskKill or software on a remote computer. There are some notes shown by Windows Vista TaskKill /? about some features that may not be quite as supported when working on remote machines.

If a PID is known, the following may be used:

TaskKill /PID 12345

To also close any programs that were started by that program, append the /T command line parameter.

Some more elaborate syntaxes are available. For instance, to close MS WiMP without needing to type the entire name:

TaskKill /FI "WINDOWTITLE eq Windows Media P*"

Presumably like TaskList.exe, the wildcards may require a non-wildcard character to be at the first part of the compared string.

If a program doesn't exit cleanly, one may try to force it with /F. The follwoing does so, and also uses /T to try to close all child processes of whatever stopped responding.


After optionally gathering info:


the following may be used:


That gets rid of all isntances of the Calculator. To remove just oen instance, remove based on some other criteria like the ProcessId value.

Using information from MSDN: WMIC - Take Command-line Control over WMI, it appears that “call terminate” may be appropriate to use, insetad of DELETE. (If one approach doesn't work, try the other.)

Using information from MSDN: WMIC - Take Command-line Control over WMI, it looks like using /interactive:on can make the command be a bit safer if you aren't sure just want it will delete.

SysInternals pskill

(This can probably specify, to a remote machine, that a program on the remote machine should be closed.)


The Windows 98 Resource Kit came with “Microsoft's “Task Killing Tool (Kill.exe)” (using the name shown by MS KB 274024). (This has been known to be bundled with the SSVNC files for Microsoft Windows.)

Provided by LTRDATA Tools and utilities for Windows (Warning: This software hasn't been tested by the author of this text, at the time of this writing. As a standard disclaimer, please determine any sort of security/stability impacts before using it.)
Using the Task Manager

An option that may exist for those same operating systems, and which may also be an option from Win9x, is to press the three finger salute. Then, for (at least for some) operating systems other than Win95/98/98SE/ME, select “Task Manager”. Then in Win NT/2K/XP/newer, make sure the running copy of the Task Manager is reviewing the Processes tab, and then check below the list of the processes for a checkbox or button to show processes of all users.

Although this also works in Windows ME, 98SE, 98, 95, and probably even Windows 3.1, this process will not involve running a very featured task manager. There may really be no options provided except to select a program to close, or to back out (cancel) without closing any running program. Also, those operating systems were a bit less resiliant (especially Windows 3.1 when running a DOS application), so closing a program might often not result in increasing the stability of the currently running instance of the operating environment (using a method other than restarting the entire graphical interface envornment).

Starting software

This is typically one of the first skills people learn when they learn a user interface.

However, there can be some interesting ways to pull this off.

Starting software on a remote system
Starting a remote service
[#wnsvcrmt]: Interacting with a remote service on a system running Microsoft Windows
Using the command line

First, identify the service name. (See: get the service names of a system running Microsoft Windows.)

Using sc

This example shows how to start such a service.

sc \\machName queryex serviceName
sc \\machName start serviceName
sc \\machName queryex serviceName

If the service fails, TechNet: Windows Server 2008 R2 Service Events Logging: Basic Service Operations: Event ID 7037 ? Basic Service Operations seems to indicate that help may be available by looking for the non-zero “WIN32_EXIT_CODE” and then using that 4 digit exitCode by running “ net helpmsg ####

Using WMIC to control a remote system's services

See WMI; especially using WMIC with remote systems (which points out the /NODE: switch).


Security notes: Controlling the ability to run programs

Security concerns are a bit lessened by the fact that having permission to start a pre-existing service is different than being able to determine what command line the service runs. Still, mischief could be created, and so it would be nice to be able to stop this.

Some command line options are discussed by Iridium on StackOver: page about starting service only for an authorized user. The SubInACL command seems recommended. (Download Center page for SubInACL)

This can also be handled using sc, which may be more likely to be built into the operating system. However, sc may not be as easy. (For instance, a preliminary check into this made the process appear to involve looking up a user's SID.) That may not be a terrible thing if trying to automate a solution, but for a single instance, it may be more daunting than simply downloading a program that provides a simpler interface. Perhaps see also: How to allow users to enumerate service remotely (which discusses using Sc sdshow and Sc sdset and working with SDDL strings, and also describes a change in Windows Server 2003 SP1 which stopped allowing some access to “Authenticated Users” which is a group that previously had more access), MSDN page on Security Descriptor String Format, University of Washington: Understanding SDDL Syntax, which was based on info documented by Overview of Active Directory Security: created by Brian Arkills and modified by Ross Wilper: archived by the Wayback Machine @, NetworkAdminKB info.

For further details on starting service, see: starting a service in Microsoft Windows. (For instance, that section discusses some further troubleshooting.)

Starting other software

A solution involving OpenSSH (generally available on Unix systems) is described by using SSH keys to control what software gets run.

Starting software in response to an event
Starting software at a specific time

May be supported by Unix and Windows.

Unix: cron
Microsoft Windows: Task Scheduler
Details about this software are mentioned at Microsoft Windows Task Scheduler.
Standardized interfaces for program interaction
Starting services
[#wnsvcbeg]: Starting a service on a system running Microsoft Windows

This section focuses namely on running services. (Additional options may provide even more flexibility: see Remote access: RPC

Options for the command line
Using the SC (command line interface)

See the section titled “Interacting with a remote service on a system running Microsoft Windows”.

The “ \\machName” can be left off if interacting with the computer that is running the SC command. Or, another alternative when using a local file, is to specify the machine name as a period (“ \\.”) which often causes “command line”-based UNC-capable software to use networking communication protocols to have a machine communicate with itself.

Access is denied
[SC] StartService: OpenService FAILED 5:

Access is denied.

See: Interacting with UAC from the command line.

A disabled service
[SC] StartService: OpenService FAILED 1058:

The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

The former reason is more likely.

SC qc serviceName

If that says “START_TYPE” is “4   DISABLED”, then run:

SC config serviceName start= demand

Note: There is a space after that equal sign.

Using “ demand” will cause the “Startup Type” to show as “Manual”. Other options include “ auto” or, on some operating systems (Windows Server 2008, probably also Vista) “ delayed-auto”. Other configurable options can be seen by running “ SC config /? ”.

(Currenty, this section does not contain a more verbose example, just to keep this section more streamlined. However, a more verbose example of this is shown by: Remote Desktop Enabling.)

Using WMI


WMIC service WHERE "name='serviceName'" call StartService

Using the WMIC command is documented further in the section about stopping services.

WMIC can be used to affect remote systems. See details in the section about interacting with a remote service on a system running Microsoft Windows, in the sub-section about WMIC (which basically just refers to WMI; especially using WMIC with remote systems which points out the /NODE: switch).

Using the graphical interface

Start Services.msc, which is part of the Computer Management interface. See: Services (Microsoft Management Console interface).

After highlighting a service, it may be started, stopped, or restarted by using the hyperlinks in the left frame. Or, these same actions may be done by checking out the service's properties, and then using buttons.

Restarting a service (from the MS Windows GUI)

When everything goes well, restarting a service will figure out what services rely on the service that is being stopped, and then stop all services that rely on the selected service, and then stop the selected service, and then restart all of the services that have been stopped. If things do not go quite as well, then the process aborts, which may leave some services in a stopped state. Therefore, if the GUI shows a list of (dependent) services that are about to be restarted, then it is a good idea to make a note on what those services are. (The list of dependent services might also be listed on the service's properties, on the “Dependencies” tab, in the lower half of the screen (in the section that states “The following system components depend on this service”).)

See also the prior notes about Interacting with a remote service on a aystem running Microsoft Windows.