Dll в памяти.

← →
Evgeniy_K (2003-12-28 11:29) [0]

Как найти в памяти dll и выгрузить ее. Известно только имя файла dll.

← →
Opuhshii (2003-12-28 12:41) [1]

см. toolhelp32, + ProcessTerminate или FreeLibrary и CreateRemoteThread,

да кстати, в чьей памяти?

← →
Evgeniy_K (2003-12-29 11:04) [2]

В памяти Windows. Задача такова: есть приложение, оно завесилось, нужно выгрузить из памяти dll, которую оно использует, чтобы можно было перезапустить приложение.

← →
Digitman (2003-12-29 11:42) [3]

> чтобы можно было перезапустить приложение

.. нужно просто его "перезапустить" и не выкрутасничать с тем, о чем ты имеешь слабое теоретическое представление

аварийное снятие "зависшего" процесса с выполнения - см. TerminateProcess()
при этом заботиться о "выгрузке" модулей , используемых ДАННЫМ процессом, не нужно - система сама это сделает не хуже (и корректней) тебя

← →
Evgeniy_K (2003-12-29 13:12) [4]

Если бы всегда срабатывало бы, то не спрашивал бы!

← →
Digitman (2003-12-29 13:23) [5]

> Если бы всегда срабатывало бы

а что, собственно, не "срабатывает" ? TerminateProcess() ?

← →
Digitman (2003-12-29 13:27) [6]

прямо-таки расчудесное объяснение проблемы : я ,мол, сел за руль автомобиля, а он не едет почему-то ! Не срабатывает ! А, мол, еслт ли у меня в баке бензин и ли еще чего-нть у меня в машине нет - догадайтесь, мол, сами ! Не царское эт дело - объяснять еще всяким , чего тут у меня "не срабатывает" и какого хрена при наличии машины я никуда не еду на ней)

← →
Evgeniy_K (2003-12-29 15:40) [7]

Конкретный вопрос поставлен в теме ветки.

← →
Digitman (2003-12-29 15:55) [8]

> Конкретный вопрос поставлен в теме ветки

в "конкретном" вопросе - не менее "конкретное" непонимание механизмов работы PE-загрузчика Win32, и на таком уровне ответ на вопрос один : никак.

решение будет подсказано ТОЛЬКО при ответе на [5]

← →
YuRock (2003-12-29 16:45) [9]

> В памяти Windows
???

Тяжело понять вопрос... Но может поможет это:

FreeLibrary(GetModuleHandle("<имя длл>"));

← →
Digitman (2003-12-29 17:25) [10]

> YuRock

Юрок, тебе тоже не жалко ящика шнапса ?)

← →
YuRock (2003-12-29 17:30) [11]

> Digitman

:)) МИНЗДРАВ предупреждает...

← →
Digitman (2003-12-29 18:13) [12]

> МИНЗДРАВ предупреждает...

эт точно) ... предупреждает : не несите чепухи) ... и не прыгайте с бубном, если не знаете для чего и когда нужен бубен)

← →
YuRock (2003-12-29 18:41) [13]

>не несите чепухи) ... и не прыгайте с бубном, если не знаете для чего и когда нужен бубен)

О... Щас нам великий Delphi-мастер прочитает познавательную мораль...
Есть одна истина: "Свое мнение не всегда правильно". Так что не следует навязывать его другим

← →
Woodpecker (2003-12-29 18:49) [14]

2 YuRock
Прежде чем пустозвонить Рихтера почитал бы или что-нить в ентом роде.

← →
Digitman (2003-12-29 18:50) [15]

> [13]

на редкость серьезная заява !)
приятно и чрезвычайно полезно-познавательно было бы послушать аргументы в пользу оной)

← →
YuRock (2003-12-29 18:51) [16]

(Стараясь никого не обидеть): мне кажется, форумы нужны для того, чтобы отвечать на поставленные вопросы, а не читать морали.

Вопрос: "Как найти в памяти dll и выгрузить ее. Известно только имя файла dll."
Ответ: "FreeLibrary(GetModuleHandle("<имя длл>"))"

← →
Digitman (2003-12-29 18:53) [17]

да Рихтер нам не указ ! Как известно)..
Мы его - хрясь ! - и by FreeLibrary() call "выгрузили", их хрен знает какой "памяти") .. коль завис он тут со своими "умными" мыслями на несколько сотен страниц текста, которые нам читать не к чему и недосуг)

← →
YuRock (2003-12-29 18:54) [18]

> [16] Другое дело, что это не поможет закрыть dll для ругих процессов, но каков вопрос, таков и ответ

← →
Digitman (2003-12-29 18:55) [19]

> YuRock © (29.12.03 18:51) [16]

ну так и где ж ты ее, сударь, ищешь ?) DLL-то ? в своем Freelibrary() ?
и в какой такой, пардон за назойливость, "памяти" ?

← →
YuRock (2003-12-29 19:02) [20]

Глубокоуважаемый господин Сергей Digitman, я не хочу с вами спорить (тем более, что мы оба знаем, что Вы правы), я просто хотел бы еще раз подчеркнуть, что нужно стараться помочь спрашивающему, а не стараться показать ему и отвечающим на его вопрос (в том числе и мне) их незнание предметной области.
Тем более это обидно, когда не обосновано.

← →
Evgeniy_K (2003-12-30 08:00) [21]

Полностью знает Виндоус только Майкрософт. Так что твой механизм может быть всего лишь иллюзия ;-)

Проблема такова:
Приложение вылетело, но dll в памяти осталась. Приложение в памяти нет. Перезапустить прилождение не удается, потому что dll уже загружена и завешена в памяти. Такое редко, но бывает!

← →
Digitman (2003-12-30 08:41) [22]

> Приложение вылетело

КУДА "вылетело" ? ЧТО значит "вылетело" ? Процесс снят с выполнения или не снят ?

> dll в памяти осталась

Если процесс уже не существует, тот никаких модулей в его ВАП нет, ибо нет самого ВАП

> Перезапустить прилождение не удается

Симптомы ? Сообщения какие ? ЧТО система говорит в ответ на попытку ?

> dll уже загружена и завешена в памяти

модуль НЕЛЬЗЯ завершить ! это - нонсенс
ЭКЗЕМПЛЯР библиотеки в виде программного модуля либо отображен на ВАП процесса либо не отображен. третьего не дано.

← →
KosilkA (2003-12-30 10:35) [23]

а если dll внедрена в ВАП сторонннего процесса ,например эксплорера , по принципу вируса? как такое прибить , кстати?

← →
YuRock (2003-12-30 10:41) [24]

Такое бывает, если библиотеку использует еще один процесс. Если нет - винда выгружает ее из памяти.

> Digitman © К стати говоря, если уж совсем по-научному, то библиотека грузится только раз (при первом LoadLibrary()), а при следующих только возвращается ее готовый хендл (даже если грузить из другого процесса).
И этому есть логичное объяснение: хендл библиотеки - это ни что иное, как указатель на структуру заголовка библиотеки, и нет никакой необходимости делать новый экземпляр этой структуры.

В данном случае может быть две причины - либо текущий процесс не завершен, либо dll используется другими программами

← →
Digitman (2003-12-30 11:10) [25]

> если уж совсем по-научному

ну давай "по-научному", коль настаиваешь)

> библиотека грузится только раз

"грузится" она столько раз, сколько процессов хотя бы однократно затребовали ее загрузку

> при следующих только возвращается ее готовый хендл (даже
> если грузить из другого процесса).

это как ?) загрузка осуществляется в контексте конкретного код.потока конретного процесса ! как ты себе это представляешь - "грузить из другого процесса" ? ерунда же полная !

> хендл библиотеки - это ни что иное, как указатель на структуру
> заголовка библиотеки

хэндл PE-модуля имеет смысл для конкретного процесса, ибо это, в первую очередь, loaded image base address, который в разных процессах вполне может быть разным.

> и нет никакой необходимости делать
> новый экземпляр этой структуры.

в контексте ДАННОГО рассматриваемого процесса - да, необходимости нет

в контекстах БОЛЕЕ чем одного процессов системой будет создано столько экз-ров, сколько процессов затребовали загрузку модуля

> либо текущий процесс не завершен

автора утверждает якобы иное - "Приложение вылетело.. Приложение в памяти нет"

> либо dll используется другими программами

да ну и на здоровье ! пусть используется ! как это может помешать старту еще одного процесса, использующего этот модуль ? в дан.случае - повторному старту процесса авторского приложения ?

вот это мне совершенно непонятно) .. ибо автор никак не хочет (или не в состоянии) вразумительно объяснить, что мешает повторному старту процесса ...
да мало ли какие другие процессы используют в этот момент этот модуль ! как это влияет на ДАННЫЙ процесс ? чем это он так уж радикально отличается от других процессов ? совершенно неясно) ...

← →
Digitman (2003-12-30 11:14) [26]

резюме всего этого просто как лапоть : для того ПРИНУДИТЕЛЬНО "освободить" файл PE-модуля, необходимо тем или иным образом терминировать все процессы, использующие в данный момент этот PE-модуль

← →
Digitman (2003-12-30 11:36) [27]

поэтому оригинальный вопрос

> Как найти в памяти dll и выгрузить ее

выглядит по меньшей мере странным, ибо неизвестно, о КАКОЙ епямяти идет речь, о ВАП какого процесса (текущего или произвольного) ..

если текущего, то - полный нонсенс : текущего либо уже нет (он "вылетел" куда-то) либо он "висит" (в первом приближении так скажем)

если иного, то собственно поиск модулей не составляет труда - на то есть хотя бы штатный psapi.. а вот выгрузка - это (FreeLibrary) должен сделать каждый код.поток локализованного процесса, который ранее сделал LoadLibrary()

← →
YuRock (2003-12-30 11:37) [28]

> Digitman ©
> "грузится" она столько раз, сколько процессов хотя бы однократно затребовали ее загрузку

Не совсем правда. Когда первый процесс первый раз загружает dll, система грузит ее "с нуля", полностью считывая ее заголовок в созданный для этого экземпляр структуры (не помню, как называется). При последующем же вызове LoadLibrary(), система лишь возвращает указатель на этот экземпляр этой структуры. Это легко посмотреть на примере:
program Test; uses Windows, Dialogs, SysUtils; begin ShowMessage(IntToStr(LoadLibrary("kernel32.dll"))); end.
Запуская несколько раз такую программу, можно заметить: хендл библиотеки будет одним и тем же - что это, совпадение? Нет! Просто он лежит вне адресного пространства приложения.

Удаляется же он только когда последний процесс, работавший с этой dll, закрылся (когда вызвано последнее FreeLibrary).
Использующиеся же в каждом из процессов части заголовка баблиотеки и сам заголовок - разные вещи. Процесс имеет информацию лишь о таких некоторых вещах (например, таблица адресов загруженных ч-з GetProcAddress() функций.

> грузить из другого процесса

Я имел в виду повторно (наприме, в другом процессе вызвать LoadLibrary)

← →
Digitman (2003-12-30 11:42) [29]

к тому же если UsageCount модуля некоего процесса = -1 (это значение соответствует факту стат.загрузки модуля на этапе старта и иниц-ции процесса, осн.модуль которого статически импортирует ф-ции интересующего модуля), то никакие FreeLibrary в контекстах его код.потоков не смогут "выгрузить" модуль из ВАП данного процесса - модуль будет "выгружен" ТОЛЬКО по факту штатного (ExitProcess) либо аварийного (внутренняяя GPF или внешний вызов Terminateprocess) снятия процесса с выполнения

← →
Digitman (2003-12-30 11:44) [30]

> Просто он лежит вне адресного пространства приложения.

чушь несусветная
читай хотя бы Рихтера)

← →
YuRock (2003-12-30 11:47) [31]

Я не знаю, кто такой Рихтер и что он писал, но хотябы читай то, на что отвечаешь. Ты хоть понял, что я написал?

← →
Digitman (2003-12-30 12:00) [32]

> YuRock

экз-ров секций данных модуля столько, сколько процессов хотя бы однократно вызвали LoadLibrary()

экз-р секции кода модуля по началу единственный (по кр.мере - в физ.памяти), но до момента первого обращения к страницам секции по записи (если таковую разрешить, по умолчанию - запрещена) ... далее же поведение разных систем разное : NT-based системы устанавливают атрибут страниц кода как COPY_ON_WRITE, и попытка записи в некую кодовую страницу модуля приводит к немедленной создании копии страницы; Win9x-based системы отражают изменения кодовой страницы модуля для всех процессов, в ВАП которых секция кода модуля отображена (т.е. единственный , разделяемый между всеми процессами, экз-р кода модуля)

НО ! секции данных PE-модуля всегда по умолчанию мультиэкземплярны в рамках системы и заинтересованных в использовании модуля процессов ... стандартный линкер от Borland Delphi не позволяет управлять изменением соотв.флагов секции данных создаваемого им PE-модуля

← →
YuRock (2003-12-30 12:03) [33]

> то никакие FreeLibrary в контекстах его код.потоков не смогут "выгрузить"...
Естественно, винда за этим следит. Так же она следит за тем, чтобы FreeLibrary не закрыла библиотеку, если она еще используется другими процессами (в этом случае она просто освобождает информацию о библиотеке в данном процессе об этой dll, и то не всегда - как в предложенном примере).

На счет Рихтера и прочих: на чтение подобных книг у меня нет времени. Изучаю Windows я в процессе работы, и все мои знания накописись на основе опыта (с помощью разных help"ов, предоставленных компанией Microsoft)

← →
Digitman (2003-12-30 12:06) [34]

> YuRock © (30.12.03 11:47) [31]

еще раз повторю, что утверждение

> Просто он лежит вне адресного пространства приложения

неверно ни терминологически ни концептуально, когда речь идет о вирьтуальном адресном пространстве конкретного процесса

← →
Digitman (2003-12-30 12:08) [35]

> на чтение подобных книг у меня нет времени

это заметно

← →
YuRock (2003-12-30 12:17) [36]

> Digitman ©:
"Программингом занимаюсь более 16 лет, из которых последние 7 - профессионально"

а я работаю, а не занимаюсь

← →
Digitman (2003-12-30 12:18) [37]

> Так же она следит за тем, чтобы FreeLibrary не закрыла библиотеку

да следит-следит)... вот только ты не следишь за тем, что я веду решь о стат. и дин. использовании модуля

в рамках тек.процесса, если его модули статически импортируют некий модуль A, то никакие Freelibrary() ни в каких код.потоках тек.процесса не заставят систему "выгрузить" модуль A из ВАП тек.процесса ... а прочие процессы здесь ни при чем - у них своя отдельная "песня" на ту же тему ...
иными словами, если некий PE-модуль, будучи импортированным статически, используется в дан.момент времени ТОЛЬКО ОДНИМ процессом, то освободить файл PE-модуля невозможно НИКАКИМИ документ.способами (ни FreeLibrary ни что-то иное) вплоть до завершения процесса (штатного или аварийного - без разницы)

← →
YuRock (2003-12-30 12:19) [38]

> вирьтуальном адресном пространстве конкретного процесса

При чем здесь конкретный процесс??? А, ладно, надоело...

← →
Digitman (2003-12-30 12:21) [39]

> YuRock

ладно, все ясно с тобой, сударь
засим ненамерен более продолжать с тобой бесплодную "научную" дискуссию - все твои аргументы сводятся к "что вижу, то пою"

← →
YuRock (2003-12-30 12:34) [40]

>Digitman ©

В таком случае твой "научный" стиль тоже хорош: "что читаю, то и пишу". Ну ладно, с наступающим тебя. И всех остальных.

Dll в памяти. Найти похожие ветки