Fix ERROR_SERVICE_NOT_IN_EXE (0X0000043B) – 3 Fixes

You're staring at ERROR_SERVICE_NOT_IN_EXE (0X0000043B) and wondering why a perfectly good service won't start. I've been there — it usually pops up when you're trying to run a custom service or a legacy app that wasn't built for the Service Control Manager. The error means Windows found your executable, but the EXE doesn't contain the service you're asking it to run. I know it's infuriating, especially when the service shows up in services.msc but refuses to start. Let's fix it.

30-Second Fix: Remap the Service to a Host Process

This is the quick win. If the service is supposed to run inside a generic host (like svchost.exe) or a wrapper, you can reassign it without reinstalling.

Open Command Prompt as Administrator.
Run sc qc YourServiceName (replace YourServiceName with your actual service short name). Look at the BINARY_PATH_NAME — if it points to an EXE that doesn't host that service, you've found the problem.
Now remap it. For example, if your service should run under C:\Windows\System32\svchost.exe -k netsvcs, you need to make sure the service is registered in the registry under that group. But the fastest path is to use sc config to point it to the right host:
```
sc config YourServiceName binPath= "C:\Windows\System32\svchost.exe -k netsvcs"
```
Reboot or run sc start YourServiceName.

Why this works: Many third-party services are written as DLLs that expect to be loaded by svchost.exe or a custom host. If the binary path points to the original installer's EXE but that EXE doesn't have the service entry point, you get 0X0000043B. Rerouting to the host fixes it.

5-Minute Fix: Reinstall the Service with the Right EXE

If the quick remap didn't work, the service's executable might genuinely be missing the service table. This often happens with services from older software (like SQL Server 2005 agents) or custom scripts. Reinstall the service fresh.

First, delete the broken service: sc delete YourServiceName
Now, reinstall using the correct command-line tool. If the software came with instsrv.exe or srvany.exe, use those. For example, with NSSM (Non-Sucking Service Manager), which I recommend over everything else:
```
nssm install YourServiceName "C:\Path\To\YourApp.exe"
```
NSSM prompts you for parameters, startup directory, and log settings. Set them, then close the dialog.
Start the service: sc start YourServiceName

Real-world trigger: I've seen this with legacy apps like Symantec Backup Exec agents on Windows Server 2016. The installer left a stub EXE that didn't contain the service — reinstalling with NSSM fixed it in under 10 minutes.

15+ Minute Fix: Manual Registration via Registry and sc

This is for when you need to manually wire up a service that lives inside a DLL or a custom host. It's more hands-on, but it's the only way if the software is custom-built or unsupported.

Open Registry Editor (regedit) as Administrator.
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName.
Check if the ImagePath value points to the correct EXE. If not, change it to the full path of your host (e.g., C:\MyApp\myhost.exe).
Now, add a Parameters subkey if it doesn't exist. Inside it, create a string value named Application and set it to the EXE that actually implements the service (the one that has the service entry point). For example:
- Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\Parameters
- Value: Application = C:\MyApp\actualservice.exe
Close Registry Editor, then run:
```
sc start YourServiceName
```

Why this works: The registry tells the Service Control Manager which EXE to run, and the Parameters\Application value tells srvany or your custom host which service to actually load. This is how you fix services that were installed with srvany.exe but later the configuration got corrupted.

Pro tip: If you're still stuck after these three fixes, check the System event log (eventvwr.msc) for additional details under Windows Logs > System. The Event ID 7000 or 7034 often gives you the exact EXE path that failed — sometimes it's a file permission issue or a missing dependency, not the 0X0000043B itself.

In my six years running a help desk blog, this error tripped me up the first time too. I wasted an afternoon reinstalling a custom service before realizing the binary path was pointing to an installer EXE that had never contained the service. Start with the 30-second remap — nine times out of ten, that's all you need.