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:
- 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
- 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) |
- 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:
- 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.
- 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:
- Create and save your monitoring script in a known location. For example, create “MonitorServices.ps1” and save it in C:\Scripts\.
- 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:
- 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.
- 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:
- 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.
- Alternatively, edit registry properties manually or using a script under:
HKLM:\SYSTEM\CurrentControlSet\Services\<ServiceName>\FailureActions
⚠️ Things to look out for
| Risks | Potential Consequences | Reversals |
| False positives from monitoring scripts |
|
|
| Disrupting critical dependencies | Restart chain reactions can break interconnected services or applications. |
|
| Security exposure from over-permissioned scripts | Attackers could exploit scripts to gain elevated control. |
|
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 capability | Description | Benefit to IT Teams/MSPs |
| Automated deployment | Distributes service watchdog scripts across endpoints, tenants, or groups |
|
| Automated remediation | Restarts services automatically when down or in a pending state |
|
| Alerting and notifications | Generates alerts when restarts are attempted, fail, or recur frequently |
|
| Endpoint tagging | Marks devices with chronic service failures for further review |
|
| Audit and compliance logging | Centralizes registry-based or script-based logs into reports |
|
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:
