Я использую следующий код (любые опробованные варианты) на веб-странице, которая должна убить процесс на сервере:
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();
Предполагается, что файл VBS убивает другой процесс w3wp.exe, который имеет тенденцию блокироваться. Это устаревшее веб-приложение, которое мы собираемся заменить в ближайшее время, но пока нам нужно прихрамывать и принудительно закрывать приложение, когда это происходит.
Должен заметить, что убийство w3wp.exe - это не что-то I.T. профессионалы делают.
Происходит следующее: WScript.exe находится в диспетчере задач каждый раз, когда я запускаю страницу уничтожения, и никогда не исчезает.
Процесс WScript.exe (и я пробовал другие, такие как psexec.exe) запускается как локальный пользователь с правами администратора (и я пробовал другие типы пользователей, включая администраторов домена) при запуске из IIS, но он работает при запуске из командная строка на сервере.
Да, да, должно. Сетевая служба - это в лучшем случае учетная запись на уровне пользователя, и AFAIK IIRC сможет уничтожать только запущенные процессы.
Если задача выполняется на самом сервере, проще всего, вероятно, потребовать встроенную проверку подлинности Windows для страницы и ACL, чтобы ее могли прочитать только администраторы и система.
Это гарантирует, что только администраторы могут войти на страницу, и есть небольшая ответственность за то, кто убил процесс.
Еще одна мысль: вы подтвердили, что KillMyProcess.vbs надежно работает при интерактивном выполнении с cscript killmyprocess.vbs?
Я понимаю, что это не дает прямого ответа на ваш вопрос. Но разве не имеет смысла исключить IIS и ручное вмешательство пользователя из уравнения? Если не использовать фактический инструмент мониторинга (SCOM, Nagios и т. Д.), Я бы подумал, что вы могли бы написать сценарий, который периодически запускается через планировщик задач на сервере-нарушителе, который может определить, зависло ли приложение, и предпринять соответствующие действия.
Зачем ждать, пока кто-то действительно заметит проблему, а потом тратить время на ее устранение? Просто автоматизируйте проблему, пока не сможете избавиться от устаревшего приложения.