Как наиболее корректно получить число дескрипторов открытой .DLL?

Если есчо счётчик загрузок нужен, то в базу данных лодера придётся лезть.

 

а... ясно... вообще мне кажется делать это таким образом, это как чесать левое ухо правой рукой... но интересно канеш... так а чем по PEB'у пройтись плохо?))) канеш чужую память читать каждый раз...

куда?))

 

CreativeFighter

Количество "дестрипторов" (разных), возвращаемых LoadLibrary, обычно намного меньше количества проекций DLL, т.к. система стремится загрузить ДЛЛ по её дефолтному базовому адресу, чтобы избежать релокации.

Скорее всего LoadLibrary будет возвращать для данной DLL один и тот же "дескриптор" во всех процессах.

Чтобы определить в каких процессах загружена данная DLL, воспользуйтесь PSAPI (EnumProcesses, EnumProcessModules).

 

Rel
LDR_DATA_TABLE_ENTRY.LoadCount

Кстате там ядерные модуля только. Поэтому отладочную инфу получать, ну или как строкой выше сказано - читать из лодера.

 

CreativeFighter

Это бред. В системах общего назначения это невозможно по определению. Т.е. либо Вы лезете в ядро, останавливаете планирование, перебираете весь список EPROCESS и для каждого из них парсите PEB, перебирая список модулей и самостоятельно заботясь о подгрузке сброшенных в pagefile кусков памяти (ни о какой документированности речь тогда вообще не идёт), либо забиваете на амбиции и спокойно, кошерно и документированно через Win32 API делаете сначала снапшот процессов, а потом для каждого потихоньку, по одному процессу, медленно, не торопясь... что-то я ухожу от темы... в общем для каждого делаете снимок модулей. В противном случае никакие ntdll Вам не помогут... уж не знаю, что у Вас там за способ через NtQueryObject нарисовался...
Clerk

Вау, какая честь! Серьёзно. Никакого сарказма.

 

Почему? если вдаваться в словообразование, то HMODULE есть суть HANDLE to MODULE иными словами дескриптор на модуль, что естественно сокращается до просто дескриптора. В чём тут некорректность?

Можно, и этим занимается ToolHelp, что приводит к проблемам расхождения реальности и счётчика на момент окончания прохождения. Насчёт ZwQuerySystemInformation - не знаю, лень было проверять, а вот ntQueryObject берёт инфу из ядра из дерева объектов - там есть соответствуюее поле - проверял, нет проблем несоответствия, но путь меня не устраивает в силу своей недокументированности. Неужели нет никакого документированного раппера для этого где-нибудь в kernel32?

 

CreativeFighter

Да что Вы прицепились-то к этому расхождению? Да даже если бы была докумментированная функция
DWORD HochuKolichestvoReferensovNaModul (LPCTSTR Put'Kmodul'u)
, то в силу планирования абсолютно никто не гарантирует, что к моменту возврата поток не прервётся и этот модуль ещё сотню раз не подгрузят.

 

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

 

не корректность заключается в непонимании различий... вы знаете чем HMODULE отличается от HANDLE? нет, канеш в описании в заголовочных файлах они определяются одинаково (макросом DECLARE_HANDLE, вроде как то так называется)... я имею ввиду идеалогические различия))) кстати касается не только HMODULE, но и HINSTANCE, которую тоже часто путают...

таак... а с этого места давайте поподробнее...

 

Формально это называется HMODULE, иными словами HANDLE to MODULE, а вопрос перевода настолько индивидуален, что каждый переводит как считает нужным, главное, что в принципе понятно и я не очень понимаю, какой смысл цепляться к словам, Вы же меня поняли, так ведь?

 

Видимо придётся, хотя решение тоже не самое лучшее по двум причинам:
во-первых, на момент получения результата он может не соответствовать реальности,
а во-вторых моя программа может не иметь прав PROCESS_QUERY_INFORMATION, что неприятно.

 

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

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

И ещё раз повторю вопрос - есть ли корректный документированный раппер для этого способа или нет? Кроме недокуменитированности этот способ всем остальным меня устраивает.

 

CreativeFighter

Расхождение с "реальностью" у вас может быть всегда, при любом методе. Какая разница, возникнет это расхождение при выполнении системного вызова или сразу после возврата из него (т.е. до того, как ваш код начнёт анализ полученных результатов)?

Кстати, а каким образом вы используете для вашей задачи NtQueryObject?

 

Вопрос задачи, то, что расхождение будет в любом случае - это понятно, но для задачи, которую мне необходимо решить ToolHelp не подходит потому что для этой[/b[ задачи расхождение становится значимым, а вот способ ntQueryObject совершенно спокойно работает без проблем и то расхождение, которое он теоретически даёт не сказывается на этой конкретной задаче, единственное, что меня останавливает от его использования - это его некорректность в смысле недокументированности.

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

 

CreativeFighter

Windows - не система реального времени, здесь задержки выполнения не лимитированы. Как выможете говорить про "расхождение, которое он теоретически даёт"? Можно говорить лишь, что "способ ntQueryObject" сработает для вашей задачи с большей вероятностью, разве нет?

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

 

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

В ответе номер 17, просто я использовал ntQueryObject вместо zwQueryObject, насколько я понимаю за исключением дополнительных проверок разницы нет.

 

CreativeFighter

Но ваше приложение ведь не только на одной вашей машине работать будет?

Этот способ некорректный как минимум потому, что не учитывает, что ДЛЛ может быть открыта как файл данных (например, Explorer'ом при отображении ДЛЛ в списке файлов).

 

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

Я уже не один раз здесь писал, что это мне и не нужно учитывать для моей задачи. То, что он это не учитывает - это понятно, но меня это более чем устраивает, потому что если бы он учитывал, мне пришлось бы это фильтровать, а так уже всё за меня сделано. Мне необходимо получить снаружи тоже число, что я бы получил если бы в DllMain делал инкремент на PROCESS_ATTACH и декремент на PROCESS_DETACH. Я бы так и сделал будь DLL моей собственной. Вопрос состоит в том, чтобы получить это снаружи, и ntQueryObject справляется с этим точно как надо, беда в том, что она нен документирована и 'Subject to change without additional notice'.

 

green
Я думаю, Вы зря стараетесь. Я понимаю, что над новичками стебаться — дело неблагородное, но чего стоит только:

(слышал звон)
Не говоря уже о:

Учитывая это, особенно мне нравится фраза:

Ага-ага... сплошные абсолютно правильные значения.

 

CreativeFighter

А не пойтили вам.. учить матчасть, а не обьяснять что это значит. Ну вобщем вы меня поняли..