Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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();
    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;

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.

share|improve this question
Killing another process from within IIS is highly irregular and unconventional. The whole point is for IIS to run with very very limited permissions, so that an attack on IIS cannot turn into an attack on the OS. Stated differently, the steps you need to take to make kill work will make your system much much more vulnerable to attack, and would not be acceptable to professional admins. – samsmith Jun 5 '12 at 16:23
I'll update my post to mention this fact. This site has no external access and our business is extremely small, we have much more serious security vulnerabilities than this, but I will pass this info on to the admin in charge who requested it. – David Jun 5 '12 at 23:35

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?

share|improve this answer
Yes, cscript killmyprocess.vbs works at the command line. The process needs to be accessed by all users. We have an outdated web based production system that tends to lock up, and we need anyone to be able to kill the process. It doesn't interfere with the application at all. I created a local user on the IIS machine and am able to remotely execute the process under that user's name, but it still hangs and doesn't work. I also made sure that local user had accepted the Eula which was a problem earlier. In the meantime, I'm using PSexec.exe, which works, but I'd prefer to have an IIS link. – David Jun 5 '12 at 15:11

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.

share|improve this answer
I'll look into this. Looks like a very good option. Thanks. – David Jun 5 '12 at 16:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.