views:

2070

answers:

3

I have a windows service (C#) installed on a server that launches every 10 minutes an executable file (C#) to process some images from one directory to another. No interaction is required with any user. Nevertheless, since the executable file as an output window, to make the service run I have to enable the "Allow service to interact with desktop" checkbox which is considered as an insecure and bad practice. How would I go about this problem? I like to have the executable separated from my windows service because

  • it makes it easier to debug and doesn't require a full windows service redeploy.
  • sometimes I use the same windows service to launch several executable files at different intervals (but all related to the same project).

EDIT:

When the interaction with the desktop is not enabled, the console application does not get executed correctly and the following error appears inside the Windows Logs:

Faulting application myapp.exe, version 1.0.0.0, time stamp 0x4b8304c3, 
faulting module KERNEL32.dll, version 6.0.6002.18005, time stamp 0x49e03821, 
exception code 0xc0000142, fault offset 0x00009eed, process id 0x10ec, 
application start time 0x01cab736950a64b5.

Once the desktop interaction is enabled, application gets executed normally.

Any thoughts?

Thanks a lot for your time.

+1  A: 

If you can, I would recommend rewriting your executables that handle the move to not use an output window. If they are standard, console applications with no output, you can execute them from within a service without requiring "Allow service to interact with desktop". This provides you all of the benefits, without any changes to your service.

Reed Copsey
How would you go about removing the application's output? Where you thinking about the same solution as Weeble? Thanks.
jdecuyper
Yeah, that was basically my thought. If it's just a console application, you shouldn't need to have desktop interaction. If you're using a Windows Application, however, it won't work...
Reed Copsey
+2  A: 

Is the subprocess just a console application? I've not written Windows Services, but I think perhaps just starting the subprocess without a window would be sufficient. Use the overload of Process.Start that takes a ProcessStartInfo and set ProcessStartInfo.CreateNoWindow to true.

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.createnowindow.aspx

Weeble
Thanks a lot for your link. I already tried it out but it still requires the checkbox to be enabled.
jdecuyper
Sadly I've not got access to a Windows machine at the moment. Do you know if the subprocess is starting and then failing or just not starting at all? And is it a console application, or something else?
Weeble
It is a C# console application. I edited my question and added the error message that gets logged.
jdecuyper
+2  A: 

If you are using Vista and later and you don't really need any interaction with the user, but have an interactive exe to execute, the Session 0 isolation feature should help alleviate some of the concerns about the 'bad practice' on having a service interact with the desktop (which in Session 0 has no physical console).

This Session 0 isolation would prevent unprivileged users from performing Shatter Attacks on your service as they get their interactive desktops in different sessions. Shatter attacks are the main reason why this 'interaction with desktop' was considered bad practice and if you are using Vista or later, it should be ok if you cannot avoid it (or will have to spend too much effort to do it).

So, if things are working fine as they are, you are probably ok.

Of course, after an OS update, things might just stop working, so it is probably better to prepare to move the dependency on interactivity out, as you don't really need it.

Moron
The Session 0 isolation makes a lot of sense and somehow makes me a little less worried about the security implication of my service. But as you correctly mentioned, it would be better to leave out the interactivity. When creating the process, I already tried to set the properties 'UseShellExecute' to true and 'CreateNoWindow' to false but the service still requires desktop interaction.
jdecuyper
Did you type that right? CreateNoWindow should be *true* and I think UseShellExecute should probably be false (although UseShellExecute might not matter).
Weeble
Sorry about that typo! CreateNoWindow is indeed set to true.
jdecuyper