The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


Dropbox Windows Service spiking your CPU? Check your Antivirus Settings!

Dropbox locked up

Customer Theodore Bogucki recently reported strange behavior when running Dropbox as a windows service with AlwaysUp:

  If I run Dropbox as a normal application, the CPU will run at about 10%. Following the directions to set up Dropbox in AlwaysUp as a service, I will get Dropbox running at 100% CPU and the file upload is extremely slow.

I am using the latest version of Dropbox and the latest version of AlwaysUp on a Windows 2012 R2 server.

What can be causing Dropbox to run amok like this when running as a windows service?

After some back and forth to investigate, Theodore determined that his antivirus program (Symantec Endpoint Protection) was conflicting with Dropbox — but only when running as a service! He said:

The Dropbox folders currently stores SQL backup files from my SQL server. I was able to fix the issue by adding an exclusion in SEP for the file extension used for the SQL backup files. I just as easily could have specified the folder to exclude.

Once this was done I stopped Dropbox on the desktop and started it using AlwaysUp and the CPU only spiked for minute or so while Dropbox started up and then settled down to its normal level. I also observed that network activity was the same as when Dropbox was running on the desktop.

If you are experiencing a similar problem, here are the instructions for excluding files and folders from scans in Symantec Endpoint Protection. A simple Google search should turn up the same information for other popular antivirus packages.

Finally, thanks to Theodore for bringing this problem (and the solution) to our attention!

Posted in AlwaysUp | Tagged , , | Leave a comment

Why does my Windows Service keep forgetting its password?

The mystery: “The service did not start due to a login failure”

One of our customers reported a very strange problem last week. After about a day of running flawlessly, their windows service would suddenly fail to start after a reboot. The error reported by the Event Viewer hinted at a problem with the service user’s account:

Windows Service Logon Failure

Trying to start the service directly from the Windows Services Control Panel application produced the same unsatisfying result:

Windows service failed to start

The service account’s password had not changed, and the user had no problem logging into the server interactively. Why was the windows service failing to login?

Luckily we were able to get the service going again by re-entering the user’s password:

Re-enter windows service password

When doing so, we noticed that the “Log on as a service” right had to be granted again. Very suspicious…

Log on as service granted

But a mere 24 hours later, the problem resurfaced! Once again, the service failed to start after a reboot.

The problem: Group Policy overwriting Local Policy

The message about the “Log on as a service” right lead us to the root of the problem.

Entering the password in services.msc updated the user’s rights in the machine’s Local Group Policy — a collection of settings that define how the system will behave for the PC’s users. However, since the user and server were part of a domain, those local settings were periodically overwritten by the domain’s group policy, which had not been updated with the new permission. And because the necessary permission “disappeared” on the machine, the service failed the next time it tried to start.

The solution: Modify the Domain Group Policy

To fix the problem, we must update the domain group policy and explicitly give the service user the “Log on as a service” right. To do so:

  1. Start the Group Policy Management application.

    Open Control Panel, navigate to System and Security > Administrative Tools, and double-click Group Policy Management on the left.

    Start Group Policy Management

    (Note: Don’t search for “group” in Control Panel. That will lead you to the “Edit group policy” link, which opens the local group policy!)

  2. Find your default domain policy on the left. Right-click it and select Edit to bring up the Group Policy Management Editor window.

    Edit the default domain policy

  3. On the left, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment and select
    the Log on as a service entry on the right.

    Edit group policy user rights

  4. Double-click Log on as a service to bring up its Properties window.

    Add the user running your windows service to the list and click OK to record the change.

    Add the domain account running the windows service

Next time your domain policy is copied to your server, it will bring along the Log on as a service right for the user. You shouldn’t encounter the “logon failure” error again!

A closing note for the folks at Microsoft: A better error message please!

Instead of reporting the generic “logon failure”, why not be more precise and say something like “The user doesn’t have the necessary rights to start the service”? You could provide even more guidance by listing the missing rights.

The bottom line is a that a helpful error message highlighting the true problem would have led us straight to the solution and avoided a few anxious days for us and our client.

Posted in Windows Services | Tagged , , | 6 Comments

“AlwaysUp Helps Manage Asbestos Samples Worldwide”

Customer spotlight     Start Software

Start Software is an award-winning software development and consulting business with offices in the UK and Australia. They create easy-to-use software systems that their clients enjoy using and which deliver real benefits. The Start Software team are specialists in Alpha Anywhere, Alpha Five and Mobile Data Studio developments. Alpha Tracker — the latest addition to the Tracker family — is a web browser-based version of Tracker for asbestos surveyors, asbestos consultants and asbestos consultancy businesses of any size.

Start Software has been using AlwaysUp regularly since 2007.

Why does Start Software use AlwaysUp?

  We have created a variety of software systems using Alpha Five and Alpha Anywhere from Alpha Software and Visual Basic from Microsoft. Many of these systems need to be “always up” – operating like 24x7x365 windows services. The AlwaysUp product enables us to deploy these applications with confidence that the services they provide will always be available to our customers.

How are you using AlwaysUp today?

  We install AlwaysUp along with our software as a matter of course. We have more than 50 clients using AlwaysUp on Windows Server 2008 and Windows Server 2012 on a daily basis all around the world.

What are your favorite features of the software?

  AlwaysUp is easy to install and configure, and has flexible options for the automatic restarting of applications (services) under a variety of conditions. Technical support provided by Core Technologies is also excellent and they are a joy to deal with.

Any other comments?

   Our Tracker and Alpha Tracker systems have been used by asbestos consultancies to capture data about more than 25 million samples in buildings worldwide and so, indirectly, AlwaysUp is helping to manage this deadly substance across the globe.

Tracker Mobile helps asbestos sampling in the field  Tracker Mobile helps asbestos sampling in the field
Posted in AlwaysUp | Tagged , | Leave a comment

How to Run your Application Every Minute with AlwaysUp

Do you want to run a script or application every minute? And have you decided that creating an AlwaysUp Windows Service will be better than using the built-in Windows Task Scheduler? If yes, here are the key settings to specify with AlwaysUp.

Wait One Minute Before Restarting

By default, AlwaysUp will immediately restart your application whenever it exits. To have AlwaysUp “pause” for a minute before restarting, make the following changes on the Restart tab:

  • Select the Not immediately option

  • Choose the After option

  • Enter 1 minute in the controls to the right

Avoid Verbose Event Logging on each Run/Restart

AlwaysUp is designed to record detailed information whenever your application exits and has to be restarted. This is often useful information for applications that should run continuously but the logging can become overwhelming when your application is stopping and restarting every minute!

Check the Minimize event logging as the application stops & starts on the Restart tab to avoid extra chatter as your application/script cycles each minute.

Other Recommendations

If you are interested in email notifications, be sure NOT to check the Whenever the application stops and has to be restarted box on the Email tab! If you do, expect to be inundated with emails as your application goes up and down every minute.

Posted in AlwaysUp | Tagged , | Leave a comment

My Dropbox Windows Service no longer works after Updating Dropbox – Help!

Recently, a few of our customers running Dropbox as a windows service with AlwaysUp have reported failures after manually updating to the latest version of Dropbox. These are happening because Dropbox changes the location of its executable file during the update. Let’s dig into the details and see how to fix the problem.

The Old Dropbox Location

Prior to version 3.5.58, released in April 2015, Dropbox stored its application executable file (Dropbox.exe) in a user-specific folder. If you installed Dropbox in the Administrator account, you could find the file in C:\Users\Administrator\AppData\Roaming\Dropbox\bin:

Dropbox application folder

The New Dropbox Location

If you install a fresh copy of version 3.5.58 or later, you will notice that Dropbox.exe now lives underneath the Program Files folder, in C:\Program Files (x86)\Dropbox\Client (or C:\Program Files\Dropbox\Client on 32-bit versions of Windows):

Dropbox new location

We have already noted the new location in our step-by-step tutorial to guide future customers, but the story is more complicated for existing installations…

Upgrading Dropbox Changes its Location (and Breaks your AlwaysUp Configuration)

Unfortunately the impact of this change to the file locations isn’t limited to new installations. Manually updating an existing Dropbox installation will cause the files to be moved to the new folder. This isn’t a problem for Dropbox itself, but since AlwaysUp is blissfully unaware of the change, it will continue to run Dropbox.exe from its old location (as you originally specified in the Application field on the General tab):

AlwaysUp General tab - the old location

Because the executable is no longer present there, AlwaysUp will fail to start Dropbox and report errors like this:

AlwaysUp fails to start Dropbox

The Fix: Set the New Dropbox Location in AlwaysUp

Fortunately normal operation can be restored quite easily. Simply edit Dropbox in AlwaysUp and update the Application field on the General tab to specify the new path to the Dropbox executable (C:\Program Files (x86)\Dropbox\Client\Dropbox.exe):

Update the path to Dropbox

Save your settings and AlwaysUp should be able to start Dropbox normally again!

Posted in AlwaysUp | Tagged , | Leave a comment