Question: I'm using the following code (any tried many variations) in a web page that is supposed to kill a process on the server:

```
    Process scriptProc = new Process();
    SecureString password = new SecureString();
    password.AppendChar('p');
    password.AppendChar('s');
    password.AppendChar('s');
    password.AppendChar('w');
    password.AppendChar('d');
    scriptProc.StartInfo.UserName = "mylocaluser";
    scriptProc.StartInfo.Password = password;
    scriptProc.StartInfo.FileName = @"C:\WINDOWS\System32\WScript.exe";
    scriptProc.StartInfo.Arguments = @"c:\windows\system32\killMyApp.vbs";
    scriptProc.StartInfo.UseShellExecute = false;
    scriptProc.Start();
    scriptProc.WaitForExit();
    scriptProc.Close();

```

The VBS file is supposed to kill a different w3wp.exe process, which tends to lock up. This is a legacy web app that we are going to replace soon, but in the meantime we need to limp by and force the app to shut down when this happens.

**I should note that killing w3wp.exe is not something I.T. professionals do.**

What happens is, WScript.exe is in task manager every time I run the kill page, and it never goes away.

The process WScript.exe (and I tried others such a psexec.exe) is being run as a local user with admin rights (and I tried other types of users including domain admins) when run from IIS, but it works when run from the command line on the server.

Answer: 
Yes, yes it should. Network Service is a user-level account at best and AFAIK IIRC will only be able to kill processes it started.

If the task is running on the server itself, the easiest way is probably to require Windows Integrated authentication for the page, and ACL it so that only Administrators and System can Read it.

That'll ensure that only Administrators can log on to the page, and there's a little bit of accountability around who killed the process.

Also, one other thought: have you confirmed that KillMyProcess.vbs works reliably when executed interactively with `cscript killmyprocess.vbs`?
I realize this doesn't really answer your question directly. But wouldn't it make more sense to take IIS and the manual user intervention out of the equation? Barring an actual monitoring tool (SCOM, Nagios, etc) in place, I'd think you could write a script that runs periodically via task scheduler on the offending server that can detect if the app is hung and take appropriate action.

Why wait until someone actually notices the problem and then has to take time out to fix it themselves? Just automate the problem away until you can get rid of the legacy app.