Windows Command #44 – sc failureflag (Windows OS)

Realistic colored-pencil illustration of Black and Asian IT professionals configuring Windows service failure actions at a server-room workstation.

sc.exe failureflag controls whether a Windows service’s configured recovery actions also run for non-crash failures. It follows directly from Windows Command #43 – sc failure, which defines the recovery actions themselves.

What failureflag changes

Windows stores this setting as the service’s failure-actions flag. Microsoft documents that when the flag is enabled and failure actions are already configured, those actions can be queued not only when the service process terminates without reporting SERVICE_STOPPED, but also when the service reports SERVICE_STOPPED with a nonzero Win32 exit code. If the flag is disabled, configured recovery actions are limited to the crash-style case where the service terminates without reporting SERVICE_STOPPED.

The flag is ignored unless the service already has recovery actions configured. That is why sc failureflag belongs immediately after the previous lesson on sc failure.

Read the current value first

Use sc.exe qfailureflag SERVICE_NAME from an elevated Command Prompt to inspect the current setting before making any changes. Replace SERVICE_NAME with the actual service name, not the display name.

For example, on a disposable test service named DemoService, run sc.exe qfailureflag DemoService. Record the original value so you can restore it after testing.

This overview explains the Windows Service Control Manager, the subsystem that sc.exe queries and modifies.

Enable recovery actions for non-crash failures

For a test service you administer, the command is sc.exe failureflag DemoService flag= 1. The space after the equals sign is significant in sc.exe option syntax. A value of 1 enables failure actions on qualifying non-crash failures.

To disable that behavior, use sc.exe failureflag DemoService flag= 0. Then verify the result with sc.exe qfailureflag DemoService.

What counts as a non-crash failure?

A service can stop in an orderly way yet still report an error. When the failure-actions flag is enabled, a transition to SERVICE_STOPPED with a dwWin32ExitCode other than ERROR_SUCCESS can trigger the configured recovery actions. Microsoft also notes that the setting takes effect the next time the system starts.

That distinction matters because a service can fail without an abrupt process crash. A controlled shutdown path might detect an unrecoverable condition, report an error status, and stop. With the flag enabled, Windows can still treat that event as eligible for the restart, command, or reboot actions configured in the previous lesson.

Do not enable it blindly

  • Confirm the service already has sensible failure actions with sc.exe qfailure SERVICE_NAME.
  • Use a disposable or noncritical test service when learning the command.
  • A repeated automatic restart can hide a persistent application fault and create a restart loop.
  • Review Event Viewer and application logs instead of treating recovery settings as root-cause repair.
  • Record the original value before changing it.

Practice lab

  1. Choose a noncritical test service that you are authorized to administer.
  2. Run sc.exe qfailure SERVICE_NAME and confirm that recovery actions exist.
  3. Run sc.exe qfailureflag SERVICE_NAME and record the original flag.
  4. Enable the flag with sc.exe failureflag SERVICE_NAME flag= 1.
  5. Verify the setting with sc.exe qfailureflag SERVICE_NAME.
  6. Restore the original flag after the exercise.

Knowledge check

  1. What does sc.exe failureflag control?
  2. Which command reads the current flag?
  3. What does flag= 1 enable?
  4. Does the flag create recovery actions by itself?
  5. Why should you inspect the existing recovery policy before enabling it?

Answer guide

  1. It controls whether configured service failure actions can also run for qualifying non-crash failures.
  2. sc.exe qfailureflag SERVICE_NAME.
  3. It enables failure actions when the service reports a stopped state with a non-success Win32 exit code, in addition to crash-style termination.
  4. No. Recovery actions must already be configured separately, such as with sc.exe failure.
  5. Because enabling the flag can cause additional restart, command, or reboot actions to run when the service fails.

Further reading

Microsoft’s Configuring a Service Using SC lists failureflag and qfailureflag among the supported Service Control configuration commands. The SERVICE_FAILURE_ACTIONS_FLAG documentation explains the exact conditions under which the flag changes recovery behavior.


Advertisement

Follow BitcoinVersus.Tech for independent technology reporting and open-source technical education.

BitcoinVersus.Tech Editor’s Note:

We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate here: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb

BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.

Leave a Reply