Introduction

A Windows service stores the command it launches in its service configuration, usually as an executable path plus optional arguments. To find the real .exe path, the most reliable methods are the service controller tools, PowerShell, or the registry entry behind the service.

Fastest Method: PowerShell

PowerShell gives you the service command line directly through WMI or CIM. The property you want is PathName.

Get-CimInstance Win32_Service -Filter "Name='Spooler'" |
    Select-Object Name, State, PathName

Typical output looks like this:

Name     State   PathName
----     -----   --------
Spooler  Running C:\Windows\System32\spoolsv.exe

For a custom service, PathName may include arguments as well, for example "C:\Program Files\MyApp\service.exe" --config C:\MyApp\app.json.

Using sc.exe

The built-in service controller also exposes the configured binary path.

sc qc Spooler

Look for the BINARY_PATH_NAME line. That field is the service command line used by the Service Control Manager.

This method is useful on systems where PowerShell is restricted or when you are already working in a classic command prompt.

Reading the Registry Entry

The underlying configuration lives under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>. The value usually named ImagePath contains the executable plus arguments.

You can read it from PowerShell without opening Registry Editor.

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Spooler" |
    Select-Object ImagePath

This is effectively the same source of truth used by the operating system, so it is helpful when higher-level tools are unavailable.

Distinguish the EXE from the Full Command Line

A common mistake is treating the entire stored path as the executable. Services often include startup arguments. If you need only the .exe, extract the first token carefully, respecting quotes.

1$path = (Get-CimInstance Win32_Service -Filter "Name='Spooler'").PathName
2
3if ($path.StartsWith('"')) {
4    $exe = $path.Split('"')[1]
5} else {
6    $exe = $path.Split(' ')[0]
7}
8
9$exe

That simple parsing logic works for many service definitions. If you are writing tooling for arbitrary systems, use a more robust command-line parser because spaces and escaped quotes can make naive splitting unreliable.

When the Path Looks Strange

Some services run through svchost.exe or another host process rather than a dedicated application binary. In those cases, the service name maps to a shared host, and the path you see is still correct for the service process model. The real service implementation may be a DLL loaded by the host process rather than a standalone executable written specifically for that service.

That distinction matters for troubleshooting. The path tells you what starts the service process, but not always which module inside that process implements the service logic.

Common Pitfalls

• Reading only the Services UI can be misleading if you need the raw command line with arguments.
• Treating PathName or ImagePath as a plain executable path ignores the possibility of startup arguments.
• Splitting on the first space without handling quotes breaks paths under Program Files.
• Assuming every service has its own dedicated executable is wrong because some services run under shared host processes.
• Looking at the display name instead of the actual service name can cause sc.exe and registry queries to fail.

Summary

• 'Get-CimInstance Win32_Service is usually the quickest way to retrieve a Windows service command path.'
• 'sc qc <ServiceName> exposes the same configuration from the command line.'
• The registry ImagePath value is the underlying stored source.
• Many services include arguments, so separate the executable from the full command carefully.
• Shared-host services such as those under svchost.exe require extra interpretation beyond the raw path.