The Core Technologies Blog |
Professional Software for Windows Services / 24×7 Operation
Posted on August 20, 2014 (Revised November 11, 2019) We are happy to announce the availability of the AlwaysUp Troubleshooter – our online, step-by-step guide to help you identify and resolve the most common problems encountered when configuring your application as a windows service. The troubleshooter is very easy to use and is packed with illustrative screenshots and helpful tips to quickly guide you to a successful outcome. However, if your issue is complex and demands more than can be achieved in that format, the interview ends with a summary of what has been learned and a contact form that makes it easy to engage our support team for additional help. So if you are having difficulty setting up your application, script or batch file as a windows service with AlwaysUp, click here to start troubleshooting now!.
Posted on July 20, 2014 Starting with Windows Vista in 2007 and continuing with every subsequent release, Microsoft has banned users from logging in to the first session created as Windows boots. This “Session 0 Isolation” has been accompanied by a steady erosion of the interactive capabilities of Session 0, rendering the Session 0 desktop virtually unrecognizable in the post-XP world. The prevailing wisdom in Redmond: Why support a proper working desktop in Session 0 when no one in their right mind is expected to use it? Unfortunately those of us working with interactive applications and Windows Services in Session 0 don’t have the luxury of ignoring GUI-related issues. And users of the excellent AutoIt automation toolkit have to make special accommodations when creating scripts to click buttons and fill in forms in Session 0. Here is what we have learned while troubleshooting AutoIt with our customers: WinActivate, WinWaitActive and WinActive Often Fail Essential AutoIt functions like WinActivate, WinWaitActive and WinActive rely on the operating system to track the active window. Unfortunately it seems that the active window is not tracked in Session 0 unless a user is actively viewing the desktop! Therefore a script that takes some action only if a window has been activated may never do its work. In this sample code, WinActivate will always return 0 when run in an unattended Session 0 and the button will never be clicked:
; Activate the window and click the button.
if (WinActivate($windowName)) Then
; Click the button on the window.
ControlClick($windowName, $buttonName, "")
EndIf
Our advice: Don’t depend on the Win* functions to find and activate a window. Simply operate on your window regardless of its active state. For example, restructure the code above to look like this:
; Try to activate the window if possible. May fail in Session 0.
WinActivate($windowName)
; Click the button on the window.
ControlClick($windowName, $buttonName, "")
The Mouse Functions (MouseMove, MouseClick, etc.) Don’t Work As with window activation, it seems that the mouse is not tracked when session 0 is unattended. Functions that move and manipulate the mouse can fail unexpectedly. Our advice: Don’t use the mouse functions in your scripts. AutoIt Scripts created with Au3Record Are Unreliable The Au3Record utility bundled with AutoIt will easily record a set of actions for later replay. It captures mouse movements, mouse clicks, key presses and more. However the script created makes heavy use of the problematic activation and mouse related functions cited above, thus rendering Au3Record scripts virtually useless in Session 0. Our advice: Don’t use scripts created by Au3Record in Session 0. You can Rely on ControlSend and ControlClick in Session 0 Fortunately functions like ControlSend and ControlClick continue to work as expected in Session 0. Neither of them relies on the target window being active nor the mouse being in a specific position, so they sidestep trouble related to those areas on the isolated desktop.
Are you using AutoIt in the isolated Session 0? Have you run into other functionality that does not work as expected? Please let us know what you have found! Your feedback will be much appreciated.
Posted on July 1, 2014 If you are comfortable working with Windows Services from the command line, take a look at Microsoft’s TASKLIST utility. This often overlooked tool — available on all versions of Windows — can help you answer the following questions as you troubleshoot your Windows Services: What is the PID Associated with a Running Service? You can use the name of the service to look up the identifier of the process associated with it. For example, to find the PID of the Print Spooler service (named “Spooler”), use: TASKLIST /SVC /FI "SERVICES eq Spooler"
Here is the result you can expect, with the PID listed in the central column: What Windows Services are Being Hosted by a Specific Process? If you are considering forcibly terminating a process, it may be wise to confirm that doing so will not unexpectedly kill related services! TASKLIST.EXE comes to the rescue by easily showing what services are running in a given process. For example, to see what services are behind the process with PID 1234, type: TASKLIST /SVC /FI "PID eq 1234"
Here we can see that the svchost process with PID 1284 is managing five (!) core services: Note that TASKLIST can interrogate remote machines as well. Simply add the /S /U and /P flags to the command line to specify the system, user name and password respectively. Enjoy! Posted in Miscellaneous | Tagged tasklist |
Posted on June 1, 2014 (Revised January 7, 2023) The Problem: Dropbox Automatic UpdatesRecently, a few customers reported “issues” with Dropbox automatically updating itself and causing havoc when running under AlwaysUp in their 24×7 environments. Apparently the auto-upgrade would restart Dropbox outside of AlwaysUp and that unmanaged instance would prevent AlwaysUp from starting a new copy under its control. The result was hundreds of Explorer windows open on the screen — a great experience! Our first instinct was to turn off automatic updates, which are usually a bad idea in a controlled, 24×7 environment anyway. Unfortunately Dropbox does not allow that. Auto-updates are totally managed by Dropbox and there are no exposed options for adjusting the behavior. The lack of controls thwarted our second brilliant idea as well — scheduling auto-upgrades for a specific time each day/week/month. Apparently changes can take place at any time, at the program’s discretion. Again, not suitable in a managed environment. A polite email to the Dropbox support folks explaining the situation and requesting help & advice yielded a most unsatisfying generic response:
Hi,
Thanks for writing in. While we'd love to answer every question we get,
we unfortunately can't respond to your inquiry due to a large volume of
support requests. Here are some resources for resolving the most common
issues:
Restore files or folders - www.dropbox.com/help/969
Reset your Dropbox password - www.dropbox.com/forgot
Reset/Disable two-step verification - www.dropbox.com/help/364
Learn about sharing files or folders - www.dropbox.com/help/category/Sharing
Learn about Dropbox's desktop app - www.dropbox.com/help/category/Desktop
Learn about Dropbox's mobile apps - www.dropbox.com/help/category/Mobile
For all other issues, please check out our Help Center - www.dropbox.com/help
We're sorry for the inconvenience,
The Dropbox Team
So time to do some reverse engineering! The Investigation: How Dropbox Auto-Update WorksWe installed an outdated version of Dropbox (2.47, thanks OldApps.com!) on our Windows Server 2012 machine, started it under AlwaysUp and patiently waited with Microsoft’s excellent Process Explorer open. It took about 8 minutes for the action to start… First, Dropbox.exe launched dropbox-upgrade-2.8.2.exe, which it must have silently downloaded into the private cache folder (C:\Users\<UserName>\AppData\Roaming\Dropbox\.dropbox-cache). - A few seconds later, the update program spawned a second copy of Dropbox.exe, passing the ominous /killeveryone flag.
Next, all instances of Dropbox subsequently shut down (including the one managed by AlwaysUp), and the updater launched a new copy of Dropbox before it too exited.
Notice the peculiar command line arguments. This is all fine when Dropbox is running normally on your desktop, but it is a problem when Dropbox is being managed by AlwaysUp. Indeed, once AlwaysUp noticed that the Dropbox process it was managing was closed, it started up a second copy: Now Dropbox abhors multiple instances, so after a few seconds the AlwaysUp-controlled instance exits — but not before throwing up an Explorer window browsing the Dropbox folder. AlwaysUp, persistent fellow that it is, detects that Dropbox has once again exited, starts it up again and the whole process repeats. It is easy to see that if left unchecked, we may end up with hundreds of redundant Explorer windows!
The Solution: Configuring AlwaysUp to Tolerate Automatic Dropbox UpdatesTo prevent the auto-update from triggering ten billion Explorer windows, we must have AlwaysUp close the instance of Dropbox spawned during the upgrade prior to starting its own copy. To do so: Edit Dropbox in AlwaysUp Click over to the Startup tab. If you have AlwaysUp version 9.0 (released in December 2014) or later, check the Stop all copies of the application running on this computer and the Also whenever the application is restarted boxes as pictured here: Otherwise, if you have an earlier version of AlwaysUp without the “single instance” feature: Download close-application.bat, a DOS batch file that will close a given application. Save it to the AlwaysUp folder (C:\Program Files\AlwaysUp, or C:\Program Files (x86)\AlwaysUp) Check the Run the following program/batch file box and enter the following command line: “C:\Program Files (x86)\AlwaysUp\close-application.bat” Dropbox.exe
Check the Also run it whenever the application is restarted box as well.
These changes will cause AlwaysUp to close all running instances of Dropbox before starting the one that it will monitor. And finally, to give Dropbox some time to complete its auto-update before AlwaysUp tries to fire it up again, click over to the Restart tab and: - Check the Whenever the application stops, restart it box
- Check the Not immediately, but box
- Select the After option and enter 5 minutes in the adjacent field.
Click the Save >> button to record your settings.
That’s it! The next time Dropbox decides to automatically update itself, AlwaysUp will quickly bring it back under control — for continued 24×7 operation. Posted in AlwaysUp | Tagged alwaysup, dropbox |
Posted on May 24, 2014 (Revised November 6, 2021) We are happy to report that AlwaysUp now integrates with the Windows power management system, to provide the ability to restart your applications when the host computer resumes from a low-power state (sleep or hibernation). This option is useful if your application being run as a Windows Service fails to properly handle the “time lapse” that occurs when a PC is put to sleep and later revived. This new, easy to use functionality is available on the Monitor tab. Simply check the box highlighted below and you will be ready to go: Enjoy! | |
(888) 881-CORE
