Dll в памяти.

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

>Digitman ©

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

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

> Перезапустить прилождение не удается, потому что dll уже
> загружена и завешена в памяти

ты головой-то подумай своей)

надеюсь, для тебя не новость, что та же системная библ-ка kerne32.dll используется всеми прикладными Win32-процессами ?

так вот по твоей логике получается, что если самый первый процесс A стартовал и загрузил/использует kerne32, то никакой другой процесс стартовать не может, пока процесс A либо не завершится сам либо каким-то невероятным образом kernel32 не будет "освобождена")

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

> YuRock © (30.12.03 12:34) [40]

угу ... с наступающим и тебя !

желаю тебе в НГ таки хоть что-нибудь почитать о механизмах организации страничной и виртуальной памяти процессов и о работе системного PE-загрузчика, дабы не нести чепухи и не давать заведомо несуразные/невыполнимые никоим образом советы

← →
KosilkA (2003-12-30 13:02) [43]

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

← →
YuRock (2003-12-30 13:26) [44]

>Digitman © [42]
Спасибо за пожелание - надеюсь, появится время.

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

Ну я не хочу продолжать эту дискуссию.

Всего наилучшего.

← →
alehan (2003-12-30 14:00) [45]

> YuRock © (30.12.03 12:03) [33]

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

Чтение Рихтера как раз и нужно чтобы вместо накопившейся груды знаний в голове возникла чёткая стройная теория.

Без этого обсуждения типа

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

оказываются лишены не только теоретического, но и практического смысла.

← →
YuRock (2003-12-30 14:18) [46]

> alehan ©
> в голове возникла чёткая стройная теория
Я практик (предпочитаю утверждать лишь проверенные мною факты). А на счет чтения книг (если ты недопонял) - то я ничего не имею против, просто нет времени.

> лишены не только теоретического, но и практического смысла
"FreeLibrary(GetModuleHandle("<имя длл>"))" закроет библиотеку в текущем процессе (если она в нем открывалась ч-з LoadLibrary()).

Так что практический смысл эта запись в принципе может иметь (если не знаешь хендла, а закрыть нужно).

← →
alehan (2003-12-30 14:46) [47]

> YuRock

Понятно :)

При случае непременно воспользуюсь твоим ценным советом )

Вообще бывают случаи, когда упавшее приложение не удаётся сразу опять запустить. Например, если оно юзает BDE, то упав при запущенных дельфях, оно не желает запускать повторно, жалуясь на недоступность каталога, содержащего файл PDOXUSRS.NET. Приходилось закрывать Дельфи. Сей феномен подробно исследовать мне было недосуг, повинны ли в том какие-либо dll или нет - не знаю.

Evgeniy_K к сожалению не уточнил своей ситуации, видимо разгоревшаяся между тобой и Сергеем Digitman дискуссия с применением высоконаучных терминов привела его (судя по всему тоже трудолюбивого практика) к мысле о том, что Рихтера почитать всё же было бы неплохо :)))

← →
VMcL (2003-12-30 15:41) [48]

>>YuRock © (30.12.03 14:18) [46]

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

← →
YuRock (2003-12-30 15:49) [49]

Если человек не может отличить документацию от книги (см. [33]) или он слепой (что для профессии "програмист" в принципе, одно и то же), а так же если человеку не хватает воспитания для того, чтобы уважительно относиться к людям (тем более, которых он не знает), то с таким "профессионалом" и разговаривать как-то не о чем...

← →
Digitman (2003-12-30 17:07) [50]

значение поля ImageBase некоего PE-модуля, отображенного на ВАП процесса А и значение поля ImageBase ТОГО ЖЕ (т.е. - одноименного, загружаемого из того же PE-файла) PE-модуля, отображенного на ВАП процесса В, не обязаны совпадать .. и этот факт ставит в тупик любого воинствующего дилетанта)

← →
VMcL (2003-12-30 17:23) [51]

YuRock © (30.12.03 15:49) [49]

Это тупой наезд.

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

Хэндл библиотеки - это указатель на структуру типа IMAGE_DOS_HEADER, а не IMAGE_OPTIONAL_HEADER, о которой говоришь ты, который получается через

hModule + pDosHeader.e_lfanew + 2

(только в случае, если это PE, что тоже надо проверять).

И никакого отношения ImageBase не имеет к хендлу библиотеки. Не люблю никого оскорблять, но, вижу, наши мастера Delphi тоже не отличаются воспитанностью...

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

> И никакого отношения

самое прямое)

значение ImageBase, прописанное в файле, есть значение базового адреса, ПРЕДПОЧТИТЕЛЬНОГО при загрузке образа модуля в ВАП процесса ... если система не имеет возможности загрузки модуля начиная с адреса, прописанного линкером в поле Imagebase PE-файла, система вправе загрузить образ PE-модуля по иному адресу. который с момента загрузки и становится реальным базовым адресом модуля в ВАП данного процесса... мы здесь не говорим о спец.опциях линкера, предписывающих ситс.загрузчику пытаться загружать образ по возмодности в верхние адреса ВАП

разумеется, поле Imagebase структуры IMAGE_OPTIONAL_HEADER после загрузки образа модуля остается неизменным ! Кто ж спорит !

но однотипное по смыслу поле run-time-структуры MODULE_INFO (неважно, как его обозвали - ImageBase или DLLBase) вовсе не обязательно содержит то же самое значение, что и IMAGE_OPTIONAL_HEADER.ImageBase ... собственно, cardinal-значение хэндла загруженного модуля и есть точная копия значения поля MODULE_INFO.DLLBase, но никак не копия значения IMAGE_OPTIONAL_HEADER.ImageBase

почему я обзываю поле MODULE_INFO.DLLBase именем "ImageBase" ? Да потому что оно некорректно по смыслу ! Образ любого модуля есть Image, но модуль совершенно необязательно есть DLL-модуль ! Осн.модуль (т.е. загруженный образ exe-файла) - это ТОЖЕ модуль ! такой же равноправный как и все прочие модули в ВАП процесса... поэтому поле DLLBase корректней было бы называть все же ModuleImageBase (или просто - ImageBase)... не путая при этом с полем IMAGE_OPTIONAL_HEADER.ImageBase

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

отсюда - прямой ответ на вопрос : ЧТО реально возвращает в кач-ве рез-та ф-ция LoadLibrary() или GetModuleHandle() ..

а возвращают эти ф-ции значения полей MODULE_INFO.ImageBase , а не IMAGE_OPTIONAL_HEADER.ImageBase !!

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

после загрузки (т.е. после того как PE-файл из просто некоего файла стал PE-модулем !! отсюда все недоразумения !) и последующей инициализации система вообще не обращается к структуре IMAGE_OPTIONAL_HEADER ... эта структура, пока процесс активен, более не нужна никому - ни системе ни программеру) ... разве что - из непонятного любопытства. которое вполне может быть удовлетворено и обычным чтением заголовка PE-файла и его анализом (т.е. ДО момента, когда он превратился в модуль некоего процесса)

← →
YuRock (2003-12-30 18:53) [56]

> значение хэндла загруженного модуля и есть точная копия значения поля MODULE_INFO.DLLBase, но никак не копия значения IMAGE_OPTIONAL_HEADER.ImageBase

Я что, спорю с этим? Мне не понятно, зачем сразу начинать ругаться.

Правда, я никогда не реботал (и не встречал) с MODULE_INFO.DLLBase (наверно это то же, что IMAGE_DOS_HEADER._lfanew - File address of new exe header), так как всегда начинал разбирать dll или exe со структуры IMAGE_DOS_HEADER, а из нее уже получал IMAGE_OPTIONAL_HEADER...

Неужели не понятно: всегда, когда я говорил о "заголовке модуля", я имел в виду именно эту структуру (IMAGE_DOS_HEADER или MODULE_INFO). Зачем ругаться не разобравшись? Ведь именно это и есть первоначальный заголовок модуля (или exe, или com)!

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

> разве что - из непонятного любопытства
Почему из непонятного? Мне, например, неоднократно приходилось подменять функции (их адреса) в таблице адресов ф-ций модуля (в моем случае - экзешника) подключенной библиотеки на другие функции (очень удобное и красивое решение на низком уровне).
А это легко можно сделать, используя IMAGE_OPTIONAL_HEADER.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress

← →
Evgeniy_K (2003-12-30 20:12) [58]

Тогда как объяснить то, что после выгрузки из памяти моей программы ее dll иногда остается и, пока я ее не убью программой KillProcess, моя программа не запускается? Я надеялся что мне попомуг, а получаю пока какие-то упреки со стороны каких-то кодеров. Если ты конкретно не можешь ответить на поставленный вопрос, то зачем тогда выкручиваться? Спасибо за попытку мне помочь, но видно не судьба. Иди лучше Кнута почитай :-)

← →
Evgeniy_K (2003-12-30 20:23) [59]

Ладно, уточняю вопрос. Все-таки надеюсь, что кто-нибудь поможет.
Dll ставит хук на клавиатуру. Моя программа как раз вызывает функцию установки хука. Хук выставляется. Если происходит какой-либо левый сбой в моей программе и она вылетает, то хук не снимается и длл остается висеть в памяти. В связи с тем, что хэндл куда передаются коды клавиш не существует длл тоже завешивается, но это происходит уже после закрытия программы. Виндоус не убивает зависшую длл и она там остается. При новом запуске моей программы она пытается взаимодействовать с зависшей длл и из-за этого она просто зависает. Если я сворачиваю свою программу, то длл как замечено может выгрузиться, но не всегда. Почему это происходитя я не знаю Я не рихтовед. А даже если бы и был, то не хвастался бы на каждом шагу.

Так понятней?

PS Где взять хороший PEScaner?

← →
YuRock (2003-12-30 20:23) [60]

> Evgeniy_K (30.12.03 20:12) [58]
Извини, конечно, если это ко мне, но не мог бы ты поконкретнее рассказать, как ты "убиваешь ее программой KillProcess"? Ведь dll - это не процесс. А что за программа - KillProcess?
Я просто хочу тебе помочь, но не совсем понимаю, что ты делаешь...

← →
YuRock (2003-12-30 20:28) [61]

Evgeniy_K (30.12.03 20:23) [59]
Попробуй прибивать хук (UnhookWindowsHookEx) при выгрузке библиотеки (желательно - перед тем, как "хэндл куда передаются коды клавиш" перестает существовать)

← →
jack128 (2003-12-30 21:18) [62]

> При новом запуске моей программы она пытается взаимодействовать
> с зависшей длл и из-за этого она просто зависает.

Применительно к EXE это выглядит, как если бы зависла моя программа, и из-за этого не могу запустить её новый экземпляр, что то здесь не состыкововается..

Учитывая

> В связи с тем, что хэндл куда передаются коды клавиш не
> существует длл тоже завешивается,

попробуй перед загрузкой DLL вызвать keybd_event..

← →
Pat (2003-12-30 21:32) [63]

>Если происходит какой-либо левый сбой в моей программе и она
>вылетает, то хук не снимается и длл остается висеть в памяти
Не волнуйся, система ее сама снимет.

Утилита Process Explorer от Sysinternals (www.sysinternals.com)

← →
alexEagle (2003-12-30 22:05) [64]

Digitman © (30.12.03 08:41) [22]
Если процесс уже не существует, тот никаких модулей в его ВАП нет, ибо нет самого ВАП

Уважаемый профи. Если вы действительно хорошо разбираетесь в программировании, а не только (по мнению модераторов) в делфи, то вы должны знать что Com может быть реализован в виде dll, которая не выгрузится из памяти до тех пор пока счетчик ссылок не обнулится (да и то при определенных обстоятельствах), а уж тем более при выгрузке одного из использующих его приложений из памяти.

И если это так, то тут поможет лишь знание COM (я сейчас не очень помню где можно управлять загрузкой ком-серверов)

И хотелось бы еще раз акцентировать ваше внимание на то, что в форуме надо давать конкретные ответы, а не разводить балаган.

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

← →
Digitman (2003-12-31 08:37) [65]

> Evgeniy_K

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

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

программа твоя запускается - это однозначно.
другой вопрос, что если запускается она из-под Делфи, то вполне возможно, что перед стартом хук-dll заново компилируется/строится, и если файл занят, то, разумеется, перезаписан он быть не может, и автостарт по F9 не выполняется

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

а дальше начинается самое интересное

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

есть еще один вариант со своей "тонкостью"

предположим, при первом старте ты успешно установил хук, поработал с ним и снял, уверовав в том, что снятие тобой хука привело к полной автовыгрузке экз-ров хук-модуля изо всех ВАП

но это может быть и не так !

некоторые GUI-процессы, "свернутые в трей", по причинам, о которых я сейчас не буду распространяться, не были включены системой в список процессов на выгрузку хук-модуля из их ВАП

вот они, эти процессы, и "мешают" тебе по всей видимости !

решение же простое как лапоть : сразу же после успешного UnhookWindowsHookEx следует выполнить SendMessage(HWND_BROADCAST, WM_NULL, 0, 0), и это даст ожидаемый результат - хук-модуль будет выгружен и из оставшихся процессов

← →
Digitman (2003-12-31 09:58) [66]

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

← →
Digitman (2003-12-31 10:26) [67]

> alexEagle

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

как только автор в [59] таки сподобился конкретизировать проблему, он тут же получил в [65], [66] наиболее вероятные способы ее обхода, ДАЖЕ без предоставления исх.текстов, что, впрочем, еще быстрей бы позволило проанализировать источник проблемы и найти ошибки и их устранение

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

← →
Digitman (2003-12-31 10:40) [68]

> PS Где взять хороший PEScaner?

для таких целей (т.е. целей отладочного исследования) вполне подойдет пример, приведенный в

http://delphimaster.net/view/7-1072779417/

этот код реализует доп.пункт контекстного меню оболочки, при выборе которого на выделенных, например, в Эксплорере файлах с расширениями exe, dll и bpl можно тут же быстро определить, какими процессами в системе в дан.момент используется указанный PE-файл

← →
panov (2003-12-31 13:43) [69]

Какая экспрессия, однако...
Извините за оффтопик, но знание не означает мудрости, а мудрость подразумевает оное.
Мудрость так же подразумевает понимание других.

Ошибки свойственны всем, надо уметь принимать свои ошибки без обид.

А унижать других ради собственного самомнения - как минимум непорядочно.

← →
Digitman (2003-12-31 14:20) [70]

Александр, удали-ка ты, коль можно, эту ветку на всяк случай) ... ну или в "Потрепаться" - тож вариант хороший) .. авось всем нам неповадно будет "мудрость" свою казать) .. оно так спокойней будет

← →
Dolot (2003-12-31 15:16) [71]

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

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

← →
Германн (2004-01-01 07:12) [72]

2 Dolot (31.12.03 15:16) [71]
Ну, во-первых, чтобы иметь право постить любые критические замечания в адрес Мастеров, правила простой этики И-нет форумов требуют некоей, авторизации. А вы даже не удосужились "зарегистрироваться" на форуме, где регистрация - чисто номинальная. Так о чем тут говорить? Любой модератор имеет полное право удалить ваш пост, даже без объяснений.

Во-вторых, действительно, почему-то, количество постов уважаемого Digitman в эти дни сильно превышает обычный уровень. Почему - знает только он.

Но, лично для меня, это - удача. Я получил и естесс-но сохранил для себя кучу примеров и советов дополняющих книги, в том числе и книгу Рихтера.

А вот людей, которые говорят, что не знают, кто такой Рихтер, и говорят, что у них нет времени читать книги, мне искренне жаль! Может им лучше последовать Остапу Бендеру и уйти в управдомы?

← →
Evgeniy_K (2004-01-01 10:10) [73]

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

← →
Snap (2004-01-02 18:37) [74]

>>длл. Можно даже кернел убить.

Какой кернел? kernel32.dll?

Каким образом убить? выгрузить из всех процессов? Если так то очень было бы интересно взглянуть на данную программу. Только скорее всего ты опять что-то напутал.

Впредь постарайся быть более точным чтобы мы могли оказать тебе помощь, поскольку до сих пор по твоим псостам ничего понятно не было.

← →
AllDer (2004-01-04 02:08) [75]

может и может kernel32.dll убить
но только не в XP(если он есть)
а в 98 там и Explorer спокойно из Киллеров вырубается

← →
X-MAN (2004-01-04 02:09) [76]

FreeLibrary(GetModuleHandle("some.dll"));

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