Как перезагрузить стороннюю DLL, которая часто вылетает

Я использую стороннюю библиотеку DLL, написанную на неуправляемом C ++, которая управляет некоторым оборудованием, которое у нас есть.

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

Мой проект использует C ++. Net 2.0 (2005). Я упаковываю сторонние вещи в отдельную DLL. Я пытался FreeLibrary () и LoadLibrary (). Однако, когда я выполняю FreeLibrary (), некоторые внутренние зависимости DLL остаются выделенными, и LoadLibrary () приводит к сбою из-за повреждения памяти.

Другой подход, который был предложен, заключался в рефакторинге всего проекта с использованием интерфейсов удаленного взаимодействия .NET. Было бы проще убить другой процесс и перезапустить его, но это будет много работы.

Какие-либо предложения? Указатели? Советы?

10.12.2008 22:53:52
4 ОТВЕТА
РЕШЕНИЕ

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

Таким образом, в случае сбоя проблемной DLL вы можете просто позволить прокси-процессу прекратить работу, не беспокоясь о (почти невозможной) задаче - убедиться, что DLL не повредила ничего важного на пути вниз. Ваш основной процесс должен только запустить новый экземпляр процесса прокси и продолжить.

10
19.12.2008 15:39:08

Я не специалист по Windows, но я думаю, что общая идея должна иметь место.

LoadLibrary, FreeLibrary имеют дело с отображением DLL в пространство памяти процесса. Повреждение, которое вы видите, возможно, связано с тем, что какой-то код внутри DLL делает что-то «плохое» и почти наверняка повреждает память процесса. Теперь, если происходит сбой, он почти наверняка уничтожит поток, в котором он работал - если не весь процесс.

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

4
10.12.2008 23:03:57
Правильно, а для нативного кода вы никогда не знаете, какую память (структуры) он испортил - включая собственные CLR.
Christian.K 11.12.2008 16:44:55

LoadLibrary и FreeLibrary являются началом, но затем вам нужно обернуть все вызовы в DLL в блоках SEH (обработка структурированных исключений) __try / __catch, если вы хотите избежать аварийного сбоя в DLL. Примечание: это сильно отличается от исключений в C ++ и блоков try / catch. См. MSDN для получения дополнительной информации.

0
11.12.2008 04:23:36

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

0
11.12.2008 04:35:01
Если вы не собираетесь перепроектировать это, вероятно, это невозможно. Это может быть разумным предложением только для программных DLL, но для драйверов это не практично.
Draemon 11.12.2008 17:14:39
Я не могу этого сделать, поскольку DLL напрямую взаимодействует с проприетарным оборудованием, о котором я ничего не знаю. Кроме того, есть много очень сложных математических алгоритмов, связанных с таким
Eric 11.12.2008 18:56:33