Как перезагрузить стороннюю DLL, которая часто дает сбой
Я использую стороннюю DLL, написанную на неуправляемом C++, которая управляет некоторым оборудованием, которое у нас есть.
К сожалению, эта DLL время от времени дает сбой, и мне было поручено «перезагрузить» ее автоматически. Я не совсем уверен, что делать дальше, чтобы добиться наилучших результатов.
В моем проекте используется C++. Net 2.0 (2005 г.). Я оборачиваю сторонние материалы в отдельную DLL. Я пробовал FreeLibrary () и LoadLibrary (). Однако, когда я использую FreeLibrary (), некоторые внутренние зависимости DLL остаются выделенными, и LoadLibrary () приведет к сбою из-за поврежденной памяти.
Другой подход, который был предложен, заключался в рефакторинге всего проекта с использованием интерфейсов удаленного взаимодействия .NET. Было бы проще убить другой процесс и перезапустить его, но это потребует много работы.
Какие-либо предложения? Указатели? Подсказки?
Ответы 4
Я не эксперт по Windows, но думаю, что общая идея должна поддерживаться.
LoadLibrary, FreeLibrary занимаются отображением библиотеки DLL в область памяти процесса. Повреждение, которое вы видите, вероятно, связано с тем, что какой-то код внутри DLL делает что-то «плохое» и почти наверняка повреждает память процесса. Теперь, если происходит сбой, это почти наверняка убивает поток, в котором он работал, если не весь процесс.
Я бы сделал обоснованное предположение, что единственный способ надежно восстановить и гарантировать неповрежденную память - это запустить жертвенный процесс в качестве оболочки для мошеннической DLL. Я предполагаю, что интерфейсы удаленного взаимодействия - один из способов сделать это. Могут быть и другие.
LoadLibrary и FreeLibrary - это начало, но затем вам нужно обернуть все вызовы в DLL в блоках SEH (структурированная обработка исключений) __try / __catch, если вы хотите избежать сбоя в DLL. N.B. это сильно отличается от исключений C++ и блоков try / catch. См. MSDN для получения дополнительной информации.
Если сама DLL дает сбой, и ваша компания пойдет на это, возможно, стоит потратить время на ее воссоздание. Лучше исправить проблему, чем просто перевязать ее.
Если вы не собираетесь заниматься реверс-инжинирингом, это, вероятно, невозможно. Это могло бы быть разумным предложением только для программных DLL, но для драйверов это непрактично.
Я не могу этого сделать, поскольку DLL напрямую взаимодействует с проприетарным оборудованием, о котором я ничего не знаю. Кроме того, существует множество очень сложных математических алгоритмов, в которых задействованы такие
Самый эффективный подход - вообще не загружать эту DLL в процесс вашего приложения. Вместо этого создайте второй процесс, единственная задача которого - использовать эту DLL от имени вашего приложения. Вы можете использовать область общей памяти, локальный сокет или другой механизм IPC для управления процессом прокси.
Таким образом, когда проблемная DLL выходит из строя, вы можете просто позволить прокси-процессу умереть, не беспокоясь о (почти невыполнимой) задаче убедиться, что DLL не повредила ничего важного на своем пути. Вашему основному процессу нужно только запустить новый экземпляр процесса прокси и продолжить.
Верно, и для нативного кода вы никогда не знаете, какую память (структуры) он повредил - включите собственные CLR.