Fix Gateway Service Errors on Windows

This page covers Gateway runtime failures. If you're stuck at npm install, see Windows npm Install Errors instead.

OpenClaw Gateway on Windows runs as a Windows Scheduled Task. When it crashes, the task shows Last Result: 1 in Task Scheduler, a zombie node.exe process holds port 18789, and the Gateway refuses to restart until you manually clean up.

Jump to Your Problem

Zombie process on port 18789 Gateway crash loop (schtasks) Token mismatch after crash Port blast radius (18789–18792) Post-update instability Complete recovery script

Zombie Process on Port 18789

The #1 Hidden Killer on Windows

A crashed node.exe process holds port 18789 after a crash. The new Gateway can't bind the port, and clients connect to the dead process (which has the old token), causing permanent auth failures and "stale" behavior.

Symptoms

Gateway shows "Stopped" but something still listens on port 18789
Token mismatch errors despite correct config
Old model being used even after config changes
Gateway refuses to start with "address already in use"

Diagnose

Find zombie process

netstat -ano | findstr :18789

# Output example:
# TCP  0.0.0.0:18789  0.0.0.0:0  LISTENING  9800
#                                             ^^^^
#                                             This is the PID to kill

Fix: Kill the Zombie

Kill zombie & restart

# Replace 9800 with the PID from netstat output
taskkill /PID 9800 /F

# Verify the port is now free
netstat -ano | findstr :18789
# (Should return nothing)

# Start the Gateway cleanly
openclaw gateway start

Common Syntax Mistake

Do NOT use taskkill /PID <9800> /F — the angle brackets cause a syntax error. Use the bare number: taskkill /PID 9800 /F

Gateway Crash Loop (Scheduled Task)

The Windows Scheduled Task for OpenClaw Gateway is stuck: schtasks shows Last Result: 1 and status "Ready" (not "Running"). CLI commands fail with:

Error: gateway closed (1006 abnormal closure)

Diagnosis Steps

Check if a zombie foreground process from a manual gateway.cmd run is holding port 18789 (see above)
Check if the Scheduled Task points to a stale path after an update
Check the Gateway log for the actual crash reason

Crash loop recovery

# 1. Rotate log to get a fresh one
Rename-Item C:\tmp\openclaw\current.log C:\tmp\openclaw\old.log -Force

# 2. Kill any zombie processes
netstat -ano | findstr :18789
taskkill /PID <PID> /F

# 3. Force reinstall and restart the service
openclaw gateway install --force
openclaw gateway restart

# 4. Check the fresh log
type C:\tmp\openclaw\current.log

WSL2 Recommended for Stability

Native Windows support is considered unstable by the OpenClaw team. If you experience recurring crash loops, consider running OpenClaw inside WSL2 for a more reliable experience.

Token Mismatch After Gateway Crash

disconnected (1008): unauthorized: device token mismatch

After a zombie or crash, connected clients still hold the old device token. Three causes:

1. Zombie process (most common)

An old Gateway instance is still running. Kill it first (see above), then restart.

2. Stale browser token

The Control UI cached an old device token. Open the dashboard in an Incognito/Private window to force a fresh handshake.

3. Break-glass settings left on

If you enabled insecure auth settings for debugging, they may now interfere. Disable them:

Disable break-glass auth

openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth false
openclaw gateway restart

For the full token mismatch guide, see Fix Device Token Mismatch.

Port Blast Radius (18789–18792)

OpenClaw uses multiple derived ports from a single base port. A zombie on any of these blocks Gateway operation:

Port	Service	Default
Base	Gateway WebSocket + HTTP	18789
Base + 2	Browser Control	18791
Base + 3	Relay	18792

Check all Gateway ports

netstat -ano | findstr "18789 18791 18792"

# Kill any zombie on a specific port (replace PID)
taskkill /PID <PID> /F

Post-Update Instability

After updating OpenClaw, the Gateway crashes immediately or exec commands fail. This happens when the Windows Scheduled Task uses a different config or Node.js path than your CLI after the update.

Post-update sync

# Sync the Scheduled Task to the new install
openclaw gateway install --force
openclaw gateway restart

Complete Recovery Script

Run this sequence to fully reset a crashed or stuck Gateway:

Full Windows Gateway recovery

# 1. Kill all zombie processes on Gateway ports
FOR /F "tokens=5" %P IN ('netstat -ano ^| findstr "18789 18791 18792"') DO taskkill /PID %P /F

# 2. Rotate logs (PowerShell)
Rename-Item C:\tmp\openclaw\current.log C:\tmp\openclaw\old.log -Force

# 3. Force reinstall Scheduled Task
openclaw gateway install --force

# 4. Start clean
openclaw gateway restart

# 5. Verify
openclaw gateway status

Fix It Faster With Our Tools

Config Wizard

Generate a production-ready clawhub.json in 30 seconds.

Local Doctor

Diagnose Node.js, permissions, and config issues instantly.

Cost Simulator

Calculate your agent burn rate before you get surprised.

Did this guide solve your problem?