Click here to Skip to main content
13,549,950 members
Click here to Skip to main content
Add your own
alternative version


83 bookmarked
Posted 12 Sep 2005
Licenced CPOL

Watch Dog

, 5 Sep 2007
Rate this:
Please Sign up or sign in to vote.
Execute applications with a Windows Service and ensure its existance.

Watch Dog Windows Service (WDWS)

Imagine a scenario where you want to run a Windows application (executable) as a Windows service. It can happen when you have an already developed application that should run each time the system starts or it requires to be executed under the Windows system account or any other Windows account.

The WDWS application is capable of executing any Windows application automatically on its start up and terminates the started application on its termination. It executes a Windows application under its own account and guarantees to keep an instance of that application running while the service is running. That means if the application gets closed or didn't start properly, the Windows service will bring another instance of the same application up automatically. Defining Windows applications that should run using WDWS is as simple as adding them to the WatchDog.ini file defined under the WDWS path, as follows:


There is virtually no limit on the number of applications that the Watch Dog Windows service can handle and they can be defined under the App(n), n>=1 key of the [Apps] section of the WatchDog.ini file. The number of periods that the Watch Dog Service is checking for the existence of the subjected application can also be defined in the WatchDog.ini file under the Period key of the Settings section.

WDWS has the following files that should be in the same folder:

  • WatchDogService.exe
  • IniFIle.dll
  • WatchDog.dll
  • WatchDog.ini

To install the Windows service, use the InstallUtil application that comes with the .NET framework. For example:

%SystemRoot%\.NET\Framework\v1.1.4322\InstallUtil WatchDogService.exe

The WDWS application uses a Timer thread to start or stop checking the existence of the applications defined in the INI file. When an application starts, its Process ID (PID) is saved and the existence of that PID is checked periodically, if it does not exist then another instance of the same application is executed and the new PID is checked.

The idea behind the Watch Dog Windows Service is very simple; as its name implies, the Windows service is acting as a watch dog that is responsible for watching some applications. Dogs usually smell to learn and recognize the existence of an object, so in the Object Oriented Design pattern of this program, there is a Dog object of the WatchDog type that will be trained to learn the subject to be watched. Each WatchDog object has a timer thread that checks the trained smell using the SuspectedSmell() method of the Subject object and when the SuspectedSmell() method returns false, the Bark event of the WatchDog object gets fired which in turn runs another instance of the subject application and trains its smell which is the Process ID of the subject application.

An instance of the ITrainingDog object is passed to the WatchDog class defined in the WatchDog.dll file. The ITrainingDog interface has a method called SuspectedSmell() that is called periodically and the BarkEvent event is called when the SuspectedSmell() method returns false. The SuspectedSmell() method of the ITraningDog object checks the existence of the Process ID of the application that is being executed and watched by the WatchDog object, and it returns false when the PID could not be found. When the PID could not be found, the Bark event is fired and inside the Bark event method another instance of the watched application is executed and the new Process ID of that application is watched by the WatchDog object.

The object that should be checked, should implement the ITrainingDog interface, and the SuspectedSmell method of this object should return true while the condition of the object is okay (the PID exists) and this method is called in the timer thread by the WatchDog object.

public interface ITrainingDog
    object SuspectedSmell();

The WatchDog class is defined as follows and the object to be watched is passed to its constructor as an argument. The OnBarkEvent event is fired when the SuspectedSmell method of the Subject returns false. The WatchDog object should be trained to recognize the subject by calling the TrainTheSmell method after the WatchDog object is initialized. The TrainTheSmell method waits for the subject for a period of time that is defined as a parameter, it waits for the external application to be executed and its PID is available using the FindProcessID method of the Subject class.

public class WatchDog: IDisposable
    public WatchDog(ITrainingDog objectToBeWatched)

    private void OnBarkEvent(object source, WatchDogEventArgs rea)

    public void TrainTheSmell( int TrainingPeriod )

The object to be watched (Subject) that implements the ITrainingDog interface has the public void Initialize(string theApp2Watch) method that searches for the Process ID and starts watching the Subject.

The WatchDog object and the Subject are created and used as follows:

TheSubject = new Subject ();
pitBullDog = new WatchDog (TheSubject);
pitBullDog.BarkEvent += new WatchDog.BarkEventHandler(Dog_BarkEvent);
TheSubject.ProcessStatusChangedEvent += 
   new Subject.ProcessStatusEventHandler(Subject_ProcessStatusChangedEvent); 

public void Subject_ProcessStatusChangedEvent(object source, 
                                 ProcessStatusEventArgs rea)

    /// PitbullDog is a little stupid! so give him
    /// 4 seconds to learn the suspected smell!
    pitBullDog.TrainTheSmell( 4000 );


private void Dog_BarkEvent(object source, WatchDogEventArgs rea)

    // start the Engine again
    Subject beWatched =(Subject)((WatchDog)source).ObjectToBeWatched;

    beWatched.StartUp( theApp2RunPath );

Obviously you can use the WatchDog object structure to check another object periodically by calling the SuspectedSmell method.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Babak Ansari
Software Developer (Senior)
Canada Canada
Software development experience since 1993

- Programming Languages: C# .NET, Delphi, C++, Java and VB
- Development Methodologies (SDLC): RUP, Scrum and XP
- Database: SQL server, Oracle, Apollo database and MS Access.

Educations & Certificates
- Microsoft® Certified Professional (MCP)
- Sun® Certified Java2 Programmer
- B.S. in computer science

You may also be interested in...

Comments and Discussions

GeneralXYNTService Pin
siroman5-Sep-07 5:14
membersiroman5-Sep-07 5:14 
GeneralRe: XYNTService Pin
Marcos Silva13-Nov-14 8:09
memberMarcos Silva13-Nov-14 8:09 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.180515.1 | Last Updated 5 Sep 2007
Article Copyright 2005 by Babak Ansari
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid