| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL | | Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

	« предыдущая ветвь | форум | следующая ветвь »

моя DLL подгружается другими приложениями [Win95/98, WinME, NT4, Win2k, WinXP]

Nostradamus ©   (2006-05-24 15:39:00) 

Имеется DLL с хуком: http://www.delphimaster.ru/cgi-bin/forum.pl?id=1147959433&n=5

Я изменил её код следующим образом:
case dwReason of
   DLL_PROCESS_ATTACH:
     begin
       HMap := CreateFileMapping(INVALID_HANDLE_VALUE, nil, PAGE_READWRITE, 0, SizeOf(TData), MapID);
       Data := MapViewOfFile(HMap, FILE_MAP_ALL_ACCESS, 0, 0, SizeOf(TData));
     end;
   DLL_PROCESS_DETACH:
     begin
       if Data^.OldHook 0 then begin
        UnhookWindowsHookEx(Data^.OldHook);
        Data^.OldHook := 0;
       end;

       UnMapViewOfFile(Data);
       CloseHandle(HMap);
     end;

Теперь после того как я запущу паралельно моей программе скажем Блокнот и закрою его то происходит
DLL_PROCESS_DETACH:
     begin
       if Data^.OldHook 0 then begin
        UnhookWindowsHookEx(Data^.OldHook);
        Data^.OldHook := 0;
       end;

       UnMapViewOfFile(Data);
       CloseHandle(HMap);
     end;

Не смотря на то, что моя программа всё ещё работает. Я сделал вывод, что моя ДЛЛ атачится по какой-то причине к другим приложениям.

Вопроc - почему и как это предотвратит???

---

Leonid Troyanovsky   (2006-05-24 18:28:00) [1]

> Nostradamus ©   (24.05.06 16:42) [8]

> Сложно сказать на 100%, но я уже проделал очень много тестов
> и действительно заметил, что чем больше разного софта запущено,
>  тем больше вероятность того, что длл будет долго


Хуковая dll выгружается после снятия хука (UnhookWindowsHookEx)
при обработке _очередного_ сообщения.
Если процессов много, то, возможно, что некоторые потоки
не получают вообще процессорного времени, т.к. заняты,
например, ожиданием ввода.

Если речь о конкретном приложении, то ему можно послать
SendMessage, скажем WM_NULL. Бродкаст более рискован,
на худой конец - SendMessageTimeout.

--
Regards, LVT.

---

Сергей М.   (2006-05-24 17:42:00) [2]

> Сложно сказать на 100%


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

---

Nostradamus   (2006-05-24 16:42:00) [3]

Сложно сказать на 100%, но я уже проделал очень много тестов и действительно заметил, что чем больше разного софта запущено, тем больше вероятность того, что длл будет долго занята. В VMWare на голой машине она всегда через секунд 30 свободна...

---

Сергей М.   (2006-05-24 16:34:00) [4]

Для начала проверь-подтверди/опровергни мое предположение

---

Nostradamus   (2006-05-24 16:32:00) [5]

> Это как минимум из-за некоторых "кривых" приложений, "висящих
> в трее" - они не "отпускают" библиотеку.
>


Одним словом реально повлиять на ситуацию я не могу :(

---

Сергей М.   (2006-05-24 16:30:00) [6]

> Nostradamus ©   (24.05.06 15:49) [2]


Это как минимум из-за некоторых "кривых" приложений, "висящих в трее" - они не "отпускают" библиотеку.

---

Nostradamus   (2006-05-24 15:57:00) [7]

> Если конечно в реестре не выставлен параметр для немедленной
> выгрузки DLL.
>

А где конкретно можно выставить этот параметер?

---

tesseract   (2006-05-24 15:55:00) [8]

Тоже нормальное поведение OC.

Если конечно в реестре не выставлен параметр для немедленной выгрузки DLL.

---

Nostradamus   (2006-05-24 15:49:00) [9]

ага, ну по крайней мере это не моя ошибка.

Но есть ещё одна проблема:
после закрытия моей программы длл ещё какое-то время (иногда длительное) всё ещё занята, т.е. её нельзя удалить/перезаписать.

---

Сергей М.   (2006-05-24 15:43:00) [10]

> Вопроc - почему


Потому что это нормальное поведение ОС.


> как это предотвратит?


В случае с Windows - никак.

---

Наверх