/
/

How to Monitor and Restart Stuck Windows Services Automatically

by Jarod Habana, IT Technical Writer
How to Monitor and Restart Stuck Windows Services Automatically blog banner image

Windows services are programs that run processes in the background at startup. They ensure uninterrupted computing, so the system may slow down or fail when one or more services get stuck in a “Starting” or “Stopping” state or even unexpectedly stop altogether. This is where automation comes in handy, so end users don’t have to wait long for IT support.

Keep reading for various methods to automatically monitor Windows services and restart them if they get stuck, from using PowerShell and CMD scripts to using Task Scheduler and the registry.

Methods for monitoring and restarting stuck Windows services

Proactive monitoring, automated recovery, and reliable logging are crucial in keeping critical Windows services running. Check out the methods below to ensure you always have a structured approach to monitor and restart essential services.

📌 Prerequisites:

  • Windows 10/11 (for workstations)
  • Windows Server 2016 or later (for servers)
  • PowerShell 5.1 or newer
  • Local administrator privileges

💡 Tip: Read Things to look out for before proceeding.

📌 Recommended deployment strategies:

Click to Choose a Method💻

Best for Individual Users

💻💻💻

Best for Enterprises

Method 1: Identify target services to monitor
Method 2: Detect non-running or stuck services via PowerShell
Method 3: Schedule service monitoring task
Method 4: Log service recovery status in the registry
Method 5: Configure built-in service recovery actions (optional)

Method 1: Identify target services to monitor

This step defines a list of Windows services critical to system operations requiring monitoring. By focusing only on essential services, you can prevent wasted resources.

📌 Use Cases:

  • Create the list of critical services across all endpoints
  • Monitor line-of-business application services
  • Define baseline for enterprise automation policies

Steps:

  1. Establish which Windows services are essential to your environment. For example:
    • Print Spooler for printing
    • DNS Client for network resolution
    • Windows Time for domain sync
  2. Define them in a PowerShell array:
$servicesToMonitor = @(
“Spooler”,             # Print Spooler
“W32Time”,          # Windows Time
“Dnscache”,          # DNS Client
“WinRM”,             # Windows Remote Management
“BITS”                   # Background Intelligent Transfer Service)
  1. Optional: Store these names in a JSON or CSV file for easy updates without editing the script itself.

Method 2: Detect non-running or stuck services via PowerShell

This method uses PowerShell to check service health, restart non-running services, and identify services stuck in transitional states.

📌 Use Cases:

  • Auto-restart DNS Client to fix name resolution failures
  • Recover Print Spooler to restore printing services
  • Detect “Start Pending” states

📌 Prerequisites:

  • PowerShell script execution permissions
  • WMI access

Steps:

  1. Run this PowerShell script:
foreach ($svc in $servicesToMonitor) {
          $service = Get-Service -Name $svc -ErrorAction SilentlyContinue
          if ($service.Status -ne “Running”) {
          try {
          Start-Service -Name $svc -ErrorAction Stop
          Write-Output “$svc restarted successfully.”
          } catch {
         Write-Output “Failed to start $svc. Error: $_”
          }
          }}

This lists Windows services using PowerShell and gets their current state. If it detects that a service is not running, it tries to start it. Then, it logs either a success or a failure message.

  1. Run this WMI script in PowerShell:
$stuck = Get-WmiObject -Class Win32_Service | Where-Object { $_.State -in @(“Start Pending”, “Stop Pending”) }

This uses WMI to query all Windows services and filters for ones in a pending state, either “Start Pending” or “Stop Pending.” It then saves those services into the $stuck variable, so you can inspect them or take action, such as force stop, restart, and alert, later.

Method 3: Schedule service monitoring task

This method automates script execution at specific intervals using Windows Task Scheduler, eliminating the need for manual execution. This ensures services are checked continuously.

📌 Use Cases:

  • Run checks every few minutes on critical servers
  • Automate self-healing on endpoints without RMM
  • Ensure service uptime during off-hours and weekends

📌 Prerequisites:

  • Task Scheduler access
  • SYSTEM or service account context

Steps:

  1. Create and save your monitoring script in a known location. For example, create “MonitorServices.ps1” and save it in C:\Scripts\.
  2. Using PowerShell, create a scheduled task to run every few minutes. In this example, it runs every 5 minutes:
schtasks /create /tn “MonitorCriticalServices” /tr “powershell.exe -File C:\Scripts\MonitorServices.ps1” /sc minute /mo 5 /ru SYSTEM

⚠️ Important: Ensure that script execution is allowed.

Method 4: Log service recovery status in the registry

This method creates an audit trail by writing restart events into the Windows Registry, which provides a lightweight logging mechanism for audits or RMM collection.

📌 Use Cases:

  • Maintain a local audit trail of recovery actions
  • Track chronic failures for root cause analysis

📌 Prerequisite: Registry write permissions

Steps:

  1. Run this PowerShell script:
New-Item -Path “HKLM:\SOFTWARE\Org\ServiceRecovery” -Force

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\ServiceRecovery” -Name “LastCheck” -Value (Get-Date).ToString(“u”)

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\ServiceRecovery” -Name “LastRestarted” -Value $svc

This creates a new registry path with keys where it logs the last check time and service restart.

  1. Validate the new entries using CMD:

reg query HKLM\SOFTWARE\Org\ServiceRecovery

Method 5: Configure built-in service recovery actions (optional)

This last method uses Windows’ built-in failure recovery options to restart services after crashes.

💡 Note: This is best used for crash scenarios (unexpectedly terminated services), not stuck states (stuck or unresponsive services).

📌 Use Cases:

  • Auto-restart services like BITS and W32Time after crashes
  • Standardize recovery behavior via GPO across endpoints
  • Minimize downtime for services prone to intermittent failures

📌 Prerequisites:

  • Administrator access (for sc.exe or the Registry Editor)
  • Service must support recovery

Steps:

  1. Configure service recovery via command line:

sc failure “Spooler” reset= 86400 actions= restart/60000/restart/60000/””/0

This sample script sets up automatic recovery actions for Print Spooler. The service restarts after 1 minute for the first two crashes, but if it fails a third time, no recovery action is taken. After 24 hours, the failure counter resets.

  1. Alternatively, edit registry properties manually or using a script under:

HKLM:\SYSTEM\CurrentControlSet\Services\<ServiceName>\FailureActions

⚠️ Things to look out for

RisksPotential ConsequencesReversals
False positives from monitoring scripts
  • Unnecessary restarts
  • Service disruption
  • User impact
  • Degraded performance
  • Add validation checks, such as confirming service state twice before restarting.
  • Test scripts in non-production environments first.
Disrupting critical dependenciesRestart chain reactions can break interconnected services or applications.
  • Build dependency map.
  • If disrupted, restart dependent services in the correct order or roll back to the last known stable state.
Security exposure from over-permissioned scriptsAttackers could exploit scripts to gain elevated control.
  • Restrict script permissions.
  • Use code signing.
  • Deploy least-privilege principles.
  • Revoke compromised credentials immediately if exploited.

Why service monitoring and automated recovery matter

Windows services are like the backbone of many system functions and applications. When they fail, stall, or stop unexpectedly, users may be unable to use their computers, resulting in wasted time, decreased performance, and increased support requests. Properly monitoring services and recovering from issues can:

  • Increase endpoint and server availability: By preventing disruptions, servers remain online and users stay productive, especially when uptime is critical.
  • Reduce in support tickets and reactive work: Automated recovery resolves common service failures before users notice them, removing the need to submit help desk requests.
  • Prevent cascading failures from dependent services: Many Windows services rely on other services to function correctly. If you can restart failing services before they affect those that depend on them to work, you can stabilize the system and prevent it from spreading across applications or the system.
  • Enable SLA-backed service health guarantees: For MSPs, uptime and service reliability are tied directly to Service Level Agreements (SLAs). Automating recovery of critical Windows services should help MSPs meet contractual obligations, reduce penalties, and build client trust.

Additional considerations when automating Windows service monitoring and recovery

Here are a few considerations highlighting some best practices to follow and potential pitfalls to address before deploying these automation strategies across production environments.

Service dependencies

Restarting one Windows service without accounting for its dependencies may cause system instability or cascading failures. Always validate service dependencies before restarting using scripts like:

Get-Service -Name X | Select-Object DependentServices

Then, restart dependent services in the proper order if needed.

Notifications and alerts

IT staff should be aware of recurring failures, as silent restarts and recoveries can mask underlying problems. To enable visibility, it’s best to configure scripts to send email, webhook, or RMM-based alerts whenever a service is restarted or fails to restart.

Credentialed services

Some services run under custom accounts, and if the password expires or is changed without updating the service, restart attempts will fail. Monitor for credential expiration and maintain proper password rotation procedures. Test automated restarts on credentialed services during maintenance windows.

Script efficiency and reliability

Including timeout logic, retries, and error handling in your scripts is good practice to prevent lockups on unresponsive services. This ensures scripts exit gracefully and log failures.

Troubleshooting common issues

Service fails to restart

It may be that the service account does not have sufficient permissions, or the service depends on another service that is stopped or unhealthy. Verify the service account and its password status, then reset it if it’s expired. You may also check dependencies with this command:

Get-Service -Name X | Select-Object DependentServices

Script not executing

The scheduled task might not be running under an account with sufficient privileges. Consider verifying the scheduled task credentials and context (SYSTEM or Administrator). The file path or script location might also have changed, so check if the script path is still accurate.

Registry not updating

The script might lack write access to HKLM or be running under a user context with only HKCU access. Make sure to run your script as an Administrator or SYSTEM.

Stuck in “Pending” state

A hung process might lock the service during startup or shutdown. Resource bottlenecks (CPU, RAM, or disk I/O) may also prevent completion. Use Get-WmiObject Win32_Service to detect services stuck in Start Pending or Stop Pending, then kill associated processes manually if it is safe to do so.

NinjaOne services that can enhance the monitoring of Windows services

The tools mentioned above are all good ways to monitor and recover Windows services on individual endpoints. However, for MSPs and IT teams, taking advantage of platforms that may help them offer better services is always beneficial. Here’s how NinjaOne can help:

NinjaOne capabilityDescriptionBenefit to IT Teams/MSPs
Automated deploymentDistributes service watchdog scripts across endpoints, tenants, or groups
  • Saves time
  • Ensures consistency across multiple clients
Automated remediationRestarts services automatically when down or in a pending state
  • Reduces downtime
  • Prevents user impact before issues escalate
Alerting and notificationsGenerates alerts when restarts are attempted, fail, or recur frequently
  • Improves visibility
  • Enables faster escalation if automation fails
Endpoint taggingMarks devices with chronic service failures for further review
  • Helps identify recurring problems
  • Supports proactive root cause analysis
Audit and compliance loggingCentralizes registry-based or script-based logs into reports
  • Demonstrates SLA compliance
  • Simplifies incident reviews

Scaling service recovery across environments

When Windows services are stopping or are stuck, the system can slow down or even become unstable. Therefore, automated monitoring and recovery should help MSPs reduce downtime and maintain client trust. From checking running Windows services using PowerShell to modifying the registry for auditing, you have multiple ways to build reliable self-healing mechanisms that minimize disruptions. Always remember the mentioned considerations and troubleshooting steps to ensure proactive operations.

Related topics:

You might also like

Ready to simplify the hardest parts of IT?