BugTraq.Ru: форум / programming / [Win32] Ой страшно...

информационная безопасность
без паники и всерьез

подробно о проекте

Анализ криптографических сетевых...

Модель надежности двухузлового...

Специальные марковские модели надежности...

Бэкдор в xz/liblzma, предназначенный...

Три миллиона электронных замков...

Doom на газонокосилках

bugtraq.ru / форум / programming

Имя

Пароль

если вы видите этот текст, отключите в настройках форума использование JavaScript


ФОРУМ


регистрация

Легенда:

новое сообщение

закрытая нитка

новое сообщение

в закрытой нитке

старое сообщение

Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
Новичкам также крайне полезно ознакомиться с данным документом.

[Win32] Ой страшно... 18.07.02 21:49 Число просмотров: 951
Автор: 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 будет благополучно удалён.

Выгрузка модулей других процессов. 16.07.02 12:34
Автор: Xan Статус: Незарегистрированный пользователь

<"чистая" ссылка>

Хочу для 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

<"чистая" ссылка>

[Win32] Выгрузка модулей других процессов. 17.07.02 04:46
Автор: BXS Статус: Незарегистрированный пользователь

<"чистая" ссылка>

если я прально понял ты хочешь выгрузить уже загруженные модули из рабочего процесса...
хм... работает некая прога, которая LoadLibrary + GetProcAddress получает адрес некой void FuckUser() которую вызывает периодически...
ок... ты выгружаешь модуль => VirtualFree.
только твоя прого снова пытаеца вызвать FuckUser() - вот тебе и exception.

как вариант: попробуй сначала заморозить (SuspendThread ) все потоки процесса и потом выгрузить модули. хотя может не сработает изза того что возможно сглючт DllEntryPoint (DLL_DETACH...). если вылетает исключение - то видимо проблема не в том что происходит обращение по освобожденному адресу а какая то другая...

короче я тут пишу и уже забыл с чего начал... пора и поспать уже :)
надеюсь я не полный бред написал...

Page build time: 0 s

Design: Vadim Derkach