19

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.

jdecuyper
  • 3,934
  • 9
  • 39
  • 51
  • 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. –  Feb 27 '10 at 00:07
  • 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 – jdecuyper Feb 27 '10 at 00:09
  • @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. – jdecuyper Feb 27 '10 at 00:14

4 Answers4

11

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.

  • 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 Feb 27 '10 at 01:11
  • Did you type that right? CreateNoWindow should be *true* and I think UseShellExecute should probably be false (although UseShellExecute might not matter). – Weeble Feb 27 '10 at 01:53
  • Sorry about that typo! CreateNoWindow is indeed set to true. – jdecuyper Feb 27 '10 at 18:31
5

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.

Basic
  • 26,321
  • 24
  • 115
  • 201
Robert
  • 3,328
  • 2
  • 24
  • 25
2

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
  • 554,122
  • 78
  • 1,158
  • 1,373
  • How would you go about removing the application's output? Where you thinking about the same solution as Weeble? Thanks. – jdecuyper Feb 27 '10 at 01:04
  • 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 Feb 27 '10 at 01:12
2

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
  • 17,058
  • 3
  • 60
  • 75
  • Thanks a lot for your link. I already tried it out but it still requires the checkbox to be enabled. – jdecuyper Feb 27 '10 at 01:03
  • 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 Feb 27 '10 at 01:52
  • It is a C# console application. I edited my question and added the error message that gets logged. – jdecuyper Feb 27 '10 at 18:40