Note: Despite appearing as yet another question of the same matter, it's not, but choosing the right title seems hard so more appropriate title change is welcome.
I'm trying to solve an issue of starting up GUI application (Windows Forms, .NET) from a service application on Windows 7 Embedded (POS ready), and have come across several solutions, but none of them worked, with one exception I discovered along the way: Using a batch file as a helper file.
Background: There are several posts like this describing why this has been removed and protected, and I understand session 0 isolation, but before any debate dives into why this shouldn't be done, I'm just trying to get my head around it, as I don't like the current solution that our company is using.
I'll be using words "actual app" which represents two GUI applications that I've tried to run. One is Windows Forms .NET exe, and second Adobe AIR build exe app.
I've successfully set up a test service and have done tests with two accounts:
- Running a service under Local System account (with and without "Interact with desktop" option...)
- Running a service under Administrator account -> This approach does not allow use of CreateProcessAsUser since its already in user session
Under Local System account, it works as expected, and I've successfully executed CreateProcessAsUser" command as shown here by murrayu and used his helper class implementation, but with no success. While actual app starts up in GUI under user account, it either doesnt start (AIR), or it has issues and erros, mostly with Access Denied exceptions present (.NET app).
Under Administrator account, the solution using CreateProcessAsUser does not work as mentioned, but using approach B (code at the end of post), which works fine for one app starting another app, did not work. There was no GUI present, as expected in a way.
Third try, solution included helper application that service would call, which then starts up the actual app. Testing this using Local System account and CreateProcessAsUser, then calling approach B in the helper app, resulted in the same behaviour as in first test, where service invoked actual app.
Oddly enough, opening up Notepad.exe, cmd.exe, calc.exe using CreateProcessAsUser works just fine.
Since command line worked, I went down that rabbit hole: The fourth try, solution included a batch file, that included a single command:
START D:\TESTAPP\DotNetApp.lnk
Note that it points to the shortcut, as calling exe directly does not work.
To my surprise, this approach worked! The actual app started as if started regularly by executing the file manually.
Now what bugs me the most is - Is there something I haven't found or try yet? Did I miss something important? The .NET app was ran using Administrator account with full rights when it reported Access denied exceptions, and works totaly fine even under User account (restricted) if executed manually form folder, so there's really nothing special about it that would seem like a cause of the errors when ran from service.
Most importantly, or most wondering question though: What does the command line / batch do that makes it work? Is it possible to program it's behaviour / solution in a helper app, or better yet, directly in the service itself?
Also, when wanting to have a service handle GUI application, and where relying on Startup/Autorun is not desirable, what would be the better solution?
Appendix B:
public static void ElevatedExecute(string processName, string command, bool useAdminElevationRights = false)
{
Process process = new Process();
process.StartInfo = new ProcessStartInfo(processName, command);
if (useAdminElevationRights)
{
SecureString ssPwd = new SecureString();
process.StartInfo.UserName = "Administrator";
string tmpPass = ADMIN_PASSWORD;
for (int x = 0; x < tmpPass.Length; x++)
ssPwd.AppendChar(tmpPass[x]);
process.StartInfo.Password = ssPwd;
}
process.StartInfo.UseShellExecute = false;
process.Start();
}
Any insights would be highly appreciated.
