Как убить процесс, не получив исключения "процесс вышел"?

Я использую Process.Kill(), чтобы убить процесс. Вот так:

if( !process.WaitForExit( 5000 ) ) {
   process.Kill();
}

и иногда процесс будет выходить прямо между строк, поэтому управление попадет внутрь if, а затем Kill даст исключение:

System.InvalidOperationException
Cannot process request because the process (ProcessIdHere) has exited.
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.Kill()
//my code here

Теперь обертка кода в try-catch не кажется хорошей идеей, потому что InvalidOperationException можно вызвать по другим причинам.

Есть ли способ убить процесс без исключения в описанном сценарии?

Ответы

Ответ 1

Вы можете P/Invoke TerminateProcess передать его Process.Handle. Затем вручную оценивает причину этого (GetLastError()). Что грубо говоря, что Process.Kill() делает внутренне.

Но обратите внимание, что TerminateProcess является асинхронным. Таким образом, вам придется подождать в дескрипторе процесса, чтобы убедиться, что это сделано. Использование Process.Kill() делает это для вашего.

Обновление: Коррекция, Process.Kill() также выполняется асинхронно. Поэтому вам придется использовать WaitForExit(), чтобы дождаться завершения завершения - если вам все равно.

Честно говоря, я бы не стал беспокоиться. Конечно, всегда есть (удаленная?) Вероятность того, что из этой строки кода выскочит какой-то "произвольный" InvalidOperationExcepion, который не связан с тем, что процесс больше не существует, или объект Process недействителен но на самом деле я думаю, вы можете просто пойти с try/catch вокруг Kill.

Кроме того, в зависимости от вашего приложения, вы можете рассмотреть возможность записи этого убийства в любом случае, поскольку он кажется какой-то последней мерой. В этом случае запишите с ним фактический InvalidOperationException. Если все странно, вы, по крайней мере, имеете свои журналы, чтобы проверить, почему сбой Kill.

Имея все сказанное, вы также можете рассмотреть возможность ловить/обрабатывать Win32Exception по тем же причинам.