The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


Windows Service Protector 5.3 Monitors Multiple CPUs

New Version: Windows Service Protector 5.3 Monitors Multiple CPUs

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 Processors

To 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 in Service Protector | Tagged , , | Leave a comment


How do I Move my AlwaysUp/Windows Services to a New Server?

move AlwaysUp to a new Server

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:

  1. Select Application > Export All… to summon the Browse For Folder selector:

  2. Choose the folder where you would like the XML files to be saved.

  3. 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:

  1. Select Application > Import…

  2. 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.

  3. 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).

  4. 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 Server

Chances are that the registration code assigned to your old PC won’t work on the new computer. You’ll need to:

  1. Revoke your old license assignment;
  2. Assign your license to your new installation.

That’s it! Best of luck with your new machine!

Posted in AlwaysUp | Tagged , , | Leave a comment

Why does my Application have Trouble Reading the Registry?

Registry trouble with windows service

The Problem

Tod 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 Solution

The 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 Registry

    In 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!

Posted in AlwaysUp | Tagged , , , , | Leave a comment

Why doesn’t my Windows Service Start at Boot?

Windows Service not Starting at Boot

Windows Services promise 24/7 operation and it can be very frustrating when they don’t start as expected! Here are the top five reasons why a service may fail to launch when your server boots:

  1. Your Windows Service isn’t set to Start Automatically

    A window service can be configured NOT to start when your computer reboots. Indeed, a service can be set to startup only on demand, or entirely disabled so it cannot run at all.

    To check that your service is properly configured:

    1. Start the Services Control Panel application.

    2. Find your service in the list and double-click it to show its properties.

    3. Ensure that the Startup type field is set to Automatic.

      Note that Automatic (Delayed Start), where your service starts 1-2 minutes after all Automatic services have been launched, may also be acceptable.

  2. A Dependent Service Failed to Start

    Some windows services depend on other services to support their work. Windows enforces these dependencies when booting. For example, suppose there are two services, A and B, both set to start automatically at boot. If A depends on B, then Windows will launch service B before starting service A. If service B fails to start, Windows will not start service A.

    Open your service in services.msc and switch to the Dependencies tab to see if your service relies on others. If so, the problem may be with one of those dependent services.

  3. The Service Account’s Password has Changed

    If your service runs in a specific user account, was the password for that account changed recently? If so, you should edit your service and enter the new password (on the Log On tab):

  4. There is a Problem with the Domain Account’s Group Policy

    If your service is running in a domain account, ensure that the domain account’s group policy has the “Log on as a service” right. As described in this article, the service may run fine at first but suddenly stop working when the local policy (which has the right) is overwritten by the global policy (which does NOT have the right).

    Look for the telltale “The service did not start due to a login failure” message in the Event Logs to identify this situation.

  5. There is another problem, reported in the Event Logs

    Your service may be shutting down because it has encountered a fatal error. The devil will be in the details so be sure to scour the Event Logs for any helpful messages from your service.

    Your service may also maintain its own log files, separate from what is available in the Event Viewer. Please be sure to consult those as well!

Posted in Windows Services | Tagged , , | 2 Comments