The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


How to use the Event Viewer to troubleshoot problems with a Windows Service

A windows service, designed to run “headless” and unattended in the background, cannot easily employ conventional popup windows to report its activities as a user may not even be logged on. Instead, a service is encouraged to send important communication to the Windows Event Log – an administrative utility that collects and stores messages and events. Once recorded, these messages can be very helpful in troubleshooting problems, for example when a service stops unexpectedly or when it fails to start at all.

Viewing Events from Windows Services

Use Microsoft’s Event Viewer to see messages written to the Event Log. Start the application by clicking on the Start button and typing in Event Viewer, or from the Control Panel (search for it by name). The somewhat cluttered window should come up after a few seconds:


Event Viewer

The left hand side shows a tree grouping the various logs captured on your machine. The events from Windows Services (and other applications running on your PC) are filed under Windows Logs > Application. Navigate to that section to load the events in the center of the window, with the entire list in the top and details of the highlighted event underneath:


Event Viewer - Application Log

Messages from your windows service will have the display name of the service in the Source column.

Important Components of an Event

The Event Viewer shows over 10 pieces of information associated with each event, including:

  • Level – How important is this event?

    Each event is classified into one of three categories:

    Information: An informative yet unimportant event. You will probably see a lot of these, and they can be safely ignored unless you are digging into a specific issue from an application or service.

    Warning: A moderately important event. These don’t necessarily signify a failure, and your software will probably limp along, but they should be reviewed regularly to see if anything mentioned can be resolved.

    Error: Indicates a critical problem or failure that may deserve your immediate attention!

  • Date and Time – When did this event occur?

  • Source – Which application reported this event?

    As mentioned before, an event written by a Windows Service will contain the service’s display name as the Source.

  • Description – Which happened?

    The full description shown prominently in the lower pane will (hopefully) provide the relevant details of the event.

For example, this information event is from the Interactive Services detection service (“UI0Detect”) reporting that Notepad is showing itself in Session 0:


Interactive Services Detection Service Event

Viewing Events about Windows Services

While the Application log keeps track of events from a running service, the Windows Logs > System area records when services are started, stopped, crash or fail to start. Look for events with the Source set to Service Control Manager (SCM). For example, here is the SCM telling us that the Windows Print Spooler service has crashed:


Event Viewer System Event

Viewing Events from AlwaysUp and Service Protector

Both AlwaysUp and Service Protector write messages to the Application section of the event logs (Windows Logs > Application).

For AlwaysUp, events from your application named “My Application” will be logged with Source set to My Application (managed by AlwaysUpService). The Event Log Messages Page lists and explains the events reported.

For Service Protector, events related to your service named “MyService” will have a Source of ServiceProtector: MyService.

And for both applications, events related to the starting and stopping of the underlying services themselves appear in the Windows Logs > System section. Look there if you have a problem with AlwaysUp itself failing to start at boot.

Posted in Windows Services | Tagged , , , | 5 Comments

The Top 5 Reasons to Run Your Application as a Windows Service with AlwaysUp

  1. You need to start your application at boot, even if no one logs on

    Windows Service starts after a reboot A regular application will only run after a user has logged in and started it. Not so for Windows Services, which are automatically started by the operating system whenever the computer reboots and run happily without anyone having to do anything. Services are the true set-it-and-forget-it approach.

  2. Your application must be available 24/7

    Windows Services run 24/7
    The automatic, extensible failure protection system built into AlwaysUp will help to minimize the downtime for your legacy application — even if it’s buggy, leaks memory or stops working for no good reason!


  3. You don’t have the time, resources or access to the source code to re-write the application as a Windows Service

  4. No coding required The boss needs your software to be a Windows Service to win the next contract, but your development team is swamped and no one wants to mess around with the code anyway. Use AlwaysUp to “wrap” your application to operate as a Windows Service so you can satisfy the client and keep your boss happy, all in a day’s work.

  5. You are managing an unreliable application that keeps crashing

    Survive crashes with AlwaysUp
    Support calls for buggy applications have ruined too many evenings and nights! AlwaysUp automatically restarts unstable applications whenever they stop for any reason. You can enjoy an uninterrupted dinner with your family for a change!

  6. You prefer to run your program in the background, away from inexperienced users

    Run in the background to avoid user errors
    Mission-critical applications visible on the desktop run the risk of being accidentally shutdown by a user or closed when he logs off. However, a windows service runs on a “hidden” desktop where it is well insulated from those using the computer.

Posted in AlwaysUp | Tagged , | Leave a comment

Introducing the AlwaysUp Troubleshooter: Helping you configure your application as a Windows Service


AlwaysUp Troubleshooter

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 in AlwaysUp | Tagged , , | 4 Comments

Tips for Running AutoIt in the Isolated Session 0


The isolated Session 0 desktop

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?


The isolated Session 0 desktop

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:

  1. 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, "")
    
  2. 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.

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

  4. 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 in Miscellaneous | Tagged , , , | Leave a comment

Using TASKLIST to check your Windows Services

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:


TASKLIST - Find a Service's PID

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:


TASKLIST - Find a PID's 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 | Leave a comment