> Что действительно может тревожить, так это созданные этим > процессом другие процессы и т.д. Ну, это то как раз я уже решил. Рекурсивно обхожу дерево процессов начиная с некоторого @#$%, заношу в массив потомков, которых потом убиваю с "хвоста"
> Побеждается заданиями. Но только они начиная с 2K появились > (возможно есть в Ме- нужно посмотреть). > А вот в "до 2К" есть место для творчества. Это как это? Не мог бы ты поподробнее рассказать.
Хочу для Win98 отгрузить dll-ки по заданному PID. Нацарапал процедурку, корректность которой мне сомнительна, т.к. при закрытии того приложения, которое разгружаем возникает Exception типа AccessViolation.
VOID UnloadPIDModules32(DWORD dwPID)
{ MODULEENTRY32 me32 ;
HANDLE hSnapModule ;
int CountUse ;
hSnapModule = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, dwPID);
if(hSnapModule != NULL)
{
ZeroMemory(&me32,sizeof(MODULEENTRY32));
me32.dwSize = sizeof(MODULEENTRY32);
if(Module32First(hSnapModule, &me32))
{// первый в списке ехе - не нужен
while(Module32Next(hSnapModule, &me32))
{ CountUse = me32.ProccntUsage ;
while(CountUse != 65535 && CountUse > 0)
{ FreeLibrary(me32.hModule);
CountUse -- ;
}
}
}
CloseHandle(hSnapModule);
}
}
И еще правильно ли я понял - когда me32.ProccntUsage==65535 библиотека невыгружаемая?
Выгрузка модулей других процессов.17.07.02 08:45 Автор: ggg <ggg> Статус: Elderman
вообще странная задача - выгружать модули из работающего процесса - он же может их использовать
и если правильно выгрузить, то само собой процесс должен вываливаться
только странно ты выгружаешь
MSDN: "MODULEENTRY32::hModule - Handle to the module in the context of the owning process."
и ещё "Calling FreeLibrary does not affect other processes using the same library module."
Выгрузка модулей других процессов.17.07.02 11:00 Автор: Xan Статус: Незарегистрированный пользователь
> вообще странная задача - выгружать модули из работающего > процесса - он же может их использовать > и если правильно выгрузить, то само собой процесс должен > вываливаться Попробую объяснить зачем это нужно. Уже вторую неделю меня реально парит тема о зачистке рессурсов при завершении работы программ. Предположим я рождаю процесс с ехе-шником от левого производителя, о работе которого я ничего не знаю. Я начинаю его закрывать. - получаю список нитей, зная PID, пытаюсь закрыть их и если в итоге процесс еще жив вызываю TerminateProccess(). Но вопрос: а если перед этим были загружены библиотеки, динамически выделялась память и т.д. Как это освободить и НУЖНО ЛИ ВООБЩЕ это делать. Не знаю. Подскажите плз.
ЗЫ
"Ya stranen a ne stranen kto zh? Tot kto na vseh gluptsov pohozh"
Лучше чем удаляет ОС - сделать трудно17.07.02 11:22 Автор: ukv Статус: Незарегистрированный пользователь
При удалении процесса вся локальная память удаляется операционной системой вместе с адресным пространством процесса - здесь никаких проблем. Что может не удалиться - так это глобальные объекты - области памяти или GDI ресурсы. Но не зная логики работы программы удалить их практически невозможно - поди найди в сторонней программе нужные HANDLE. То же касается некоторых открытых файлов.
Так что удалить процесс лучше, чем это делает операционная система - задача на мой взгляд малореальная.
[Win32] Лучше чем удаляет ОС - сделать трудно17.07.02 21:29 Автор: Biasha <Бяша> Статус: Member
> Что может не удалиться - > так это глобальные объекты - области памяти или GDI > ресурсы.
Что, например, конкретно?
> Но не зная логики работы программы удалить их > практически невозможно - поди найди в сторонней программе > нужные HANDLE. То же касается некоторых открытых файлов.
Это ж каких таких, некоторых?
> Так что удалить процесс лучше, чем это делает операционная > система - задача на мой взгляд малореальная.
И, вероятно, невозможная в пользовательском режиме.
Что действительно может тревожить, так это созданные этим процессом другие процессы и т.д.
Побеждается заданиями. Но только они начиная с 2K появились (возможно есть в Ме- нужно посмотреть).
А вот в "до 2К" есть место для творчества.
[Win32] Лучше чем удаляет ОС - сделать трудно19.07.02 10:23 Автор: Xan Статус: Незарегистрированный пользователь
> Что действительно может тревожить, так это созданные этим > процессом другие процессы и т.д. Ну, это то как раз я уже решил. Рекурсивно обхожу дерево процессов начиная с некоторого @#$%, заношу в массив потомков, которых потом убиваю с "хвоста"
> Побеждается заданиями. Но только они начиная с 2K появились > (возможно есть в Ме- нужно посмотреть). > А вот в "до 2К" есть место для творчества. Это как это? Не мог бы ты поподробнее рассказать.
[Win32] Лучше чем удаляет ОС - сделать трудно19.07.02 21:31 Автор: Biasha <Бяша> Статус: Member
> > Что действительно может тревожить, так это созданные > > этим > > процессом другие процессы и т.д. > Ну, это то как раз я уже решил. Рекурсивно обхожу дерево > процессов начиная с некоторого @#$%, заношу в массив > потомков, которых потом убиваю с "хвоста"
А если один из процессов дерева уже завершился?
Как ты найдёшь внука умершего сына?
> > Побеждается заданиями. Но только они начиная с 2K > > появились > > (возможно есть в Ме - нужно посмотреть). > > А вот в "до 2К" есть место для творчества. > Это как это? Не мог бы ты поподробнее рассказать.
Никогда такого не делал. Рихтер в своей книге писал, что "эта" технология используется VS 6.0 для завершения порождённых процессов при нажатии стоп при сборке проекта. Писал, что она очень не проста и он описывал её в своей колонке такого-то журнала.
Я так подозреваю там используется перехват CreateProcess. Но лучше найди этот журнал (может быть он даже в MSDN есть).
[Win32] Лучше чем удаляет ОС - сделать трудно18.07.02 10:54 Автор: ukv Статус: Незарегистрированный пользователь
> > Что может не удалиться - > > так это глобальные объекты - области памяти или GDI > > ресурсы. > > Что, например, конкретно?
Зависит от версии Виндов. Кое-где встречаются объекты типа HGLOBAL (вроде как остались в наследство от 16-битных приложений), но как себя будет вести себя с ними W98 и W2К при аварийном завершении процесса - предсказать не берусь. Однако
утечка памяти и GDI ресурсов в некоторых версиях виндов - вполне реальная вещь. Значит операционная система не умеет полностью собирать мусор за плохо написанным приложением (или некорректно завершенным).
> То же касается некоторых открытых > файлов. > > Это ж каких таких, некоторых?
Неужели никогда не приходилось сталкиваться с "неудаляемыми" файлами при некорректном завершении некоторых программ? Как такое организовать "вручную" - сказать не берусь, но в первую очередь попробовал бы FileMapping, да еще со всякими наследуемыми свойствами.
[Win32] Ой страшно...18.07.02 21:49 Автор: Biasha <Бяша> Статус: Member
> > > Что может не удалиться - > > > так это глобальные объекты - области памяти или > > > GDI > > > ресурсы. > > > > Что, например, конкретно? > > Зависит от версии Виндов.
Вот уж интересно.
> Кое-где встречаются объекты типа > HGLOBAL
Да, Win32 API тоже можно назвать кое-где.
> (вроде как остались в наследство от 16-битных > приложений),
Так и есть.
The global and local functions supported for porting from 16-bit code, or maintaining source code compatibility with 16-bit Windows.
> но как себя будет вести себя с ними W98 и W2К > при аварийном завершении процесса - предсказать не берусь.
А я возьмусь. При завершении процесса (пофиг аварийном или нет) его адресное пространство будет уничтожено. Следовательно вся выделеная им виртуальная и физическая память будет освобождена (за исключением физической памяти, используемой другими процессами).
> Однако > утечка памяти и GDI ресурсов в некоторых версиях виндов - > вполне реальная вещь.
Да, говорят в каждом компе сидит злой Билл и глючит его...
> Значит операционная система не умеет > полностью собирать мусор за плохо написанным приложением > (или некорректно завершенным).
Бил там обязательно сидит, ведь иначе почему компы глючат?
> > То же касается некоторых открытых > > файлов. > > > > Это ж каких таких, некоторых? > > Неужели никогда не приходилось сталкиваться с > "неудаляемыми" файлами при некорректном завершении > некоторых программ?
Я конечно дико извиняюсь, но, ксожалению, не приходилось. :(
> Как такое организовать "вручную" - > сказать не берусь, но в первую очередь попробовал бы > FileMapping, да еще со всякими наследуемыми свойствами.
Наследуемое свойство означают лишь, что он буде автоматически открыт в порождённом процессе.
Как только будут закрыты все дескрипторы всех процессов, открывших FileMapping (при завершении процесса они будут закрыты автоматически) FileMapping будет благополучно удалён.
если я прально понял ты хочешь выгрузить уже загруженные модули из рабочего процесса...
хм... работает некая прога, которая LoadLibrary + GetProcAddress получает адрес некой void FuckUser() которую вызывает периодически...
ок... ты выгружаешь модуль => VirtualFree.
только твоя прого снова пытаеца вызвать FuckUser() - вот тебе и exception.
как вариант: попробуй сначала заморозить (SuspendThread ) все потоки процесса и потом выгрузить модули. хотя может не сработает изза того что возможно сглючт DllEntryPoint (DLL_DETACH...). если вылетает исключение - то видимо проблема не в том что происходит обращение по освобожденному адресу а какая то другая...
короче я тут пишу и уже забыл с чего начал... пора и поспать уже :)
надеюсь я не полный бред написал...
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
