Issue with getting System.Diagnostics.Process to execute a command line with right arguments

Hi all,
I have this very strange issue with a process that executes a command line (that talks to tumbleweed secure transport client) from a .NET Windows Service. This works fine from a windows forms application, strangely but not from a Windows Service. I am running as "Local System". Here's my code snippet from the service:
string batchFile = @"C:\temp\MyBat_TEMP.bat";

            System.Diagnostics.ProcessStartInfo procStartInfo =
            new System.Diagnostics.ProcessStartInfo(batchFile);
            procStartInfo.UseShellExecute = false;
            procStartInfo.CreateNoWindow = true;
            //procStartInfo.WorkingDirectory = @"C:\temp";
            System.Diagnostics.Process process1;
            process1 = new System.Diagnostics.Process();
            process1.StartInfo = procStartInfo;
            process1.Start();
            process1.close

Here's my batch file content (1 line):
stclient httpsu://<clienthostname>:443/BulkImport/to/ C:\ToSend\AMC_NT_6_201009021000.csv /prefNoAskSched /Remote-Site <RemoteSIteName>

It looks like the stclient is being called but with incorrect arguments WHEN i run from a windows service. Same code runs fine from an exe.
Does anyone know if anything needs to be done differently with the arguments to an exe when we run from a windows service vs an exe.
Any help is appreciated!
Thanks!
KimberleyYAsked:
Who is Participating?
 
cookreConnect With a Mentor Commented:
When a normal exe runs, it runs under the security of the logged on user.  A service, however, runs under the security of the configured account, in this case, systemlocal, which has full rights to the local box, but none to the network.

You may want to try a runas:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/runas.mspx?mfr=true

Note also that a service must be typed as interactive in order to see the window's message pump.
0
 
Mike TomlinsonConnect With a Mentor Middle School Assistant TeacherCommented:
Does it work like this?
            System.Diagnostics.Process process1 = new System.Diagnostics.Process();
            process1.StartInfo.FileName = "stclient";
            process1.StartInfo.Arguments = @"httpsu://<clienthostname>:443/BulkImport/to/ C:\ToSend\AMC_NT_6_201009021000.csv /prefNoAskSched /Remote-Site <RemoteSIteName>";
            process1.StartInfo.UseShellExecute = false;
            process1.StartInfo.CreateNoWindow = true;
            process1.StartInfo.WorkingDirectory = @"C:\temp";
            process1.Start();

Open in new window

0
 
cookreCommented:
cross posting is fun...
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
KimberleyYAuthor Commented:
Thanks for the responses.
IdleMind..I did try that as well, same result as the batch file. Seems to run the command line with some invalid options
Cookre..I tried doing:
procstartinfo.verb = "runas /user:<username>@domain
and that didn't help either.
I'll play with the runas option a little bit more.
I am also almost certain it's got something to do with running as localsystem vs user.
Thanks!
0
 
KimberleyYAuthor Commented:
cookre...also, i did turn on the "Allow service to interact with the desktop" option under the service proerties.
0
 
KimberleyYAuthor Commented:
This was interesting...there was a space in one of my command line options:
stclient httpsu://<clienthostname>:443/BulkImport/to/ C:\ToSend\AMC_NT_6_201009021000.csv /prefNoAskSched /Remote-Site <RemoteSIteName>
This worked from my windows forms exe but not from my windows service. I had to remove the space
/Remote-Site<RemoteSiteName> in order for the process to execute this command line correctly from the window service.
I thought the "@" at the beginning of the argument string would take care of that, but apparently it didnt.
Thanks for your time. I am closing this issue.
0
All Courses

From novice to tech pro — start learning today.