The Core Technologies Blog |
Professional Software for Windows Services / 24×7 Operation
Posted on October 14, 2022 (Revised November 7, 2022) Service Protector 8.5 is now available for download. Here’s what we worked on in this new version: Automatically restart your service when an important application isn’t runningDoes your service depend on an important “helper” application? If so, Service Protector can periodically check if the helper application is running and restart your service if the application isn’t active. For example, suppose you’re protecting a service that spins off a Java process to perform important image processing. You can now instruct Service Protector to restart your service if no java.exe process is running on your server. In that way, you’re protected if the supporting java process crashes or stops for any reason. You can activate the new sanity check from the Monitor tab. Start by checking the Whenever it fails a periodic sanity check box: Click the Set button to open the Add Sanity Check window. From there, select Check that an application is running from the list: In the next screen, enter the name of the executable to watch for. The name must end in .exe. For example, to watch for a Java process, enter “java.exe”: If you don’t know the name of the application’s executable file, run the application and find its entry on the Task Manager’s Details tab. The name will appear in the first column. After entering the executable name, continue on to the next pages to specify how often Service Protector should check for the application. When done, save your changes. And that’s it! With the sanity check in place, you can rest assured that your helper application’s “untimely demise” will trigger Service Protector to recycle your service. The “Check file updated” sanity check now supports date variablesWe’ve made several improvements to the sanity check that restarts the service whenever an important file hasn’t been updated in a while. Most notably, date variables can be used in the name of the file to monitor. This feature is beneficial when checking a log file that “rolls over” each day. Previous releases of Service Protector — which only supported a fixed file name — could not handle a dynamic name. For example, let’s take the case where your service writes to a new log file each day. The file name contains the date, in the format “myserver-DD-MM-YYYY.log”. To monitor that log file with the sanity check, you would specify the file name as myserver-$DAY2$-$MONTH2%-$YEAR4$.log: And with that in place, when running your service on October 14 2022, Service Protector would check for a file named “myserver-14-10-2022.log”. Service Protector is fully compatible with Windows 10 & 11 22H2As usual, Microsoft continues to roll out twice-yearly updates to its Windows operating systems. Windows 10 22H2 will be released to the public in a few days. However, as a member of the Windows Insider program, we’ve been playing with that new version since August. Similarly, Windows 11 22H2 started rolling out to customers in September. And like Windows 10 22H2, we’ve been evaluating it for over a month now. Our assessment? Service Protector continues to work flawlessly with both operating systems. In some sense, that is to be expected as Microsoft has left the Windows Services layer untouched. Other fixes & improvementsFixed a crash when testing a custom sanity check: Thanks to Jacques Dagousset for reporting the problem, which would occur in rare circumstances. Reduced CPU load when scanning for crash dialogs: With recent changes, Service Protector is significantly more efficient when scanning for dialogs that indicate that your service has crashed. Improved logging when running a sanity check: Extra messages provide insight when testing a sanity check (and when debugging subtle problems).
As usual, please review the release notes for the full list of features, fixes and improvements included in Service Protector version 8.5. Upgrading to Service Protector 8.5If you purchased Service Protector version 7 (after January 2021), you can upgrade to version 8.5 for free. Simply download and install over your existing installation to preserve your existing services and all settings. For instance, your registration code will continue to work. If you bought Service Protector version 6 or earlier (before January 2021), you will need to upgrade to use version 8.5. Please buy upgrades here — at a 50% discount. See the complete upgrade policy for more details. Enjoy!
Posted on September 26, 2022  I’ve got a Windows Service that keeps starting by itself. Why is that happening? I’m pulling my hair out trying to figure out why… — Colin P. Hi Colin. There may be several culprits here. Let’s go through a few. 1. Your service is required by another serviceDoes your Windows Service support any other services? Is another service “dependent” on yours? If so, then starting that other service may start yours too. This can be a bit confusing so let’s illustrate with an example. Here we have a service called “Dropbox (managed by AlwaysUpService)” — created with our AlwaysUp product: We made the Dropbox service dependent on the “Fax” service. Indeed, you can see the relationship on the Dependencies tab: It’s important to note that the dependency stipulates the following situation: The Fax service must be running before the Dropbox service can start
To test the implications of that relationship, we: Stopped both the Dropbox and Fax services, and Started the Dropbox service.
Afterwards, we saw that the Fax service was running: Apparently when we started the Dropbox service, Windows realized that the Fax service was needed and quietly started Fax as well. So that’s one way for a service to start inadvertently. With that example in mind, please check if another service depends on your service. If so, Windows may be starting your service because of that dependency relationship. 2. Your service is “trigger started” by WindowsLegacy versions of Windows presented a couple of options for when a service was started: Automatically — by Windows — when your computer booted; Manually — by a person or application — when needed.
Windows Vista (2007) introduced a third option: Trigger start. Now, services can be started in response to key operating system events. And the set of triggering events is varied. For example, a trigger start service can be launched whenever: Someone plugs in a USB drive; Your computer joins a domain; A network port is opened; A custom event (or system state change) occurs.
Trigger start services reveal themselves in the Startup type column of the Services application. As you can see in this screenshot, there are quite a few on our Server 2022 machine: This article explains the difference between “Automatic (Trigger Start)” and “Manual (Trigger Start)”. Is your service configured to trigger start? If so, it may be starting when its associated event fires. You can use our free Service Trigger Editor utility to investigate the service and the events that trigger it. Removing the trigger may be an effective solution but please be sure to understand the consequences of doing so! 3. Someone is starting your service manuallyI don’t know what your service does, but might someone else be starting it to get their work done? You want the service to be idle but perhaps a colleague needs it running! Is someone else with access to your machine launching the service? Best to check around and find out. 4. An application running on your PC is starting the serviceSome folks say that applications are people, too. 🙂 Well, maybe not, but a program can certainly stop and start a Windows Service — just like a person can. For example, an application that supports Bluetooth may fire up the Bluetooth Support Service if it’s not running. Indeed, the application likely calls the Windows API (the ControlService function) instead of using the NET or SC commands, but the effect will be the same. So do you know of a program that needs your service to operate? If so, you should consider uninstalling the application. Our recommendation: Investigate with Windows Service AuditorIf you can’t figure out who (or what) is starting your Windows Service, it’s time to get your detective hat on. Start with the Windows Event Viewer. Do you see the service starting and stopping? Can you tell who’s doing it? Pay attention to the times as they could shed light on the situation. But if you’re still in the dark, we recommend bringing out the big gun: our free Windows Service Auditor. Windows Service Auditor introduces extra logging, to shine a bright light on your Windows Service. For example, here it’s telling us that “Mike Jones” updated the “Windows Update” service today at 10:59 AM: Hopefully you’ll solve the mystery soon. Good luck!
Posted on September 12, 2022 Hello, I’m hoping you can help me troubleshoot some issues we are experiencing with AlwaysUp. We are currently using version 12.9.0.46. A user reported that something wasn’t working correctly with the application we’re running as a service. Upon investigating the issue, I noticed that AlwaysUp doesn’t appear to be writing any logs to the event viewer as stated on this page. I thought I was maybe just missing any messages, so I stopped and restarted the service after about 1 minute. However, this also didn’t write anything to the Application Logs in Event Viewer. Could you assist me in sorting out the reporting please? — Lewis Hi Lewis. Let’s dig into your situation. Which account runs your application as a Windows Service?Do you have a user specified on the Logon tab in AlwaysUp? That’s the account where your application will run. For example, this screenshot shows OneDrive configured to run as a service in the “Mike Jones” account: When we start OneDrive in AlwaysUp, the executable runs as “Mike Jones”: And as Process Explorer shows, even AlwaysUpService.exe — the headless application that runs your application as a service in the background — operates as the same user: Note that most Windows Services run in the LocalSystem account — a predefined local account used by the Service Control Manager. Indeed, AlwaysUp will run your application as LocalSystem unless you override it by providing an alternate account. But running in a “regular” user account is often the best choice when installing an application as a service. That’s because most desktop applications are tied to the account where they were installed. Starting them in an account where they were not installed (and cannot find settings saved during installation and configuration) usually ends in failure. That account must have permission to create event logsAs illustrated above, the service that AlwaysUp creates runs entirely in the context of the account specified on the Logon tab. In your set up, the account doesn’t appear to have the necessary permissions to write to the event logs. That’s why you’re not seeing any records from AlwaysUp. Test the account’s event log permissions with PowerShellYou can test this theory by running the following PowerShell command from the user’s account: Write-EventLog -LogName Application -Source "APPNAME (managed by AlwaysUpService)" -EntryType Information -EventID 0 -Message "This event was created while testing with PowerShell. Please ignore." Please replace APPNAME with the name of your application in AlwaysUp. Essentially, the Write-EventLog command simulates how AlwaysUp works. If Write-EventLog fails, then AlwaysUp will fail too. Here is the result of running the command from the “Mike Jones” account for our OneDrive service. Write-EventLog succeeded: And a new event showed up in the Application log: So everything looked good for Mike. How to enable event logging from your AlwaysUp serviceYou can fix the permission problem in one of three ways: Grant the user administrative rights. As an admin, they will definitely be able to write to the event logs. This may be your easiest way forward. Leave the user as a non-admin but grant the account specific rights to the Application event log. Depending on where the issue is, you may have to update the registry and perform other administrative surgery. These links offer guidance: Enter a different user with administrative rights on the AlwaysUp Logon tab. That account shouldn’t have any problems creating records in any event logs.
Hope this helps!
Posted on August 29, 2022 1. Export to CSV or tabbed text with the Services applicationPerhaps the easiest way to export your services is with the built-in Windows Services application — services.msc. To export, simply: Start Services. Click the Start button, type services.msc in the search field and hit return. From the Action menu, select Export List: Choose the format (tab delimited text or CSV), enter a file name and click Save to create the file.
Your file will contain the following five columns of data, which you cannot customize: Name (Note: This is the service’s display name, not its unique name used by Windows) Description Status Startup Type Log On As
If that’s all you need then you’re good to go! 2. Export to CSV or XML with PowerShellEven though it’s easy to do, exporting with the Services application may not provide all the information you would like to capture. For example, the service name is not included and neither is the command line used to start the service. If you’d like more columns, then PowerShell is another option. For example, this command lists all the services on your machine: Get-CIMInstance -Class Win32_Service | Select-Object Name, DisplayName, Description, StartMode, DelayedAutoStart, StartName, PathName, State, ProcessId
The output looks like this: Note that you can add or remove properties from the Select-Object section as you see fit. Feel free to include any property listed in the Win32_Service class documentation. And once you’ve settled on a command that prints the necessary information, call the Export-CSV module at the end to send the results to a file. For example, this command exports the list of services to “C:\output-file.csv”: Get-CIMInstance -Class Win32_Service | Select-Object Name, DisplayName, Description, StartMode, DelayedAutoStart, StartName, PathName, State, ProcessId | Export-CSV -Path C:\output-file.csv
If you prefer to create an XML file, call Export-Clixml instead: Get-CIMInstance -Class Win32_Service | Select-Object Name, DisplayName, Description, StartMode, DelayedAutoStart, StartName, PathName, State, ProcessId | Export-Clixml -Path C:\output-file.xml
But we must warn you — the XML created is a bit difficult to read (or parse): 3. Export to XML with Windows Service AuditorFinally, if you’re after XML, our free Windows Service Auditor utility is worth a look. We created Windows Service Auditor to help protect against changes to your important Windows Services but it has the ability to export the list of services to an XML file as well. After downloading and starting Windows Service Auditor, simply select Export (XML} from the All Services menu to create the XML file: The XML will be very detailed, with all aspects of your Windows Services recorded. Here is an example: Because its output is so detailed, Windows Service Auditor is your best option if your goal is to take a snapshot of your services and all their settings. Hopefully one of these three methods works for you!
Posted on August 15, 2022  Hi. I think I’ve written a batch file that your AlwaysUp software cannot run as a service. Here are the contents of my file: @echo off
> usermessage.vbs ECHO Set wshShell = CreateObject( “WScript.Shell” )
>>usermessage.vbs ECHO wshShell.Popup “My Text line 1” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 2” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 3” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 4” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 5” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 6” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 7” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 8” ^& vbCrLf ^& _
>>usermessage.vbs ECHO “My Text line 9”, 120, _
>>usermessage.vbs ECHO “My Window Title”, 64
WSCRIPT.EXE usermessage.vbs
DEL usermessage.vbs I searched the internet for hours using various terms and finally found a suggestion that your software would solve my problem. It runs perfectly if I just click on it. But I could not make it run as a service. I’m not a pro at this. Any Ideas? — John Hi John. Thanks for trying AlwaysUp and for getting in touch. What’s the batch file doing?We’re not VBScript experts so it took us a while to understand what your batch file is doing! However, it soon became clear that the batch file: Constructs a VBScript file named usermessage.vbs on the fly. Adds a line to usermessage.vbs to create a Windows Script shell object. Adds lines to usermessage.vbs that call the Popup function with several lines of text. Runs usermessage.vbs, which shows a popup window with the specified text. The popup will stay on screen for up to 120 seconds, or until the user clicks the OK button. Deletes the usermessage.vbs file.
In summary, the purpose of the batch file is to show this message box for up to 2 minutes: It seems a bit contrived, but perhaps this code is a sample you created for testing? No doubt your “real” code is more practical and exciting. 🙂 AlwaysUp runs your batch file properlyAlwaysUp launches the batch file as a Windows Service just fine. And it has no problem running the dynamically created VBScript file either. We’re lucky to have hundreds of customers using AlwaysUp to launch their batch files, every day. Indeed, we were able to setup your batch file in AlwaysUp and confirm that it runs as expected. Process Explorer showed AlwaysUp running the batch file, which launched the Windows Script Host executable (wscript.exe) to display the popup window. You can see this arrangement in the tree of processes on the left: All good, right? Well, not entirely… Session 0 Isolation prevents you from seeing the popup windowEven though your script is running, you will not be able to see the popup window on your desktop. That is because of Session 0 Isolation — an important security measure that constrains Windows Services. You won’t see the popup because: your batch file is running in Session 0, on the special background desktop where all Windows Services operate, and Windows isolates applications running in Session 0, meaning that they cannot show up alongside the other windows on your screen.
Once upon a time, you were be able to switch to Session 0 to see the popup but no longer. Unfortunately, Microsoft removed that capability a few years ago. As a result, there is no way to see a window displayed in Session 0. So in summary, your batch file will not pop up a window on your interactive desktop when you run it as a Windows Service. And that’s true even if you don’t use AlwaysUp because the restriction is built into Windows itself. I hope this makes sense. Unfortunately, Session 0 Isolation can be tricky to comprehend. Please check out these FAQ entries if you want to dig into the details (caveat emptor): And please be sure to get in touch if you have any other questions. Best of luck with your project! | |
(888) 881-CORE
