How do you start another process from a Window Service?

[Mike Pliam]

From a Window Service written in VS 2005 using CLR C++, I have been unable to start a another process. I tried using the suggestion made in a previous thread (see: How do you start another process using CLR C++ ?
http://www.codeguru.com/forum/showthread.php?t=457407).

The following code works quite nicely from a CLR C++ console program:

System::Diagnostics::Process::Start(sPathname1);

where sPathname1 is the complete path of an executable application.

The event log for the Service indicates that the run trigger was activated, and the Windows Task Manager shows that, in fact, the target executable is running, but there is no obvious computer screen evidence that the executable is running.

I suspect that there is some 'threading' problem here, but I am uncertain of that. I really don't know what's going on.

Any ideas what I am doing wrong?

[darwen]

obvious computer screen evidence that the executable is running

Does the executable have UI which you're expecting to see ?

In which case

(1) It is possible in XP by going to the services control applet (start/run/services.msc - go to properties of the service, logon tab and select "allow service to interact with desktop".

(2) In Vista it is impossible because services in Vista aren't allowed to interact with the users desktop.

So if you're writing for XP bear in mind that anyone using Vista won't be able to use your service.

What does your service do ? Why can't you just write an executable to be run by putting it in the users startup folder ?

Darwen.

[Mike Pliam]

It is possible in XP by going to the services control applet (start/run/services.msc - go to properties of the service, logon tab and select "allow service to interact with desktop".

Yes. That works. Is it possible to set that property programatically?

With respect to VISTA, I fear that this is one more manifestation of our exaggerated paranoia since 9/11. For more on this, please see: http://www.codeguru.com/forum/showthread.php?t=457499

[darwen]

There is no setting in the Installer class which enables you to set this, but you can go through WMI to do it.

In your installer class (the one derived from System::Configuration::Install::Installer) you need to override the OnAfterInstall method and do the following :

[RunInstaller(true)]
public ref class WindowsServiceInstaller : public System::Configuration::Install::Installer
{
    // ...

protected:
    virtual void OnAfterInstall(System::Collections::IDictionary ^savedState) override
    {
        using namespace System::Management;
        using namespace System::ServiceProcess;
        
        System::Configuration::Install::Installer::OnAfterInstall(savedState);

        ConnectionOptions ^connectionOptions = gcnew ConnectionOptions();
        connectionOptions->Impersonation = ImpersonationLevel::Impersonate;

        ManagementScope ^managementScope = gcnew ManagementScope("root\\CIMV2", connectionOptions);
        managementScope->Connect();

        // fill in your service's name here
        ManagementObject ^wmiService = gcnew ManagementObject("Win32_Service.Name='TestService1'");
        ManagementBaseObject ^inParam = wmiService->GetMethodParameters("Change");
        inParam["DesktopInteract"] = true;
        wmiService->InvokeMethod("Change", inParam, nullptr);
    }        
};

Fill in your services name in the appropriate bit.

Darwen.

[Mike Pliam]

Very impressive - and it works beautifully on Win XP Pro.

One question: The Window Service that we have been discussing brings up the Windows executable application as visible on the desktop at the appropriate time. However, that executable does not appear to function properly. For example, it does not retrieve Registry settings that have been previously set, as it does when run directly.

[darwen]

Let me guess - they're user registry settings ? In HKEY_CURRENT_USER ?

The app should be using registry settings in HKEY_LOCAL_MACHINE.

The service is logged on using the local services account so will use the registry settings for that user. Not the user who is currently logged in. That' s why it should be using settings in HKEY_LOCAL_MACHINE which are available to all users.

If you have to keep the user settings, you need to change the account credentials the service is using. You can do this in code by changing the Username and Password in the properties of the ServiceProcessInstaller class and changing the Account property to ServiceAccount.User e.g.

[RunInstaller(true)]
public ref class WindowsServiceInstaller : public System::Configuration::Install::Installer
{
private:
    ServiceInstaller ^serviceInstaller;
    ServiceProcessInstaller ^serviceProcessInstaller;
    
public:
	WindowsServiceInstaller(void)
	{
		InitializeComponent();
		
		this->serviceInstaller = gcnew ServiceInstaller;

                                // set up service installer properties here...

		this->serviceProcessInstaller = gcnew ServiceProcessInstaller;
		
		this->serviceProcessInstaller->Account = ServiceAccount::User;
		this->serviceProcessInstaller->Username = "MyUser";
		this->serviceProcessInstaller->Password = "password";
	}

Bear in mind services can be run when no-one is logged on. What's your service going to do if it runs when no-one is logged on ?

I have to say again I think your approach is wrong. I think you should write an application to be run in the Startup folder, or set in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run to be run when the user logs in. This will avoid all the problems with Vista and with the registry.

Darwen.

[Mike Pliam]

Your guess is correct! And you provide a powerful argument for using HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER for application Registry settings. I have always been confused on this point, and simply copied what appeared to me to be the trend of using HKEY_CURRENT_USER.

In fact, it is not so easy to use HKEY_LOCAL_MACHINE because the WinApp::SetRegistryKey(LPCTSTR lpszKey) defaults to HKEY_CURRENT_USER. As far as I can tell, there is no easy way to change that so that WinApp::GetProfileString(...), etc functions will work. In addition, if the Registry settings are interactive with the application, only those Users with Administrative privileges can change them. It seems clear that one must keep the objectives of a given application or service in mind when designing Registry interactions. In one recent application that had to be run by standard users over a network, I resorted to INI files, a step backward according to some, but it works just fine.

As far as my 'approach', I must confess that I am simply 'playing around' with Window Services at this point, trying to learn of what use such programs might be to enhance my other applications. Of course, Window Services are extremely interesting in there own right. And because I wanted to write my own Scheduler, it was suggested that I start with a Window Service. That turns out to be far more difficult than I had first imagined. In the process, I have gotten side-tracked onto VISTA issues and alot of other things. However, I am a big believer in 'playing around' as key to learning about new things, inefficient as that might sometimes be. BTW, I still havn't figured out how to write a Window Service scheduler that will work.

[vatsa]

It is not a reply, a question instead. In above discussion we are calling application from window service. can someone suggest me how to call window service from an application and use the methods and functions declared in a window service.I am using VC++