I have a Screensaver written in .NET / C# that is dependent on a background process running. While the background process is added to the user’s startup programs on install, it would still be nice to not require the user to reboot their machine after installing the screensaver. The process itself has to run under the current user’s credentials, so using a Windows Service for this is out of the question.
The best solution I’ve thought of for this is to detect whether the background process is running when the screen saver starts, and start it if it’s not, just using .NET’s Process class. However, I’m noticing two somewhat related issues with doing this:
1) Windows seems to always think that the screensaver is running while the screensaver process, or any child process created by the screensaver, is still running. The net result of this is that the screensaver will start on its own and spawn the process, but will never start again, because Windows thinks the first screensaver is still active because the background process is still running.
2) If the computer is set up to lock the computer when the screensaver pops up, the user will be left with a blank screen after exiting the screensaver and has to explicitly ctrl+alt+delete to log in. This happens because the background process is running under WinLogon’s desktop and once again, Windows is waiting for the screensaver to exit.
Is there any way around this? The best thing I can think of is find some way to force the background process to run as a child of explorer.exe instead of the screensaver itself, but I’m not sure what the best way to go about doing that would be, or if it’s even possible. I’ve tried p/invoking the Win32 API’s CreateProcess method as well with various parameters to no success as well.
As a simple workaround, you could tie the running of the background process to the running of the screensaver – if the screensaver needs to start the supporting process, make it responsible for shutting down that process as well. You’d then have something that works, albeit with reduced functionality, prior to the first reboot.
Alternatively, as a more complex solution, given it’s possible for one process to start another with different credentials you should be able create a windows service that’s responsible for launching the background process with appropriate credentials, kind of a watchdog service that makes sure the actual background process is running.