Exe won't run from code

lukin

I have a Windows Desktop application and in one part of it I want to call another application.
I am using ProcessStartInfo to call the exe (Add_schedules.exe).

It works perfectly under Windows XP but not on Windows 7. If I physically right-click on the exe (in Program Files) that the code file is calling and select "Run As" and then pass in the username and password that I am using in the code below, then it works but not when I do it from code behind (as below).

The user credentials I am passing into ProcessStartInfo does have sufficient priveleges to start the application it is calling so it is not insufficeint privelges that is the problem.

I don't even get an exception when I wrap a try/catch around the code. Just nothing happens.

The Domain,username and password are received from a database via a web service call (I have not included that code). The funny thing is,if I change it to use the credentials of the Administrator of the domain, it works but I am not permitted to do this, it has to be a specific user. It looks like under Windows 7 I can only use ProcessStartInfo when I am using Administrator, but not any other user.

Any replies are appreciated. The code is below.
Edit: Don't suggest using Impersonation as I have tried that already and it only works on Windows 7 if you disable UAC and then reboot (this is not an option)

string loc = System.Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFiles).ToString();



                        ProcessStartInfo startInfo = new ProcessStartInfo(loc + @"\AddSchedules\AddSchedules v1.0.00\Add_schedules.exe");

                        startInfo.WindowStyle = ProcessWindowStyle.Hidden;
                        startInfo.CreateNoWindow = true;
                        startInfo.UseShellExecute = false;
                        startInfo.Domain = domainName;
                        startInfo.UserName = userName;
                        startInfo.Password = s;
                        startInfo.Verb = "runas";                      
                        Process process = Process.Start(startInfo);
                        process.WaitForExit();

srsly78

Doesn't look like a batch file to me, looks like an exe.

Try not running in a protected folder (like program files). Test it out in c:\temp instead. Windows 7 protects certain folders.

edit: After more careful reading this is your problem. Only admin can write to those folders. Use the hidden %APPDATA% folder if you want to write stuff. Do NOT try to write to files in program files.

lukin

srsly78 wrote: »

Doesn't look like a batch file to me, looks like an exe.

Sorry, yes it's an exe, will fix the thread title.

lukin

srsly78 wrote: »

Try not running in a protected folder (like program files). Test it out in c:\temp instead. Windows 7 protects certain folders.

The Add_schedules.exe I am trying to start is an application so it's going to be installed to Program Files by default right?

srsly78 wrote: »

Only admin can write to those folders. Use the hidden %APPDATA% folder if you want to write stuff. Do NOT try to write to files in program files.

I'm not really trying to write to Program Files, I'm only calling an executable within it.

srsly78

Are you sure? Does it try to create a logfile or anything like that?

Do a simple test, try to run it from c:\temp.

lukin

srsly78 wrote: »

Are you sure? Does it try to create a logfile or anything like that?

Do a simple test, try to run it from c:\temp.

I copied over everything from the AddSchedules directory to c:\temp and changed the code to run the exe from there but still no go.

srsly78

http://stackoverflow.com/questions/4223008/process-start-permissions-problem

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.useshellexecute.aspx

See notes about working dir and shellExecute flag.

lukin

Tried it this way, still no good:

 string loc = System.Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFiles).ToString();



                        ProcessStartInfo startInfo = new ProcessStartInfo();
                        startInfo.FileName = @"cmd.exe";
                        startInfo.Arguments = loc + @"\AddSchedules\AddSchedules v1.0.00\Add_schedules.exe";
                        startInfo.WorkingDirectory = loc + @"\AddSchedules\AddSchedules v1.0.00\";
                        startInfo.WindowStyle = ProcessWindowStyle.Hidden;
                        startInfo.CreateNoWindow = true;
                        startInfo.UseShellExecute = false;
                        startInfo.Domain = domainName;
                        startInfo.UserName = userName;
                        startInfo.Password = s;
                        startInfo.Verb = "runas";                       
                        Process process = Process.Start(startInfo);
                        process.WaitForExit();

srsly78

You aren't debugging it right, there should be some kind of error. And you are still using %program files% - just do NOT use this directory (until you figure out how permissions work).

Colonel Panic

Are you sure you aren't eating exceptions somewhere higher in the callstack with an empty handler? You can set VS to break on handled exceptions too.

Is the program a command line app? You can redirect stdin/stdout when starting a process. You're saying nothing happens, but it's also possible the app runs, spits out some message and quits.

lukin

srsly78 wrote: »

You aren't debugging it right, there should be some kind of error. And you are still using %program files% - just do NOT use this directory (until you figure out how permissions work).

I tried it again with the directory in C:\Temp but still the same result. I think it is something in the domain security policy that is preventing me running any app elevated (unless I run it as Admin).
As I mentioned, it used to work if I physically right-click on the exe that the code is calling (in Program Files) and select "Run As" and then pass in the username and password. Now this only works when I pass in admin credentials.

srsly78

Ah right, domain changes everything. Test it on a normal box without any crazy policies.

Program Files is still protected under xp/7 even on a normal box tho. Avoid until you can get stuff working normally in another folder.

lukin

Colonel Panic wrote: »

Is the program a command line app? You can redirect stdin/stdout when starting a process. You're saying nothing happens, but it's also possible the app runs, spits out some message and quits.

No it's a desktop app with a main method. It creates scheduled tasks programmatically. The app works, it's just whose calling it does not have the prieveleges.
I am thinking it is one of two things:

1. The domain user I created does have privileges to create Scheduled Tasks when it is a Windows XP PC on the domain but not Windows 7?
2. The domain user I created does have privileges to start an app elevated when it is a Windows XP PC on the domain but not Windows 7?

If this is the case then it is something on the local security policy on the Windows 7 PC that is not there on the XP PC.

lukin

srsly78 wrote: »

Ah right, domain changes everything. Test it on a normal box without any crazy policies.

Program Files is still protected under xp/7 even on a normal box tho. Avoid until you can get stuff working normally in another folder.

No point testing it on a PC that is not part of a domain; it's going to be installed on PC's where all of them are on a domain.

srsly78

There IS a point. You get it working first in a simple environment without complications, then you try it in a more complex environment. This is how you debug and eliminate problems.

Colonel Panic

lukin wrote: »

No it's a desktop app with a main method. It creates scheduled tasks programmatically. The app works, it's just whose calling it does not have the prieveleges.
I am thinking it is one of two things:

1. The domain user I created does have privileges to create Scheduled Tasks when it is a Windows XP PC on the domain but not Windows 7?
2. The domain user I created does have privileges to start an app elevated when it is a Windows XP PC on the domain but not Windows 7?

If this is the case then it is something on the local security policy on the Windows 7 PC that is not there on the XP PC.

I see. As you can guess, without knowing you're environment I can't be much more helpful. Can you at least establish whether the process starts or not? I see you set the CreateNoWindow param to true. What if you toggle that?

lukin

I think it's not a development issue and more an Operating System/Domain security issue. It is something on Windows 7 that I can't change.

Colonel Panic

I agree, but I think it would help to at least confirm that the process starts and try to work out what you can do about it.

lukin

Colonel Panic wrote: »

I agree, but I think it would help to at least confirm that the process starts and try to work out what you can do about it.

I've established that it's the exe the user can't start, not that it can't do what the exe is supposed to do (create scheduled tasks).
I kept Task Manager open while right-clicking on the exe and starting it as a different user:

1. As the specific user I get from the web service; doesn't start the process but a process called dllhost.exe (description is com surrogate) did start briefly but disappeared just as quickly.
2. As Domain admin; starts no problem

It's a problem with that specific exe as if I try to start winword.exe as the specific user it starts fine.

stevenmu

It sounds like it might be a UAC issue, can you disable that?

lukin

Didn't need the separate application after all; I put the code to create scheduled tasks in a separate application in the first place because I tried calling it from one application and it didn't work because the user that was logged on at the time didn't have the priveleges.
I thought by taking it out and putting it in a separate app I could launch a ProcessStartInfo in the original app and call the separate app under a separate user.
Turned out that on the site I was installing it on the logged on users had full rights on their PC's so I just called the code from the original app and the scheduled tasks were created.
I'd still like to know why I can't call an application from C# in Windows 7 under a user other than administrator.
I think it might be be because of the way the application is created as because if it starts Word it should be able to start other apps (you would imagine).

lukin

stevenmu wrote: »

It sounds like it might be a UAC issue, can you disable that?

Yes disabling UAC would have resolved it but the network admin on site would not permit it.

srsly78

C# has loads of security stuff built in, it won't load dlls off network drives and stuff like that.

lukin

srsly78 wrote: »

C# has loads of security stuff built in, it won't load dlls off network drives and stuff like that.

Definitely something to do with the app (not the user privelege) as "dllhost.exe" appeared in Task Manager when I ran it under the specific user but when I ran a Microsoft app (Word) under the specific user it was fine.