Прелюдия.

Винда 2000. Заходим под админом.


Действие.

Запускаем процесс (например cmd) программой runas от имени пользователя имеющего разрешения на убивание процессов.
Затем запускаем программу убивания. На функции OpenProcess для Id процесса cmd винда нас посылает заковыристым ругательством ERROR_ACCESS_DENIED.
Менеджер задач винды тоже не может убить этот злосчастный cmd.


Эпилог.

HEEEEEEELP !
Есть ли управа ?

ukms
Есть.
В качестве подсказки напишу SeDebugPrivilege.
Taskmgr эту привилегию себе не включает, потому и не умеет это делать.

Спасиба !

Интересно, я думал эта привилегия только к отладке имеет отношение...

Будем пробовать.

Похожий вопрос вдогонку.

Под win2000 бывает такая ситуация: хочешь убить подвисший процесс, нажимаешь "снять", и если недождавшись ответа попробовать уже "заказанный" :) процесс убить снова, начинается тоже Access Denied, только уже совсем безнадежный: не убить его больше никак.
Обидно: система работоспособность сохранила, а в памяти висит какая-то зависшая хрень и ничего с нею не поделать. Неужели только перезагрузка?

Попробовал следовать подсказке уважаемого vasketsova, нашел в Local policies параметр Debug programs и присвоил себе права на это дело наравне с админом. Но залогинен я в это время был не админом, а собой-юзверем и изменений никаких не заметил: как висело два зависших процесса и ругались на попытку снятия Access Denied - так и продолжали висеть...

Видать, в моем случае дело не в привилегиях: ведь когда я первый раз командую taskmanager'у выгрузить зависший процесс, он задание принимает(т.е. привилегии есть). Но результатов команды - никаких, и ты пытаешься убить процесс снова. И после этого его уже ничем не проймешь.

Перепробовал:
TaskMan+ v1.5 (замена Taskmanager'у, берущая себе debug-привилегии для убивания процессов, когда залогинен админом)
http://www.diamondcs.com.au/index.php?page=taskman

Kill.exe из Windows 2000 Support Tools - пишет: - ' ' could not be killed

Наконец, pskill.exe - улучшенный вариант kill.exe
http://www.sysinternals.com/ntw2k/fr.../pstools.shtml
Результат один: access denied... :(

Может быть, надо дождаться результатов первой попытки системы выгрузить зависший процесс - но иногда такое чувство, что ждать придется вечно.
Так вот, может ли в такой ситуации, когда убил процесс, система "задумалась", а ты убил его в это время снова - помочь что-нибудь, кроме перезагрузки?

AlieNET
Вопрос очень интересный, так как его решение может помочь найти защиту от убивания своих процессов. Необходимо уточнение. Что это за процесс? Права пользователя, дающего задание на снятие процесса (админ, адвансед, кастом)?

hasherfrog
Компьютер только мой, Win2000 Pro SP4, когда я вышеприведеные "убивалки" испытывал, был залогинен админом. Процесс - это ReGet Deluxe 3.3b178, обработанный "волшебной файлочкой" ;) от ROR'а. У меня стоит ZoneAlarm, и когда ReGet Update пытается выйти в сеть, я ему запрещаю это напрочь(самому regetdx.exe качать разрешено). После очередного "облома" апдейта запустивший его regetdx не может выйти в инет(не висит, но качать не может).

Тогда я запускаю новый регет, появляется окошко, предлагающее закрыть одноименный более ранний процесс(типа: close, retry, cancel). Жму на Close, новый регет запускается и работает без проблем, но старый процесс с таким же именем продолжает висеть в памяти, и ничем его не убьешь!
Иногда доходит до трех копий регета, висящих в процессах.

Может ли окошко access denied означать не отсутствие привилегий(я ж админ?!), а то, что к процессу не пробиться, т.к. он не отвечает - так крепко завис? Ведь когда я жму на close, запуская вторую копию регета, система делает первую попытку убить процесс. После этого я пытаюсь его снять снова и снова, и все время получаю access denied.
Избавляет от этих "призраков" только перезагрузка, а это обидно: система то вполне работает и не тормозит, а выгрузить зависших регетов - не может... :(

Добавлено:

Тут что-то связано с тем, что зависающие процессы пытаются выйти в интернет. Помимо случая с регетом у меня недавно был аналогичный с eMule - поставил 5-ую версию ZoneAlarm, и она стала вешать мне осла, а вместе с ним и win2000! Откатился до ZA 4.5 - все работает великолепно. Без участия интернета неразрешимых (без перезагрузки) проблем с Вин2К у себя не припомню.

AlieNET
Точно такая же ситуация. Только я думал, че-то с ослом не то - переставил на более раннюю версию - через какое-то время все то же самое началось - напрочь зависает, спасает только ребут.

AlieNET
Вы не могли бы с помощью PsExplorer (так кажется) от www.sysinternals.com посмотреть на ресурсы и свойства процесса Reget (до и после зависания)? Может, что-то прояснится.

hasherfrog
Отправил вам свой ReGet вместе с патчем(1.6Мб). Велика вероятность, что он будет также "мерзнуть" в процессах, что и у меня. Т.к. эта же история была и под Win98 - т.е. дело не в конкретной ОСи. Если все "заработает как надо" ;) , думаю, вы сможете раздобыть гораздо больше информации, чем я.
*может потребоваться стенка ZA 4.5, но есть такое чувство, что всё получится и сдругой стенкой, или даже без неё.
**в архиве также текстовик с ресурсами процесса до и после зависания - надеюсь, пригодится.

Если глюков не будет - тогда постараюсь выслать вам инфу о зависаниях, добытую при помощи TaskInfo2003 - эта прога умеет копировать данные в буфер, только скажите - что интересует.

По прежнему думаю, что дело связано с завязками процесса ReGet на какиме-то ресурсы системы, которые помогают ему выйти в интернет. Зависание тут возможно провоцирует файрвол. В результате процесс убиваешь, а часть, которая связана с этими ресурсами система убить не может - и получается "призрак". Повторюсь, что если Win2000 у меня и глючит крепко - то только в связи с программами, лезущими в онлайн. Система плохо убивает процессы, имеющие отношение к сети - знать бы, почему...
*если убить телефонию, например, а потом запустить её снова - коннекта нет, приходится перезагружаться.

У меня новая информация. Сегодня после экспериментов опять образовалось 3 зависших копии регета. Но я не стал ни на одну из них повторять команду "убить процесс". Команда шла только один раз: когда при открытии новой копии программы предлагалось убить старую - я отвечал close её. После этого я забыл про эти процессы-призраки и вспомнил о них... часов через 6, когда кончился интернет и надо было перезагружать систему: смотрю... - а нету их! Все чистенько. Но висели они от команды close до исчезновения никак не меньше 3 часов.
Самая вероятная версия: это связано с онлайном. Пока ты в онлайне, убить дорвавшийся до него регет до конца нельзя. Стоит из онлайна выйти - становится проще.
Вторая версия: если не долбить повторные команды kill, системе закончить процесс легче, и (всего через каких-то 3-4 часа...) она это сделает.
Но надо будет поэксперементировать.
Все равно странно: другие проги, вроде FlashGet или eMule, порешаются без проблем, независимо от состояния соединения.

AlieNET
Всё никак не дойдут руки, не хватает времени. Некоторые общие соображения уже есть: службы+SERVICE_CONTROL_STOP+триды+NTAUTORITY/SYSTEM. Более нормальным языком пока не могу ничего объяснить :(

hasherfrog
Спасибо, что вообще взялись помочь. :) А так мне не к спеху: все, в принципе, работает. Зависания эти мешали мне корректно закрывать винду, но если не kill'ить регеты-призраки повторно после команды close, они в конце-концов исчезают - постараюсь пока так и делать. Но узнать, почему регет так трудно прибивается было бы очень интересно.
Кстати, у регета очень хитрая интеграция с MSIE - не влияет ли она? У меня всегда включена "низкоуровневая".

А вообще регет крутейшая качалка! На днях меня выручил: удалось присосаться к одному редкому файлу, несмотря на все ява-скрипты(за счет MSIE Spy). Буду теперь 4 версию искать.

Именно.

hasherfrog
Поставил версию 4 регета - началось все то же самое... Сейчас поменял ZA на Outpost 2.1 Pro - глючить перестало. Интеграция по прежнему включена "низкоуровневая". Так может, дело в стенке?

AlieNET
То что именно "стенка" является причиной ошибки, понятно. С самого начала, собственно :) Меня-то интересует вопрос о невозможности снять зависший процесс, а не причина его "зависания". Разница в работе стенок, скорее всего, вот в чём: OutPost при попытке открыть программой сокет на запрещённом порту сразу посылает её куда подальше. А ZA делает по-другому: он говорит "сейчас, сейчас", "подвешивая" соединие. Т.е. ZA постоянно возвращает EAGAIN на попытку accept'а. Или ETIMEDOUT на попытку connect'а. Очевидно, участок кода, отвечающего за соединение, находится где-то в критикал-секшион одного из многочисленных треадов, устанавливающих соедиения.  И попытка снять с выполнения такой процесс затормаживается, поскольку основнойй процесс пытается дождаться завершения вторичных (тех, что с соедиениями), а они никак не могут отлепится от ZA. Почему нет прав на вторичное снятие - потому что система уже пытается снять процесс и ждёт когда он ей скажет (так, тут туман пошёл) что он готов завершиться. И Вы снимаете уже снятие процесса, а это нельзя. Дальше сплошной туман. Интеграция в IE, взаимодействие со службами...

Ну, если Вас интересовало, как избавится от проблемы, то Вы нашли решение, отлично! Собственно, дальше можно не копать. А теория подождёт... Я по-прежнему не могу занятся reget'oм вплотную, сорри :(

hasherfrog
А насколько я усугубляю ситуацию повторными попытками снятия процесса, как Вы думаете? Меня волнует: я этим завешиваю процесс сильнее или нет: просто система ждет возможности закрыть процесс и когда дождется, закроет его не менее успешно (и быстро) чем без повторных попыток?
Просто мне нравится Win2000 и не хочется думать, что от повторных попыток снятия она входит в ступор.

С регетом я понимаю - туман большой. Но мне с ним особой помощи и не надо уже, разберусь. Вы мне многое предыдушим постом своим объяснили. Спасибо.

П.С.
А ZoneAlarm-то, ушлый какой: "сейчас, сейчас..." :biglaugh:

AlieNET
Ненамного. Дело в том, что для окончания снятия процесса (по TerminatiProcess) система ждёт, когда процесс (все его триды) закончит все операции по вводу/выводу.
Кстати. Я тут попытася воссоздать ситуацию программно, но у меня ничего не вышло (к тому же практического значения, имхо, всё-таки маловато получается). Я ожидаю WaitSignleObject (XP, кстати, не 2к) на "подвешенном сокете, но система благополучно разрешает ситуацию. Но у меня нет ZA, а ситуацию я прсто эмулировал, поэтому и не вышло. В линуксе та же ситуация срабатывает - пока не кинут SIGKILL, я "висю" на аксепте до посинения :).

Вот ещё, что я забыл проверить...
Чтобы это значило? Ладно, как руки дойдут...

hasherfrog
Самая приятная новость - что Вин2К не виновата(на днях впервые увидел, как система сама выгрузила "дважды убитый" зависший сетевой процесс. Раньше я думал, что она на это не способна).
Не утешает сложность вопроса, особенно что касается таких вот хитросплетений триад системных + сетевых процессов, ч.з. куда интегрированного MSIE, стенки вроде ZA... :o Устаю я от этих разбирательств - потому что не понимаю общих принципов работы оси пока...