Process.Start is causes application to hang

[Jesse Cates via DotNetMonster.com]

I am trying to launch a command-line program that came with a program called Live Stats. This command-line program is used to automate configuration of Live Stats. In order to test this, I am just calling the program with no arguments, which just returns some "how to use" text, and requires no user input. The problem is that once I do a .start on the process, the program just hangs indefinitely. I can see it running in the process list on the server, using 0% CPU, but it never goes away. When I tried it with the arguments to actually change a setting, that setting never got changed. If I try doing a .StandardOutput.ReadToEnd (Or any other type of Read), or a .WaitForExit, then the ASP.NET page will hang as well. I took the exact same code I'm using in the ASP.NET page, and put it into a standard windows VB.NET app. I ran that app on the server, and it worked with no problems at all. In addition, using the same code in the ASP.NET page with a different app works just fine, so I know that it has something to do with the program I'm trying to run, but can't figure out what exactly it is. If anyone is willing to help me with this, I will gladly send you the program (It's only a 300kb single-file executable), to see if you're able to help. And, here is the code that I'm using (VB):

Dim siStartInfo As New ProcessStartInfo("ls6remote.exe")
Dim pLSRemote As New Process
Dim strReturn as String

'Initialize Process properties
siStartInfo.UseShellExecute = False
siStartInfo.CreateNoWindow = True
siStartInfo.RedirectStandardOutput = True

pLSRemote = Process.Start(siStartInfo)
strReturn = pLSRemote.StandardOutput.ReadToEnd
Response.Write(strReturn)
pLSRemote.Close()

 

[Steve C. Orr [MVP, MCSD]]

ASP.NET by default runs under the user account ASPNET.
Most likley, this user account does not have permissions to the file, or to
one of the resources that file is trying to access.
For testing purposes you can have it run under your personal user account
since you know your account has the necessary permissions.
Here's more info:
http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconaspnetimpersonation.asp

 

[Jesse Cates via DotNetMonster.com]

Man, I can't believe I typoed in the topic. :/

Anyway, a little more info about the LS6Remote.exe. This program does connect to the Live Stats server via TCP. I'm not actually using it to connect to any servers in the code that I'm testing this with, but I guess it's possible that the app is trying to open a socket, anyway. I have no idea if this would make a difference or not (Does the ASP.NET worker process maybe not have permissions to open new sockets? Just grasping at straws, here).

Also, info about the environment of the server: Windows 2000 Server w/ SP4, IIS 5.0, and .NET 1.1 (No SP1 on it, yet). I am not using impersonation, and have verified that the ASPNET user has full control on ls6remote.exe (It is actually launching the process, so I don't think this might be considered an issue, but just in case).

 

[Jesse Cates via DotNetMonster.com]

I had checked and double-checked that the ASPNET account had full access to the file I was trying to run, but hadn't thought to try running as a different user. So, I followed your suggestion. Unfortunately, apparently process.start always runs as the account that ASP.NET is running as, regardless of the impersonation used. Even though System.Security.Principal.WindowsIdentity.GetCurrent().Name showed what I was impersonating as, when I viewed the new process in Process Explorer, it showed it running as ASPNET. I tried lauching whoami.exe from an ASP.NET page, and it returned ASPNET. I Googled a little, and apparently this is the behavior of process.start, and that .NET 2.0 will have parameters for specifying a user to run as. That doesn't help me much currently, though.

Anyway, to test to be 100% sure if it was a permissions problem or not, I tried adding ASPNET to the administrators group, and it then worked. Then it was just a matter of using FileMon, and looking for any "ACCESS DENIED" results. Once I got that all sorted out, it's now working.

So, thanks for pointing me in the right direction.

 

[Steve C. Orr [MVP, MCSD]]

I'm glad I was able to help.
And thanks for sharing the additional details about how you got it working
so the rest of us can benefit.