How to Start a Windows Service with Custom Startup Parameters from Command Line or Script


1 views

Many developers encounter issues when trying to pass startup parameters to Windows services using the net start command. The common misconception is that you can simply append parameters after the service name, like:

net start MyService /param1 value1 /param2 value2

However, this approach fails because the net start command doesn't properly handle parameters containing spaces or values that don't begin with a forward slash.

Method 1: Using sc config

The most reliable way to set startup parameters is through the Service Control Manager (SCM) configuration:

sc config MyService start= demand
sc config MyService binPath= "\"C:\path\to\service.exe\" /param1 value1 /param2 value2"
net start MyService

Note the important details here:

  • Use start= demand to set manual startup
  • Wrap the entire binary path and parameters in quotes
  • Escape the inner quotes around the executable path

Method 2: PowerShell Approach

For more flexibility, PowerShell provides better parameter handling:

Start-Service -Name "MyService" -ArgumentList @("/param1", "value1", "/param2", "value2")

Or for more complex scenarios:

$service = Get-WmiObject -Class Win32_Service -Filter "Name='MyService'"
$service.Change($null,$null,$null,$null,$null,$null,"C:\path\to\service.exe /param1 value1 /param2 value2",$null,$null,$null,$null)
Start-Service MyService

For services that always need specific parameters, you can modify the registry:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\MyService" /v ImagePath /t REG_EXPAND_SZ /d "\"C:\path\to\service.exe\" /param1 value1 /param2 value2" /f

This change will persist across reboots and service restarts.

When configuring service parameters, watch for these common pitfalls:

  • Ensure proper escaping of quotes in paths
  • Account for spaces in parameter values
  • Verify the service executable actually accepts command-line parameters
  • Check event logs for service startup errors

Remember that not all Windows services are designed to accept startup parameters. Consult your service's documentation to verify this capability before attempting to implement these solutions.


When working with Windows services in automation scripts, a common requirement is passing custom startup parameters. The standard net start command has surprising limitations in this regard:

:: This works
net start MyService /param1

:: This fails with syntax error
net start MyService param1

:: Complex parameters cause issues
net start MyService /config:"C:\path\with spaces" /debug

The Windows service control manager has specific parsing rules for parameters:

  • Parameters must begin with forward slash (/)
  • Space-separated arguments aren't natively supported
  • Quoted values still cause parsing issues

Here are several approaches to work around these limitations:

Method 1: SC Command Alternative

:: First set the parameters using sc config
sc config MyService start= demand binPath= "\"C:\path\to\service.exe\" /param1 value /param2"

:: Then start the service
net start MyService

Note the double quotes around the executable path and the parameters.

Method 2: Permanent Configuration via Registry

For persistent parameter settings:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\MyService" /v ImagePath /t REG_EXPAND_SZ /d "\"C:\path\to\service.exe\" /param1 value /param2" /f

Method 3: PowerShell Approach

For more modern systems using PowerShell:

$service = Get-WmiObject -Class Win32_Service -Filter "Name='MyService'"
$service.Change($null,$null,$null,$null,$null,$null,"C:\path\to\service.exe /param1 value /param2",$null,$null,$null,$null)
Start-Service MyService

For services requiring multiple complex parameters, consider creating a wrapper batch script:

@echo off
:: wrapper.bat
"C:\path\to\actual_service.exe" /param1:"value with spaces" /param2 %*

Then configure the service to run the wrapper instead.

  • Always check Event Viewer (Application logs) for service startup errors
  • Use Process Explorer to verify the actual command line used
  • Test parameter parsing with a simple echo service first
  • For .NET services, check the Environment.GetCommandLineArgs() output