Fix 'Error 1067: The process terminated unexpectedly' When Starting a Windows Service

What's happening

You tried to start a Windows Service — from Services.msc, the command line, or after a reboot — and got this:

Windows could not start the service on Local Computer.
Error 1067: The process terminated unexpectedly.

Translation: the service process (.exe) started, then immediately crashed before it could report "running" back to the Service Control Manager. Windows saw the process exit too fast. It doesn't know why — it just knows the process didn't make it.

1067 is a symptom, not a diagnosis. You can't fix it without knowing what caused the crash — and that answer is in the logs.

Step 1: Open Event Viewer first

Event Viewer almost always has the actual error. The 1067 message is just a wrapper; the real crash reason — a missing DLL, a bad config file, a port conflict — is logged separately.

Open it:

eventvwr.msc

Check two places:

• Windows Logs → Application — errors from the service process itself
• Windows Logs → System — Service Control Manager events (source: Service Control Manager)

Filter for red "Error" events timestamped around when you tried to start the service. The description on those events — not the 1067 message — is what tells you what actually went wrong.

Common things you'll see:

• The program can't start because VCRUNTIME140.dll was not found → missing Visual C++ runtime
• Failed to open config file: C:\path\to\config.json → wrong working directory or missing file
• bind: Only one usage of each socket address is normally permitted → port already in use
• Access is denied → file or registry permission problem
• An application-specific error from your service code

Step 2: Check the service configuration

Make sure the binary path is correct and the service account looks right:

sc qc "YourServiceName"

This shows output like:

SERVICE_NAME: YourServiceName
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\path\to\service.exe --config C:\path\to\config.ini
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Your Service
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

Verify the binary actually exists at that path:

Test-Path "C:\path\to\service.exe"

False means the service was registered against a path that no longer exists — common after a reinstall or a directory move. Fix it:

sc config "YourServiceName" binpath= "C:\correct\path\to\service.exe"

The space after binpath= is required — sc syntax is finicky about that.

Step 3: Run the executable manually

Open a command prompt as Administrator and run the service binary directly:

"C:\path\to\service.exe"

Or with arguments:

"C:\path\to\service.exe" --config "C:\path\to\config.ini"

Running manually forces errors to the console instead of letting the Service Control Manager swallow them silently. A missing dependency, a bad config value, a permission problem — all of these print immediately when you run the binary yourself, rather than disappearing into a generic 1067 wrapper.

If the binary exits right away, check the exit code:

echo %errorlevel%

A negative exit code like -1073741515 (hex: 0xC0000135) is a dead giveaway for a missing DLL dependency.

Step 4: Fix the root cause

Missing DLL or runtime

Event Viewer says something like VCRUNTIME140.dll was not found? Install the right runtime:

• For VCRUNTIME140.dll or similar: install Visual C++ Redistributable
• For Java services: verify JAVA_HOME is set and the correct JRE version is installed
• For .NET services: check installed runtimes with dotnet --list-runtimes

Config file not found or invalid

Here's a trap that catches a lot of people: services don't run from their own directory. The default working directory is C:\Windows\System32. Any relative path in your config silently resolves to the wrong place.

Always use absolute paths in service configs, or pass the config location explicitly in the binary path:

sc config "YourServiceName" binpath= "\"C:\path\to\service.exe\" --config \"C:\path\to\config.ini\""

Service account permission issues

Look at SERVICE_START_NAME in the sc qc output. If it's LocalService, NetworkService, or a custom domain account rather than LocalSystem, it may not have read access to the binary directory or config files.

Check what permissions that account has:

icacls "C:\path\to\service\directory"

Grant read and execute access:

icacls "C:\path\to\service\directory" /grant "NT AUTHORITY\LocalService:(RX)" /T

If the service writes log files, it needs write access to the log directory too — otherwise it crashes the moment it tries to open a log file it can't create.

Port conflict

A service that binds port 8080 at startup crashes immediately if something else already owns that port. Find the culprit:

netstat -ano | findstr :8080

Note the PID in the last column, then look it up:

tasklist | findstr 1234

Either stop the conflicting process or change your service's port in its config file.

Step 5: Restart the service and verify

Start the service and check its state:

sc start "YourServiceName"
sc query "YourServiceName"

You want to see:

STATE              : 4  RUNNING

Or in PowerShell:

Get-Service -Name "YourServiceName" | Select-Object Name, Status, StartType

Wait 10–15 seconds, then query again. A service that crashes on startup often shows RUNNING briefly before flipping back to STOPPED. If that happens, go back to Event Viewer — new errors from that attempt will be timestamped right in that window.

Lessons learned

• Error 1067 is always a symptom. The real error is somewhere else — usually Event Viewer or a log file written by the service itself.
• Running the .exe manually as Administrator is the fastest debugging step. It surfaces errors the Service Control Manager would otherwise swallow silently.
• Relative paths in service configs are a common trap. Services don't run from their own directory — use absolute paths.
• After any Windows update or application reinstall, check that the binary path in the service config still points to a valid location. Registry entries go stale when software gets moved or upgraded.