Develop Reference

Launch an exe application from windows service

I have a service which should open an exe application ( C# Application ) based on certain conditions. When the service is started in debugging mode ( Visual studio ) it opens the application. But when it is installed as a service, it does not do so. It fails to open the application. Why is this happening?

What you're trying to do isn't directly possible under normal circumstances - simply launching an app in a new process from your Windows Service code is not going to interact with the GUI of the currently logged in user I'm afraid.
There are ways of communicating between a service and the GUI however.
This discussion might point you in the right direction.

Based on your comments, I think what you are really looking for here is a normal userspace application and a scheduler. You might want to use Windows' own scheduler to run the application every monday, if it is an always-on box, or place the application in Startup. When the application runs, it should check the current day of week, and if it is monday and the application has not previously run this day, the application should start. If not, you can safely terminate the application entirely.

Thanks for the answers! I found out a solution for it and im posting it here.
I created a dummy app which is hidden on startup and it does the exact same function that the service was intended to.
1.create a dummy app (copy paste code from service to form application)
Hide it after start up.
2.start the application right after installation.
3.add registry key so that it starts up after a system reboot.
in simple words, clone service behavior.

process start on dll in c# [duplicate]

I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?

Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...

The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.

WTSEnumerateSessions and CreateProcessAsUser.

Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.

That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7

On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.

I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...

If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.

Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx

File System watcher in Windows Service or Console Application?

I am implementing a file system watcher, my requirement is to watch for a given local folder on a machine and then do a small task (for example open a certain page in web browser). The file(s) in the given directory would be generated randomly sometimes every two hours or four etc. This tool should be automated in the sense that a user does not have to start it. So my question is, Should I implement this in a windows service which always will be running or in a console application.Preference is to do it in a console application but then it would need to started by a user right? Please advice

You can automatically call any type of application (Console, Windows, etc.). What it gets down to with a Windows Service is whether you want it to be running before anyone logs in.
Only a Windows service runs while no one is logged in. A console application (while it can be set to run on login) must have someone log in in order to run.

Running a program when Windows Boots (before Login)

I wonder is it possible to run my application before login on windows.? Its actually a WinForm application(Preferably other than Windows service).
I mean my application must be running even before log in and it should sit on System Tray from which I can "show" or open Interface for user.

To have:
Something happen between system startup and user login
An icon in the notification area for users to interact with
You must break your application up into two separate components. One of these will be a WinForms/WPF application which provides the notification area icon and allows the user to interact with it. The other will be a Windows Service, or possibly a scheduled task.
Once you've done this, the windows service can focus on doing whatever needs to be done prior to logon and the notification area application can assume responsibility for showing the results, or whatever else to the end user.
To answer the question you posed in comments regarding reading data from the Event Log, yes this is possible. There are other questions on here which will give you that particular answer:
read the windows event log by particular Source
Read event log in C#

This MS article might help but it is a bit old:
http://support.microsoft.com/kb/142905
Hopefully it'll put you on the right tracks though.

I think, it doesn't make sense, to acquire user input before a user has logged into the system. So, if the application needs input from a user, why start it before the use has logged in? If the application just starts some background work, than you should use a windows service, as this is the prefered way in windows.

Type in run gpedit.msc, for Group Policy,
There you can set start up script.
Application will launch before Windows Login,
Step to produce :-
Start --> Run --> gpedit.msc --> Local Computer Policy --> Windows Settings --> Script (Startup/ShutDown),
Add you .exe
It will launch Before login.
Do not try more in Group Policy, it may happen harmful for System
By Programmatic logic,
Try with registry key
this value is updating in registry,
by our program we can update directly registry then we can call application

You can schedule any application to be run when computer is powered on using Windows Task Scheduler. There is a corresponding option there.
But why would you need this? You should use a service for this.

Application on windows startup C#

i have designed an application which validates users against online database and then allow users to work, after authentication it shows desktop, it loads on startup.
i would like to start my login application at windows start up, i have added my login application path to registry it is started well with windows. but it has one issue
first windows desktop appears few seconds and then my login application loaded
i would like to show my application before windows desktop
or
any other way to use windows login to validate user against online server database and then allow users to work.

If you don't want the desktop to show at all you can run your application as the Windows Shell.
You use this registry key
[HKEY_LOCAL_MACHINE\SOFTWARE\Micro­soft\Windows NT\CurrentVersion\Winlogon]
"Shell"="C:\\WINDOWS\\explorer.exe­"
The other solution is to use XP Embedded Standard so you can totally customise the Windows experience. Takes a lot more work than the simple shell replacement though, but much more robust

You could replace the shell as above, then have your application launch explorer.exe when you were ready to have the start menu and taskbar show up...