Как перезагрузить стороннюю DLL, которая часто вылетает - PullRequest
3 голосов
/ 11 декабря 2008

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

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

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

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

Есть предложения? Указатели? Подсказки?

Ответы [ 4 ]

10 голосов
/ 19 декабря 2008

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

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

4 голосов
/ 11 декабря 2008

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

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

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

0 голосов
/ 11 декабря 2008

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

0 голосов
/ 11 декабря 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...