вызов LoadLibrary("MSHTML.DLL") создает поток
его можно как-то корректно прибить?
FreeLibrary не помогает %)

код LoadLibrary вызовет DLL_PROCESS_ATTACH в свою очередь скорее всего в DllMain создается какой нить поток, хотя в MSDN на этот счет сказано что нельзя этого делать.


Ну если просто предположить что прибить поток DLL то вызвать FreeLibrary()

Dem_max, у вас плохо со зрением? Три строчки текста не прочитать? Я написал



пруфлинк давай

Это сообщение отредактировал(а) Abyx - 31.7.2010, 15:19

Читаем тут http://msdn.microsoft.com/en-us/library/ms...3(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms...6(v=VS.85).aspx

1) просплайсь у себя в процессе функу CreateThread и в обработчие по lpStartAdress определяй модуль (mshtml ) не давай создаваться потоку возращай 0 
2) использовать другуя dll и может в обработчике DLL_thread_attach чтото попробовать  
3) ну и TerminateThread можно пробовать

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

вы бредите

еще из этой оперы. 
SuspendThread -> GetThreadContext -> eip = adrExitThread -> SetThreadContext-> ResumeThread 

это нестандартное решение нестандартной задачи - если оно вам кажется бредом - это ваши проблемы

Если есть сомнения по поводу выгрузки библиотеки, то вызывай функцию DllCanUnloadNow:


Это сообщение отредактировал(а) 586 - 1.8.2010, 01:25

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

Добавлено через 12 минут и 19 секунд
12usver12, тот код который вы привели - это не "корректное завершение потока". Это еще более некорректное завершение потока, нежели TerminateThread. 
ExitThread вызванная в произвольном месте по эффекту не отличается от TerminateThread, но переключение контекста потока это вообще жесть. Поток может выполнять какой угодно код, и не факт что в этот момент его можно вызывать ExitThread. Например можно запросто словить дедлок который повесит весь процесс.

алсо, в сакральный смысл делать асм-вставку для ExitThread? типа хотели показать что знаете асм?

можно сразу написать "ctx.Eip = (DWORD)&ExitThread;", его параметр никому не нужен.

Ресурсы, которые предоставляет библиотека MSHTML.DLL - это COM-интерфейсы. Если DllCanUnloadNow возвращает S_OK, то все интерфейсы освобождены, и освобождать больше нечего.
По поводу потоков - такая-же проблема есть при использовании диалога OpenDialog - тоже там остаются висящие потоки. И никого это не беспокоит. К такому выводу я пришёл, когда запустил "Блокнот" в отладчике. 
Судя по примеру в MSDN и твоей теме, код вроде правильный.

Это сообщение отредактировал(а) 586 - 1.8.2010, 09:45

586, код стал правильным только когда я добавил ExitProcess()
вобщем-то это решение, но если мне надо будет временно запустить диалог, это не есть хорошо, что создается 1 поток при загрузке длл, и еще 10 при запуске ShowHTMLDialog. Хотелось бы как-то это разрулить %)

Если компилировать прогу с рантаймом (без директивы #pragma comment(linker, "/entry:main")), то всё завершится нормально. А всё потому, что рантайм вызывает ExitProcess. Так что нормально, что вызываешь ExitProcess в чисто винапишной проге.

наверное действительно надо просто не обращать на них внимание, и всегда юзать ExitProcess при закрытии программы

Добавлено через 1 минуту и 17 секунд
586, я знаю что рантайм вызывает ExitProcess  =) 
иногда это очень раздражает, когда хочешь чтобы main() завершилась, а другие потоки продолжали работать
но тут как раз противоположный случай

Практически все приложения используют ExitProcess. В том числе приложения, скомпилированные в C++ Builder и Delphi.

Это сообщение отредактировал(а) 586 - 1.8.2010, 10:09

Ну сам по себе вызов LoadLibrary никаких дополнительных потоков не создаёт, если конечно в обработчике DLL_PROCESS_ATTACH этой библиотеки не стоит CreateThread/_beginthreadex... Вы подробнее описать проблему не можете?..
Да и вообще давайте рассуждать логически: если функия потока создаваемого потока (извиняюсь за масло масленное) находится в DLL, и при её выгрузке поток корректно не завершается и продолжает работать, то сразу же должен вылетать access violation. Так как образ DLL уже отгружен от адресного пространства вашего процесса. MSHTML.DLL вряд-ли так криво реализована...



Ну уж очень нестандартное решение... )))))))))

Contains processor-specific register data. The system uses CONTEXT structures to perform various internal operations. Refer to the header file WinNT.h for definitions of this structure for each processor architecture.

Не обращали внимания на эту идиотскую по-вашему мнению информацию из MSDN?.. )))))))))

А вот вам:



Где поле поле регистра Eip?.. Или под каждую архитектуру своё завершение писать?.. Пока ещё такого не было, но всё-таки соглашусь с Abyx: вы бредите. Хотя подход безусловно интересный, но не нестандартный, а нерабочий... 

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 14:07

HellStranger, у вас по умолчанию платформа xeon? у меня - по умолчанию x86-32
какбэ в WinNT.h нужная структура CONTEXT выбирается дефайнами (#ifdef).

Это сообщение отредактировал(а) Abyx - 2.8.2010, 14:10

Вы, наверное, слепые или просто далеки от мысли... Я привёл пример структуры CONTEXT под архитектурой, где указанного поля регистра EIP просто напросто нет, тем самым указав аппаратную зависимость решения, предложенного 12usver12. Или вы у нас настолько продвинутый программист, что под каждый процессор пишите отдельно, но используете при этом cpp?.. "ОЧЕНЬ УМНЫЙ" ПОДХОД! Удачи в вашем нелёгком (читать по-другому...  ) труде!

Добавлю только, что вместо того, чтобы ответить на мою просьбу уточнить суть проблемы, вы начинаете искать повод превратить тему в балаган, делаю вывод, что вы баба базарная... И всё-же, посоветую вам для решения проблемы прочесть Рихтера главы 19 и в особенности 20, где, я уверен, ваша проблема описана и решена.

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 14:36

HellStranger, вы такой забавный) пишите еще


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

К вашему сведению EIP-регистр общего назначения, присутствующий во всей архитектуре IA-32/64 (в том числе и в XEON), и всё-же решение на его основе даже для данной платформы не подходят. 
Вы тоже забавный, настолько, что отвечать на ваши посты я смысла больше не вижу... Сам шучу- сам смеюсь это про вас... 

HellStranger, я открою вам страшную тайну, первая буква в Eip говорит что это только x32, и никак не x64. там он называется Rip

А кто сказал что по FreeLibrary билиотека будет выгружена из адресного пространства по DLL_PROCESS_DETACH, если вернем false то DLL не будет выгружена?

Может бы все проще ? Автор не вызвал нужные функции для закрытия всех ресурсов ?

автор собственно их и реквестирует

А можно узнать, зачем звать LoadLibrary("MSHTML.DLL") когда можно (и нужно) просто создать COM объект (один из поддерживаемых ею)? Возможно она (MSHTML.DLL) не рассчитана на то, что ее будет грузить НЕ COM менеджер?

xvr, вообще-то создание ком-объекта сопровождается загрузкой библиотеки.
COM менеджер - это что? посмотрите реализацию CoCreateInstance %) там есть LoadLibrary

алсо она рассчитана на то что ее будут грузить не-COM менеджер

Да, но не ограничивается только им.

COM менеджер следит за тем, что бы библиотеку не выгрузилась, пока есть живые COM объекты (если конечно програмист сам ее не выгрузит в принудительном порядке   )

Да, упоминания в MSDN есть. 

А в примерах от MS ( http://www.microsoft.com/downloads/details...;displaylang=en / Htmldlg.exe) тоже остаются нитки при завершении?

Abyx, Используйте ExitProcess, и не слушайте ШКОЛАТУ!

SetThreadContext(утечка памяти pending kernel services, а на WaitFor**** это вообще полный бред)
TerminateThread - прямая утечка памяти(минимум Не корректное освобождения стека, + pending kernel services).

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