I have a WPF application that I would like to be launched anytime the computer starts NOT when a user logs in. I know I can place the .exe in the startup folder, but I don't want that since a user has to login for that to be launched. I cannot use a Windows service, it's not an option for me.
Is there a way to start up an application once the PC starts up(or reboots), even before a user logs in? Any help is much appreciated.
You can't run an application without a user login. The only thing you can run is a Service, which I'm guessing from your question being about WPF that this is not what you want.
How about using the Task Scheduler? In Windows 7, there's a "Security options" section where you can set an option for a task to run whether a user is logged on or not. You can specify an executable file, and it'll start when Windows starts up.
(This won't scale though, if you're looking for an option when a user installs your software. For that, a service is the correct way to go... you may need to elaborate in your question why exactly you can't use a service.)
Related
Is it possible for code to work perfectly on the Administrator profile and not work at all while logged in as another user?
I am building certain applications at work, and while developing, coded and tested while logged on as Administrator. Every application working normally.
Now before deployment, when I execute the same application, but now logged in with a specific user account, I just get the error "Console Application stopped working" etc etc. I have handled all possible exceptions with my own Message Box, but this error is something I did not expect?!
In the exe's, I tried changing setting to "Run as Administrator", no use!
Any help would be much appreciated. Thanks!
PS - There are certain FTP methods I reuse from another class. And by handling all possible exceptions, I mean, I would have a try-catch block for the FTP method, so in case of error encountered after deployment, affected user may call helpdesk and notify the exact error.
Well, its not the right way to go, but right click and run as Admin, works butter smooth. Should I go ahead and modify all executables to - Run as Administrator under Properties->Compatibility??
You should firstly investigate if your application does need Admin rights indeed. A few scenarios that I can think of where an App needs admin rights are writing to protected locations of the system, writing to registry (excluding the areas that the user has rights on). If you think that admin access is not needed, you could always seek other ways to make it work. For example, instead of writing to a protected location, create a directory for you application in the user's application data folder and write to that location.
When you launch the application, if you're running on I believe Windows Vista or higher(7 works this way for sure)
You can Right click on the application and click on Run as Administrator
And yes, Sometimes the application won't work if you're not running as an administrator. For instance, If it's trying to change files in a protected location.
There are other variances that can cause your program to not work, For me, "Console Application stopped working" normally means that you don't have the right version of the .net framework installed, but it can mean any number of things.
First excuse my for my bad English language
i'm Writing a security application for my company and i want to prevent users from opening specific program like torrent in my application. but this is not the problem. the problem begin where users can close my application some how....
they can end process and ...
i need some solution to Hide my application from users or make it Unclosable
i was thinking to something like Network Notify icon or Clock in windows, i read about Explorer extensions but they don't help me because they already Closable
by the way i need application start working on computer start-up Automatically
thanks Everybody
Execute your watcher as a windows service and provider a user gui that only give some visual feedback to the user from the service by using some kind of inter-process communication. If the user closes the gui, the service still runs in the background.
But if your users have local administrator rights they can always stop your program (or service) somehow, otherwise they wouldn't be administrators of the system anymore.
At the moment we have .NET WinService started under LocalService user at windows start. The service launch another WinForms Application using Process.Start().
But there are several problems in this solution:
We don't wait for an interactive user logon and the Application falls because it tries and fails to initialize DirectX device.
Application launched under LocalService perfectly interacts with user desktop in Windows XP. But it doesn't work in Windows 7 because of there are different graphic stations for each user in win7.
Sometimes we need to run application with current interactive logon user rights.
Does anybody know how to wait for user interactive logon in the service and start WinForms Application with these user rights?
I think this helps to solve all problems.
You will need a separate client app. Check out this document, page 6: http://msdn.microsoft.com/en-us/windows/hardware/gg463353.aspx.
For your monitoring/restart scenario look at CreateProcessAsUser as mentioned in the document. You will almost certainly need to have your client app coordinate with the service for this, and it's still pushing a square peg into a round hole.
I would try using a combination of the answers above.
To solve #1
At user logon, launch the Winforms application using autostart in registry or startup folder. Make it notify the service that it was started successfully.
To make sure that the Winform app is started successfully after user log on:
Have your service that checks if application is started running in the background as you have now but don't let it do the initial startup.
Instead just let it register when user logs on, should be possible to do by listening to OnSessionChange.
Set a delay for X number of seconds to allow the login/startup process finish before it starts checking for a running application (ok maybe not the best solution).
If the service discovers that the application is not started or crashes, restart it from the service using the method Mark points out, CreateProcessAsUser.
Is it possible that this just isn't the right approach for what you're trying to do? It seems possible that you'd be better off putting the monitoring logic or whatever has the uptime requirements into the service so that it's "always on" so to speak. Then you would be left with UI logic in the WinForms app, which could be open or closed with no ill effect.
I found this nice snippet of code online:
rkApp = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Which runs great but alas on windows 7 and vista I suspect, it crashes cause it doesn't have permission to write there.
So then I research (on stackoverflow of course) how to avoid this, quickest method:
rkApp = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Simple enough! Though there is two issues remaining. One is with both methods (on a XP Box that is), the program thinks its relative path is somewhere in the C:\windows folder now...so I.e. it won't find my path relative help files etc. The second issue is, on windows 7, my program won't startup until I log in. I want it to start up in the background if possible before anyone logs in.
Its a simple .exe that hangs out in the systray when its running. I didn't want to create this monstrosity of an installer to get around these admin and pathing issues.
I Think I would have to create it as a service (no clue how to do that) to get it to start up when the machine reboots before anyone logs in. Secondly to do that I am sure I have to figure out the admin privileges, and since I don't want to have to approve the program to run every time it starts up it sounds like I would have to figure out its admin privileges during install time, but alas no installer.
So just curious what routes I might take to get this to work. I can even suffer it coming up only after when the user logs in, but my current methods that work this way really screw up the pathing of my program since it tries to write stuff out to a new directory (not the one I originally started the EXE from). Etc...and I have no clue how to go about fixing that pathing issue.
It sounds like you need two programs here.
You can't have an application run in the system tray and run prior to login. The system tray doesn't "exist" until the user logs in and has a valid desktop.
The normal way to handle this is to make two programs. First, create a windows service that does the bulk of your work. This will run on startup, and be independent of any user logins.
Then, make a user mode application which uses IPC to communicate with the service. This can run on login, and "talk" to the service remotely, thereby providing your system tray requirements.
If you want your program to start as a service before anyone logs on, then it's going to need to be installed and run as an admin user. There's not getting round this fact.
There's a Microsoft Knowledge Base article on creating a service which should get you started.
There's a project template for a Windows Service installed by default in Visual Studio 2008:
"File > New > Project > Visual C# > Windows > Windows Service"
At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.