Alternative to "Allow service to interact with desktop"?

Question

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.

Evangelize

The debugging part isn't a good reason. You could have have an executable and the service both use a common assembly that contains all the functionality. – Therefore

Yes, the windows service is running Windows Server 2008 Web Edition. Windows Service and executable are generated with Visual Studio 2008 against the with .NET Framework 3.5 – Evangelize

@Isaac: in the past I have been doing it with only a single assembly but since I started developing a lot of scheduled tasks on the same project it became more manageable to isolate the executing jobs from the service itself. But I see your point and maybe it would be more "correct" to have it all run inside the same assembly. – Evangelize

Answer 1

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.

Crespo

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. – Evangelize

Did you type that right? CreateNoWindow should be true and I think UseShellExecute should probably be false (although UseShellExecute might not matter). – Everick

Sorry about that typo! CreateNoWindow is indeed set to true. – Evangelize

Answer 2

I know this is a bit late but in this circumstance i would use the task scheduler and not bother with the windows service. The task scheduler has a comprehensive set of scheduling options and can run console applications without issue.

Verlie

Answer 3

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.

Cthrine

How would you go about removing the application's output? Where you thinking about the same solution as Weeble? Thanks. – Evangelize

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... – Cthrine

Answer 4

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

Everick

Thanks a lot for your link. I already tried it out but it still requires the checkbox to be enabled. – Evangelize

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? – Everick

It is a C# console application. I edited my question and added the error message that gets logged. – Evangelize