Вы не зашли.
Господа,
не замечали ли вы такую странную вещь: если посмотреть (например, ProcessExplorer'ом) список загруженных DLL различных процессов, то частенько попадаются процессы с одной и той же DLL, загруженной дважды с разными базовыми адресами. Причем путь к обеим образам одинаков (т.е., WinSxS тут, скорее всего, ни при чем). Например, в процессе devenv.exe 8-й студии две копии devenv.dll, а NATDbgDEUI.dll - аж четыре (!) штуки, все с разными базовыми адресами и одинаковыми image path.
Что это за странности?
У меня в процессе devenv.exe 8-й студии нет ни одной копии devenv.dll
Может просто глюк какой? Скажем подгрузили библиотеку не тогда когда нужно, а старую перед етим не выгрузили. Вообще-то не вижу смысла для чего такое делать...
green написал:
У меня в процессе devenv.exe 8-й студии нет ни одной копии devenv.dll
виноват... это называется msenv.dll
Mi256 написал:
Может просто глюк какой? Скажем подгрузили библиотеку не тогда когда нужно, а старую перед етим не выгрузили. Вообще-то не вижу смысла для чего такое делать...
Возможные предположения: одна из копий загружена виндой как inprocess COM server по вызову CoCreateInstance(), а вторая прилинкована динамически через LoadLibrary() или таблицу импорта... Хотя смысловая нагрузка такого решения все равно сомнительна...
Mi256 написал:
Может просто глюк какой?
"А может это проклятие какое-нибудь?" (с) Final Destination 2 :) :) :)
Ursus
А ты не смотрел тип загрузки? У первой обычный, Image, у второй - Data.
IceStudent написал:
Ursus
А ты не смотрел тип загрузки? У первой обычный, Image, у второй - Data.
А, действительно... Это всё объясняет ))
Народ,
как раз пытаемся разобраться с именно этой проблемой, обсуждение начато в гугл группах, http://groups.google.com/group/microsof … 2924ea759c, но, увы, там тишина (равно как и на msdn форумах, ссылку припводить не буду - там вообще обсуждения нет никакого), поэтому хотел бы услышать ваше мнение тут.
В нашем рассматриваемом примере (http://www.megafileupload.com/en/file/2 … --zip.html), да, мы грузим эту длл вначале с помощью SxS COM, создавая объект, живущий в ней, а воторой раз - как статически прилинкованную к загружаемой через LoadLibrary длл (т.е. делаем LoadLibrary "промежуточной" длл, в таблице импорта которой находится "проблемная" первоначальная дублирующаяся длл (та, в которой живут созданные раньше через SxS ком объекты)). Порядок загрузки изображен тут: http://i10.photobucket.com/albums/a148/ … roblem.jpg.
Меня бы может и устроил ответ, что, типа, в одном случае у нас ком грузит, а в другом - LoadLibrary, да и то опосредованно через таблицу импорта и все такое (хотя это, имхо, бред, какая разница как оно грузится, если образ один и тот-же, да и поискать в нете если, то везде говорят, что "dll can't be loaded twice" с различным вариациями), если бы не еще несколько НО с нашей точки зрения:
1. Если в указанном примере использовать обычный ком, а не SxS, то копия длл оказывается одна.
2. Если изменить порядок загрузки и вначале грузить через LoadLibrary, а потом создавать объект через SxS ком - то опять-же, копия одна.
И пускай уже, пункт 1 я готов принять как некий by design, но вот пункт 2 ставит большой знак вопроса. Какими бы ни были разными механизмы загрузки, но порядок не должен влиять на конечный результат, при использовании одних и тех же механизмов.
Более того, если поставить бряки в DllMain дублирующейся длл, то студия дуреет: при первоначальной загрузке через SxS все красиво брякается, а вот при повторной непонятной загрузке студийные бряки не срабатывают, а int3 приводит студию в шок и она показывает в стеке вызовов полную ерунду + асм код вместо исходников. Т.е. она видит, что длл загружена по одному базовому адресу и никак не хочет принимать тот факт, что та же длл есть и еще по одному адресу.
Ну и напоследок скажу, что mapping type для обоих инстансов этой длл одинаков - Image. Безусловно, image path также идентичны.
Заранее благодарен за ваши соображения на этот счет.
Отредактировано TheRawGod (19-12-2007 15:13:22)
TheRawGod
И правда, 2 экземпляра одной ДЛЛ... :0
Если это представляет проблему, то можно грузить COM-овскую DLL (SideBySideDLL.dll) только динамически, в этом случае, кажется, всё в порядке.
Или, что то же самое, сделать её delay loaded - тогда не придётся ничего менять в коде.
Таким образом, можно сделать вывод, что это баг в загрузчике ОС? (:-0)
Отредактировано TheRawGod (20-12-2007 01:30:22)
