The Core Technologies Blog |
Professional Software for Windows Services / 24×7 Operation
Posted on November 26, 2016 (Revised February 1, 2024) Windows Server 2016 was quietly released on October 12th. This new operating system extends Microsoft’s reach into modern cloud technologies (with Nano Server and Docker) and introduces a host of under-the-hood improvements in security, networking and automation. This Technet article digs into the details. Anything New for Window Services?No — at least nothing that we could find. Unlike Windows 8.1 or Windows Server 2008 R2, Windows Server 2016 was not accompanied by an update to the underlying Services API. There are no new capabilities available to applications built on top of those mission-critical functions supporting 24×7 operation. Indeed, the reliable Services Control Panel application remains the same as we saw in the previous generation, Server 2012 R2: Nevertheless, we were still very curious to see if any of our applications would run into trouble on Microsoft’s latest and greatest! AlwaysUp Windows Services Work Well on Server 2016We easily installed AlwaysUp 9.7 on our Server 2016 test machine. And with no major changes for Windows Services, it was no surprise to see AlwaysUp running applications like Dropbox, Box Sync and Skype reliably in the background:
Service Protector Monitors your Important Server 2016 ServicesOur team encountered zero issues installing, running and evaluating Service Protector 5.3 over a two week period. Advanced features such as CPU hog detection, scheduled restarts and email alerts all operated without a hitch.
Our Free Utilities are Compatible with Windows Server 2016 TooThankfully Service Trigger Editor, ServiceTray, Switch to Session 0 and all our other products performed flawlessly on the new OS as well. No problems were found.
But Server 2016 Contains a Bug: No Keyboard and Mouse in Session 0We discovered this problem when we tested Windows 10 last year, and it now appears to have taken hold on Microsoft’s Server operating systems as well. The folks in Redmond are aware of the bug and claim to have a fix but several of us who rely on Windows Services have been impatiently awaiting a resolution for over a year now. 🙁 So to sum up, we are pleased to report that our entire suite of applications is compatible with Windows Server 2016. Best of luck running Server 2016 in your business! Additional Windows Server 2016 Information
Posted on October 30, 2016 If you are responsible for keeping a CPU-hogging Windows Service running all the time, then we have some great news! Service Protector, our time-saving administrative tool that helps any Windows Service achieve 100% uptime, is now able to monitor processor use across all your server’s CPUs. Previous versions of Service Protector would only monitor a single CPU/Core. This approach fit with the vast majority of today’s popular windows services that run entirely on one CPU, but it was inadequate for newer, performance-hungry services designed to make use of all a server’s CPUs. This release addresses that deficiency by detecting “runaway” services consuming too many cycles across all the CPUs. How to Activate Windows Service “CPU Hog” Detection Across All ProcessorsTo identify and automatically restart a misbehaving windows service that ties up multiple CPUs, simply check the Average over all CPUs (instead of only one) box when configuring Service Protector’s Monitor tab: With the above setting, a service running on a 4-CPU machine that consumes over 95% of all processing power would be automatically restarted by Service Protector. Enjoy!
Posted on September 1, 2016 (Revised November 26, 2024) Our free ServiceTray utility manages any Windows Service from a convenient tray icon. Most folks that use the software configure it to start at login by placing a shortcut in the Windows Startup Folder, but unfortunately that method is not effective on the latest versions of Windows. UPDATE (March 19 2021)ServiceTray version 4.0 eliminates this issue. Instead of starting in full administrative mode, ServiceTray now starts with minimum permissions and prompts for admin rights when the first service operation is performed. As a result, Windows now happily launches ServiceTray from the Startup folder. So if you are using the latest version of ServiceTray, there is no need to implement any of the solutions described below. Why Doesn’t the Startup Folder Work for ServiceTray? Microsoft introduced a set of security features called User Account Control (UAC) in Windows Vista and Server 2008. The key concept behind UAC is that of “least privilege” — where all applications run with normal, non-administrative rights until someone explicitly allows elevation to the more powerful context. Yet while UAC has certainly made PCs more secure from malicious viruses and other hostile actions, it can occasionally foil legitimate use. For example, UAC doesn’t play nicely with programs configured to start automatically when you log in. Indeed, if an application or shortcut in the startup folder requires administrative rights, Windows will not start it! Such is the case with ServiceTray, which must run as an administrator to start, stop and interrogate your Windows Service. So how do you get ServiceTray to start when you login? We have identified a couple of solutions: Solution #1: Disable UAC Perhaps the simplest way to get Windows to automatically launch ServiceTray is to turn off UAC. Indeed, a quick Google search will turn up many articles showing how to disable UAC. Apparently many people have found UAC very frustrating and end up turning it off. However as this post points out there are many security implications to consider if you go that route. So caveat emptor! Solution #2: Create an “At Login” Scheduled Task You may have heard that the Windows Task Scheduler is the ideal choice for running background tasks at scheduled times, but did you know that it can also fire up an application on your desktop when you log in? Here is how to do that for ServiceTray: Start Task Scheduler. This is best done by running taskschd.msc from a command prompt, or by opening the Control Panel, searching for “schedule” and clicking the Schedule tasks link. From the Task Scheduler window, click the Create Basic Task… action on the right: You should now be looking at the Create Basic Task Wizard window where you can enter a name for the new task we are creating. Something like “Start ServiceTray on Login” would be appropriate, but you can enter anything you like. Click Next > to move on. In the Trigger section, select the When I log on option and click Next >. Next, choose the Start a program option. As usual, click Next > to proceed to the next screen. Now it’s time to tell the Task Scheduler how to start your ServiceTray shortcut. We’ll need to find that information from the shortcut itself. Find the shortcut you created with ServiceTray. Right-click on it and select Properties. The window that comes up should look like this: The Target field contains the full command line used to launch SerivceTray with your selected Windows Service. From that field, copy the path to the ServiceTray executable (probably “C:\Program Files\ServiceTray\ServiceTray.exe” — don’t forget the quotes) and place it in the Switch back to the Create Basic Task Wizard’s Program/script field. Put everything else into the Add arguments (optional) area. For example, our ServiceTray shortcut command was: “C:\Program Files\ServiceTray\ServiceTray.exe” “Spooler” -icon 1
Here is what the Create Basic Task Wizard window looks like after that command has been entered: Click Next > to move on. The basic configuration is now done and you should now see a summary of the scheduled task to be created. But before clicking the Finish button, make sure to check the Open the Properties dialog… box because we’d like to make one more modification. And finally, in the Properties window, check the Run with highest privileges box. This magical option will ensure that ServiceTray starts with full admin rights, so that it can manage your Windows Service. Click OK to dismiss the dialog. Please close the Task Scheduler as well as your task is now in place.
Our Recommendation While deactivating UAC is certainly quicker and easier, we recommend going with solution #2 as it doesn’t require any compromises in security/protection. Enjoy!
Posted on August 13, 2016 (Revised February 17, 2025) To transfer your AlwaysUp Windows Services to a new computer, please follow this 4-step process: 1. Export your AlwaysUp Application(s) from your Existing Server If you don’t want to move any applications/services from your old server, go straight to step 2. Otherwise, to export each of your AlwaysUp applications to a XML file: Select Application > Export All… to summon the Browse For Folder selector: Choose the folder where you would like the XML files to be saved. Copy the XML files to a flash drive, or make them available on a network share that is accessible from your new PC. You will need them in step 3.
2. Download & Install AlwaysUp on your New Server On your new PC, download AlwaysUp from our web site and follow these step-by-step instructions to install it. 3. Import your AlwaysUp Application(s) into your New Installation If you exported applications in step 1, now is the time to import each of them into your new installation. On your new PC: Select Application > Import… Next, select the XML file representing the service you wish to restore. This will launch the Add Application window, already populated with the details of your service. Review your application’s settings. Please pay special attention to the path to your main executable or script on the General tab (or any other file locations configured for your service) which may be different on this new PC. Note that you may have to re-enter your Windows password on the Logon tab because that password was not exported along with your other settings (to enforce security standards). Click the Save>> button to record this service.
Please repeat these steps for each of the applications/services you wish to restore. 4. Register AlwaysUp on your New ServerChances are that the registration code assigned to your old PC won’t work on the new computer. You’ll need to: - Revoke your old license assignment;
- Assign your license to your new installation.
That’s it! Best of luck with your new machine!
Posted on July 3, 2016 (Revised May 1, 2022) The ProblemTod Daniels of d’innovative reported a strange problem. His JScript file (run with Microsoft’s CSCRIPT.EXE) started fine from his desktop but failed when run as a windows service with AlwaysUp. By troubleshooting the situation from the command line, Tod was able to narrow the problem down to a problem when reading from the registry. Specifically: - regedit /e F:\test1.reg “HKEY_LOCAL_MACHINE\Software\Broadcom\BACS” run outside AlwaysUp produces a file containing the registry export.
- regedit /e F:\test2.reg “HKEY_LOCAL_MACHINE\Software\Broadcom\BACS” run inside an AlwaysUp CMD session does not produce a file.
Both commands were run in the same user account, so why the different results? The SolutionThe discrepancy is due to the different views of the registry presented to 32-bit and 64-bit applications. Most modern versions of Windows are 64-bit. All the major applications and supporting DLLs distributed with the OS are 64-bit. To ensure that older 32-bit applications continue to run fine on these new operating systems, Microsoft engages in some “creative trickery”: 32-bit applications see a 32-bit version of the System32 Folder Even though the Windows System32 folder (typically, C:\Windows\System32) is stocked with 64-bit applications, a 32-bit application has that folder “mapped” to a counterpart (C:\Windows\System32\Wow64) filled with 32-bit versions instead. So when a 32-bit application runs the “DIR” or “REGEDIT” commands, it is actually invoking the 32-bit version in the Wow64 folder. This silent mapping ensures compatibility when a 32-bit application invokes one of those standard Windows utilities. AlwaysUp is a 32-bit application and is constrained by this behavior. When we’re troubleshooting, the command prompt is launching the 32-bit version of regedit. 64-bit applications work with a (slightly) different view of the RegistryIn the 64-bit operating systems, some registry keys actually have a 32-bit version and a 64-bit version! One such key is HKLM\Software. 32-bit applications can write to this key normally, however the changes show up under HKLM\Software\Wow64 instead. A 64-bit application can see both versions of the keys and can choose which version to access.
Now Tod is using Windows Server 2012 R2 which is 64-bit. Our “a-ha” moment came when we noticed that this key exists: HKEY_LOCAL_MACHINE\Software\Broadcom\BACS
but the corresponding 32-bit key does not: HKEY_LOCAL_MACHINE\Software\WOW6432Node\Broadcom\BACS
This discrepancy means that 64-bit applications can access HKEY_LOCAL_MACHINE\Software\Broadcom\BACS while 32-bit applications cannot see a registry entry with that same name. Tod was able to start the 64-bit version of regedit from AlwaysUp by exploiting another bit of Microsoft trickery — the Sysnative folder. This is the full path that enabled regedit to find the Broadcom key: C:\Windows\Sysnative\regedit /e F:\test1.reg “HKEY_LOCAL_MACHINE\Software\Broadcom\BACS”
Ultimately he was able to launch the 64-bit version of CSCRIPT from the same path and his application is now functioning as expected as a Windows Service! | |
(888) 881-CORE
