Fix ERROR_NO_RECOVERY_PROGRAM (0x0000043A) in Windows Services

I've seen this error pop up on Windows Server machines more often than you'd think—usually right after a service crashes and the Service Control Manager tries to restart it but finds nothing configured. The error message "No recovery program has been configured for this service" is misleading: it's not about a missing EXE, it's about the failure action being set to 'Take No Action' or completely blank.

The fix: Set a recovery action

You've got two ways to do this. The command line is faster, but the GUI works if you're not comfortable with sc.

Method 1: Using sc failure (recommended)

1. Open Command Prompt as Administrator.
2. Run sc query servicename to confirm the service name. If you don't know it, use sc query to list all services.
3. Then run:

   sc failure servicename reset=86400 actions=restart/5000/restart/10000/restart/30000

4. Replace servicename with your actual service name (e.g., Spooler, W3SVC, MSSQLSERVER). The reset=86400 means the failure count resets after one day. The three actions are: first failure restart after 5 seconds, second failure restart after 10 seconds, subsequent failures restart after 30 seconds.
5. Run sc failure servicename again to verify it now shows a configured action.

Method 2: Via Services.msc

1. Press Win+R, type services.msc, hit Enter.
2. Find your service, right-click, choose Properties.
3. Go to the Recovery tab.
4. For First failure, Second failure, and Subsequent failures, select "Restart the Service" from the dropdown.
5. Set the "Reset fail count after" field to 1 (or 86400 seconds—same thing).
6. Click Apply, then OK.

That's it. The error should stop appearing the next time the service crashes.

Why this works

What's actually happening here is that Windows Service Control Manager (SCM) has a mandatory check before restarting a service after a crash. The SCM reads the service's failure actions from the registry at HKLM\SYSTEM\CurrentControlSet\Services\servicename\FailureActions. If that registry key is missing or contains only a zero-length binary blob (which happens when no action is set), SCM throws ERROR_NO_RECOVERY_PROGRAM and doesn't restart the service at all.

Setting an action via sc failure or the GUI creates that registry key with proper binary data that SCM can parse. The key contains an array of SC_ACTION structures (each specifying an action type like SC_ACTION_RESTART and a delay in milliseconds), plus a reset period. Without this data, SCM has no instructions—so it generates error 0x0000043A and logs event ID 7031 or 7034 in the System log.

The reason you need to set all three failure actions even if you only expect one crash is that SCM reads the entire failure array in order. If you leave subsequent failures unset, they default to 'Take No Action', which means the third crash in your reset period will kill the service permanently. Don't do that.

Less common variations

Service won't accept the sc failure command

Some services—especially Microsoft Exchange, SQL Server Agent, and third-party services that manage their own recovery—protect their recovery configuration. You'll get "Access denied" or "The specified service does not support this command." In that case, check if the service has its own recovery settings in its config file (e.g., SQL Server Agent uses SQL Agent properties). If it's a custom service, the developer might have hardcoded SCM failure actions during installation. You can verify with sc qfailure servicename—if it returns nothing, the service was registered without failure actions, and SCM won't let you add them because the service's main executable already handles restart internally.

Error persists after setting recovery

This usually means the service is crashing before SCM can read the failure actions. Check Event Viewer → Windows Logs → System for event ID 7034 (service terminated unexpectedly). If you see a 7034 followed immediately by this error, the service is crashing so fast that SCM hasn't had time to apply the new recovery settings. Stop the service manually (net stop servicename), then start it again (net start servicename). That forces SCM to reload the registry key. If it still crashes, the underlying issue isn't recovery—it's a bug in the service itself.

Using a scheduled task as recovery program

You can configure SCM to run a script or program on failure instead of restarting the service. Set the failure action to "Run a Program" and point it to a batch file or PowerShell script. But note: SCM runs the recovery program in the SYSTEM account context, not the service's account. If your script needs network access or specific permissions, test it first. Also, don't use this for critical services—SCM will wait for the recovery program to exit before attempting the next action in the list. If your script hangs, the service stays dead.

Prevention

When you install a new service—via sc create or the InstallUtil tool—always set failure actions right away. Don't assume the default is good. The default on Windows is 'Take No Action' for all three failure conditions, which guarantees this error if the service ever crashes. Run a post-install script that does:

sc failure newservicename reset=86400 actions=restart/5000/restart/10000/restart/30000

If you manage services through Group Policy, you can deploy failure actions via a startup script or using Group Policy Preferences to set registry values under HKLM\SYSTEM\CurrentControlSet\Services\servicename\FailureActions. But beware: if your service is already running, GP won't apply until the next reboot or service restart.

For services you develop yourself, set failure actions during installation using the ChangeServiceConfig2 API with SERVICE_CONFIG_FAILURE_ACTIONS. Never leave the failure actions null—that's what triggers this error. Even if you think your service never crashes, set a restart action anyway. You'll save yourself a support call at 3 AM.