Безопасно убить процесс из файла .bat
У меня есть приложение VB6, которое нужно обновить самостоятельно. Для этого PM рекомендовал использовать командный файл, который должен запускаться из приложения. Пакетный файл должен убить процесс, загрузить новую версию с локального сервера, перезаписать старые файлы и снова запустить приложение. Моя проблема в том, что я не уверен, что taskkill вернет управление родительскому элементу только после того, как процесс был убит и все использованные ресурсы были освобождены; в частности, нам было интересно, что происходит с файлом .exe процесса. Есть ли гарантия, что он будет разблокирован после возврата тасккилла? - конечно, теоретически он не должен блокироваться никаким другим процессом, это единственный интересующий нас случай.
Ответы 4
Имейте параметр командной строки, например / Shutdown, который будет обрабатывать программа VB.
MyApp.exe / Завершение работы
Параметр / Shutdown найдет существующий запущенный экземпляр приложения (с помощью FindWindow API) и отправит пользователю сообщение в окно с запросом на плавное завершение работы.
Taskkill должен возвращаться только после завершения процесса (согласно комментариям ниже: используйте флаг / F для принудительного завершения программы, если она ожидает ввода пользователя).
Чтобы узнать больше об этом, вы можете использовать Обозреватель процессов и точно увидеть, когда процесс завершен, а также, если у кого-то еще открыт файл .exe (Ctrl + F и имя exe), но этого не должно быть.
Это не так, и это просто проверить. Откройте блокнот и введите что-нибудь, не сохраняя его, затем запустите taskkill / im notepad.exe. Вы увидите, что taskkill возвращает управление, пока блокнот спрашивает, хотите ли вы сохранить документ перед закрытием.
Если процесс завершается, ресурсы (память, дескрипторы файлов) всегда должны быть освобождены ОС.
@Jeff - это так, если вы используете флаг / F
@rslite - верно, но я не об этом, я хотел доказать, что taskkill вернется, пока приложение все еще работает и пытается закрыть.
it does if you use the /F flag Это небезопасное убийство - как будто вопрос явно задается.
@Synetech - вроде как поздно для оригинального плаката, но в любом случае он хочет убить приложение, чтобы оно могло заменить файл .exe. Приложение можно запрограммировать на высвобождение всех ресурсов перед запуском процесса обновления. Нет ничего безопаснее этого. Флаг / F гарантирует, что в любом случае приложение будет закрыто.
Если процесс прерван, исполняемый файл будет освобожден для обновления. В качестве альтернативы использованию taskkill вы можете использовать pskill из sysinternals, но taskkill должен отлично работать с параметром / IM.
Однако ни pskill, ни taskkill не будут ждать остановки процесса перед возвратом управления. Таким образом, вам придется отслеживать процессы, чтобы убедиться, что они больше не работают.
Кроме того, и это было бы моим предпочтительным решением, можно развернуть приложение vb6 с помощью однократного щелчка, что автоматически обновит приложение новыми выпусками. Подробности см. В эта статья.
Что касается ресурсов, открытых процессом, возможно, они останутся открытыми (например, соединение sql), но, скорее всего, они будут успешно закрыты. Вы сможете узнать наверняка, только наблюдая за происходящим, протестировав taskkill в процессе.
Надеюсь, это поможет.
PSKill "распознается" некоторыми шпионскими программами и сканерами вирусов как нечто плохое. Вы должны знать об этом при распространении приложения.
@GvS - это очень хороший аргумент, и я уже сталкивался с той же проблемой раньше с McAfee Enterprise.
Я делаю это, позволяя самому приложению проверять наличие обновлений. Если есть, то приложение загружает их во временное место. После этого он запустит (.js) скрипт и выйдет из приложения. Этот скрипт будет ждать, пока процесс закроется (спит), скопирует обновления и снова запустит приложение.
Таким образом, у вас будет гораздо меньше логики в сценарии, и вы можете делать свои вещи в среде, у которой есть больше инструментов.
Процесс был остановлен, но были ли освобождены использованные ресурсы? Это мой вопрос.