Fun With Task Scheduler
Published on May 9, 2017 by Staff Writer
Windows Server is a complex and powerful server operating system. It can respond to thousands of simultaneous requests, while issuing a few thousand of its own, in under a second. An administrator needs to provide it with the requisite CPU, memory and disk and bandwidth to handle all of this traffic. Nonetheless, Windows will handle an amazing load when asked.
Windows’ capacity to withstand stress is derived from how engineers have designed its process model. Windows can participate in many discrete conversations and transactions because each process operates in its own memory space and allocated CPU time. If a process crashes or terminates, it will only contaminate its own allotment of resources, without affecting other processes. This isn’t flawless, however, as the rare crash will lead to total system failure.
If you run a shop long enough, you will encounter one of these crash-prone, flaky processes. They likely fall into one of the following categories:
- A Service built for a version of Windows which is older than the version it’s running on
- A Service that was built by an non-reputable vendor
- A pre-production release of software
- Something you built, but can’t fix
- You’re using a service for purposes other than what the developer intended
If you’re in a position where it’s imperative to keep one of these running, you need to monitor the service and periodically restart it. Fortunately, Windows also provides a means of recovery for failures, via the Services MMC. You can configure the service to restart itself, run another program or restart the server. Simply configuring a service to restart itself will work 99% of the time (based on anecdotal evidence and best-guessing). Depending on how the engineers designed a service, there may be extenuating circumstances which prevent a service from restarting immediately or even minutes later.
I have two services that behave this way. They crash all the time, won’t restart by themselves, I can’t fix them, but they need to stay running. I’m stuck limping them along to a seemingly never-approaching finish line. My work-around is to run a Scheduled task that monitors their status every 15 minutes. If the services have stopped, it will attempt to start them. After 1 year, this shade-tree approach seems to work well.
Create the Script
The batch file below executes the Service Control command to query the system for a specific process, in this case “Flaky Service”. It exports the result of that command to a text file. If the text file does not contain the string “RUNNING”, it will attempt to start the service. I’ve set up a Scheduled Task to run this batch file every 15 minutes.
sc.exe \\localhost query “Flaky Service” > ServiceCheck.txt
Find /i “RUNNING” < ServiceCheck.txt
IF NOT %ErrorLevel% == 0 (
Echo NOT Running
sc.exe \\localhost start “Flaky Service”
) ELSE (
Echo IS Running
For a quick demonstration, view our YouTube video here
- POSTED IN: