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

Здравствуйте, ksd, Вы писали:

ksd>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>после перезапуска системы все работает нормально.
ksd>может, кто то сталкивался с проблемой? что делать? где концы искать?
1) Код ошибки какой?
2) В DLL случаем не используется C++ Runtime? Ибо код DLL может по идее начать раньше выполняться, чем инициализируется рантайм в процессе, к которому ДЛЛ атачиться (или и вовсе не инициализируется). Отсюда и сбой?

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, ksd, Вы писали:

ksd>>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>>после перезапуска системы все работает нормально.
ksd>>может, кто то сталкивался с проблемой? что делать? где концы искать?
C>1) Код ошибки какой?
приложения валятся с Access Violation не пойми где.

C>2) В DLL случаем не используется C++ Runtime? Ибо код DLL может по идее начать раньше выполняться, чем инициализируется рантайм в процессе, к которому ДЛЛ атачиться (или и вовсе не инициализируется). Отсюда и сбой?
используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?

Здравствуйте, ksd, Вы писали:

C>>2) В DLL случаем не используется C++ Runtime? Ибо код DLL может по идее начать раньше выполняться, чем инициализируется рантайм в процессе, к которому ДЛЛ атачиться (или и вовсе не инициализируется). Отсюда и сбой?
ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Да, странно что перезагрузка влияет. А ничего интересненького в DLLMain нету?

Здравствуйте, ksd, Вы писали:

ksd>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?

Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].

Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.

Но особо я там не вникал. Модуль древний уже, дофига где использовался, и прям вот по нормальному его перепроектировать не хотелось и вовсе. А учитывая, что все эти static std::string лежали в private секции, и доступа к ним этот класс не давал, то вполне устроило переделать начинку на скалярные типы, не меняя интерфейса класса. Тык что оставалось только пересобрать проект.

Может наведет на какую-нить мысль?

Может наведет на какую-нить мысль?

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, ksd, Вы писали:

ksd>>используется. а что рантайм? она статически линкуется. пишуть, что можно пользоваться только kernel32, остальное еще не загружено. ну, после перезагрузки винды же все нормально?
C>Если есть какие-нить статические переменные уровня класса или в cpp-файле, то по идее их как раз должна иницилизировать рантайм. А в момент загрузки, если рантайм еще не инициализирована, и есть какие-то обращения к таким переменным, то чего в этом случае произойдет один бог его знает. Может быть в этом дело?

C>Я нечто подобное видел, правда в exe-шнике. Но в нем для пущей липосакции был по максимуму убран рантайм. Дык вот после подключения какого-то левого модуля, у которого в cpp водился std::string статический на класс, exe-шник начал валиться прям на старте с Access Violation. Вылечил заменой всех объектных переменных вроде std::string на скалярные типы данных, вроде char[].

C>Насколько я тогда понял, компилятор просто размещал такие данные в data-секции exe-шника и заранее "знал" их как иницилизировать. И проблема исчезла. Там вроде как получалось, что этот статический std::string на своей инициализации выделял память, и что-то туда писал. Без рантайма на старте в релизе это ессесна не работало. А когда я туда сложил скалярные типы с заданным размером, то вроде как получалось, что компилятор заранее знал размер и чем инициализировать, поэтому обходился без инициализации с рантаймом.

Но особо я там не вникал. Модуль древний уже, дофига где использовался, и прям вот по нормальному его перепроектировать не хотелось и вовсе. А учитывая, что все эти static std::string лежали в private секции, и доступа к ним этот класс не давал, то вполне устроило переделать начинку на скалярные типы, не меняя интерфейса класса. Тык что оставалось только пересобрать проект.

Может наведет на какую-нить мысль?

Здравствуйте, ksd, Вы писали:

ksd>>>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>>>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>>>после перезапуска системы все работает нормально.
ksd>>>может, кто то сталкивался с проблемой? что делать? где концы искать?
C>>1) Код ошибки какой?
ksd>приложения валятся с Access Violation не пойми где.

А что подразумевается под заменой? У меня подозрение, что старая dll-ка всё ещё где-то в области памяти процессов. После замены, каким-то образом процессы лезут по старым адресам в новой dll и падают. С явным LoadLibrary такой фигни не должно быть... А какая у тебя операционка, кстати?...

Здравствуйте, CEMb, Вы писали:

CEM>Здравствуйте, ksd, Вы писали:

ksd>>>>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>>>>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>>>>после перезапуска системы все работает нормально.
ksd>>>>может, кто то сталкивался с проблемой? что делать? где концы искать?
C>>>1) Код ошибки какой?
ksd>>приложения валятся с Access Violation не пойми где.

CEM>А что подразумевается под заменой? У меня подозрение, что старая dll-ка всё ещё где-то в области памяти процессов. После замены, каким-то образом процессы лезут по старым адресам в новой dll и падают. С явным LoadLibrary такой фигни не должно быть... А какая у тебя операционка, кстати?...
под заменой подразумевается переименовать текущую, записать в system32 новую, запустить что-нибудь, ну, cmd.exe, например. и получается вот очень похоже на ситуацию с обращением по старым адресам. как бы системе сказать, что dll-ку подменили, надо заново отображение делать?
это проявляется на разных версиях винды, сейчас боремся конкретно с win7.

Здравствуйте, ksd, Вы писали:

ksd>под заменой подразумевается переименовать текущую, записать в system32 новую, запустить что-нибудь, ну, cmd.exe, например. и получается вот очень похоже на ситуацию с обращением по старым адресам. как бы системе сказать, что dll-ку подменили, надо заново отображение делать?
её надо выгрузить из всех процессов. Как вариант — внутри процессов сказать FreeLibrary до тех пор, пока счётчики не обнуляться. Но всё-таки сначала хотелось бы понять, что реально происходит внутри. Получается, что когда стартует новый процесс — он берёт откуда-то старую таблицу экспорта твоей длл-ки(если это так, то выгружать dll-ку из всех процессов — скорее всего не поможет делу, если только винда не делает копию, глядя на путь до библиотеки, да). Я такого не видел, но я и не припомню, чтобы я делал глобальные перехваты последние годы Но вот точно, что помню: при перерегистрации COM-объектов в 7-ке приходится перегружаться, потому что 7-ка где-то кеширует(не помню, что, или GUID или путь до исполняемого файла, скорее второе) лечиться только перезагрузкой. Ситуация странная, тут тоже странная.
Ну, может кто ещё отпишется, подождём

Здравствуйте, ksd, Вы писали:

ksd>приложения валятся с Access Violation не пойми где.

Так не бывает
Падать не может "не пойми где", всегда есть какая-то точка, откуда вылетело исключение.
Как вариант — настроить систему на авто-сбор дампов:

Collecting User-Mode Dumps
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx

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

ksd>есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.

Советую как можно быстрее забыть от AppInit_DLLs в пользу чего-нибудь другого.
Во-первых, не работает на Win8+ при включенном Secure Boot.
Во-вторых, не предусмотрена система исключений. Например, у меня winlogon.exe
падал только из-за того, что загруженная dll вызывала какую-то функцию
из shell32.dll. А если я не хочу загружаться в winlogon.exe, что тогда?
В-третьих, момент загрузки dll не определен и это может стать источником дополнительных проблем
(некоторые остальные системные dll могут быть еще не инициализированы).

ksd>под заменой подразумевается переименовать текущую, записать в system32 новую, запустить что-нибудь, ну, cmd.exe, например. и получается вот очень

Предлагаю эксперимент: собрать максимально примитивную dll без какой-либо функциональной нагрузки,
просто DllMain и все. И проверить, будет ли воспроизводиться на ней. Если да — проблема в Windows.
Если нет — проблема в dll (99%, что так оно и есть).

Здравствуйте, ksd, Вы писали:

Ещё вариант для анализа:
написать вторую dll-ку, которая будет инжектиться и собирать нужную информацию относительно того, что происходит с первой dll-кой.
а так же всё-таки попробовать выгрузить 1-ю dll из памяти перед тем, как физически её заменять на другую.

ksd>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>после перезапуска системы все работает нормально.
ksd>может, кто то сталкивался с проблемой? что делать? где концы искать?
1) CreateRemoteThread/ReadVirtualMemory/WriteVirtualMemory в коде наличествует?
2) IPC с передачей указателей на код (функции) длл наличествует?
3) #pragma comment(linker, "/SECTION:БЛАБЛАБЛА,RWS") гденить есть? или /SECTION:БЛАБЛАБЛА,RWS в параметрах линкера?
4) а поговорить А в дебаггере посмотреть, что именно падает, с каким стеком, подумать над полученной информацией — пробовали?
5) SetWindowsHookEx не используется ли с функцией внутри этой длл?

была такая фигня, еле систему восстановил по моему спасет статический рантайм

Здравствуйте, ononim, Вы писали:

ksd>>ну, есть dll-ка, монитор, которая аттачится ко всем процессам в системе через appinit_dlls.
ksd>>при замене этой dll-ки на новую версию начинают все новые запущенные процессы валится.
ksd>>после перезапуска системы все работает нормально.
ksd>>может, кто то сталкивался с проблемой? что делать? где концы искать?
O>1) CreateRemoteThread/ReadVirtualMemory/WriteVirtualMemory в коде наличествует?
O>2) IPC с передачей указателей на код (функции) длл наличествует?
O>3) #pragma comment(linker, "/SECTION:БЛАБЛАБЛА,RWS") гденить есть? или /SECTION:БЛАБЛАБЛА,RWS в параметрах линкера?
этого нет
O>4) а поговорить А в дебаггере посмотреть, что именно падает, с каким стеком, подумать над полученной информацией — пробовали?
при запуске же нового процесса падает, как отладчиком цепляться на запуске?
O>5) SetWindowsHookEx не используется ли с функцией внутри этой длл?
используется.

O>>1) CreateRemoteThread/ReadVirtualMemory/WriteVirtualMemory в коде наличествует?
O>>2) IPC с передачей указателей на код (функции) длл наличествует?
O>>3) #pragma comment(linker, "/SECTION:БЛАБЛАБЛА,RWS") гденить есть? или /SECTION:БЛАБЛАБЛА,RWS в параметрах линкера?
ksd>этого нет
O>>4) а поговорить А в дебаггере посмотреть, что именно падает, с каким стеком, подумать над полученной информацией — пробовали?
ksd>при запуске же нового процесса падает, как отладчиком цепляться на запуске?
1) запускать под отладчиком
2) запускать под отладчиком установив галку debug child processes чтото другое, например cmd.exe, при этом на время запуска cmd.exe убрать длл. Потом вернуть длл и запустить из cmd.exe то что падает

O>>5) SetWindowsHookEx не используется ли с функцией внутри этой длл?
ksd>используется.
Теперь смотрите. Если вы используете эту ф-ю для того чтоб ставить глобальный хук, то передаете аргументами системе HINSTANCE длл и указатель на функцию — колбяку хука. Система чудес не творит. Она по этому HINSTANCE получает путь к длл, а указатель на функцию превращает в смещение относительно базы длл. В каждом новом процессе она будет загружать длл по полученному пути и добавлять к полученной базе известное ей смещение. Если по заданному пути окажется другая длл, то по этому смещению скорее всего будет совсем не то, что было по первоначальной длл.