На всякий случай — враппер делал на основе статьи Пола Дилации из MSDN Magazine за апрель 2005-го года. ManWrap его проект называется. Потом он еще одну статью написал, где адаптировал свои наработки под новый синтаксис C++, появившийся в VS 2005, но точного номера я не помню.
Ситуация: есть библиотека dll, содержащая несколько объектов ATL. Она скомпилирована в MS Visual C++ 2003, с ключом /clr, поскольку в одном объекте ипользуется обращение к .NET сборке (запрашивается remoting-объект). В модули, где .NET не нужен, вставлено #pragma unmanaged
Все отрабатывает нормально, за исключением того, что когда закрывается хост-приложение и выгружает мою длл, выдается исключение
The exception unknown software exception (0xc0020001) occurred in the application at location 0x7c81eb33.
WinDbg показывает следующую информацию:
ERROR_CODE: (NTSTATUS) 0xc0020001 — The string binding is invalid.
В чем может быть дело? Я не провожу у себя в длл никаких GC.Collect(), GC.WaitForPendingFinalizers() и прочего, просто закрываю коннект с ремоутинг-сервером.
Здравствуйте, Legion13, Вы писали:
L>The exception unknown software exception (0xc0020001) occurred in the application at location 0x7c81eb33.
L>WinDbg показывает следующую информацию: L>ERROR_CODE: (NTSTATUS) 0xc0020001 — The string binding is invalid.
Та же фигня. Есть сборка в .dll, в ней используется PWLIB и OPAL.
Legion13, Вам удалось решить проблему?
Здравствуйте, Legion13, Вы писали:
L>В чем может быть дело? Я не провожу у себя в длл никаких GC.Collect(), GC.WaitForPendingFinalizers() и прочего, просто закрываю коннект с ремоутинг-сервером. L>Очень надеюсь на помощь, бьюсь уже 2 дня.
Простой вариант возвращать из DllCanUnloadNow S_FALSE (если уверены, что проблема точно не ваша). С другой стороны, проблемы как таковой в DllCanUnloadNow быть не должно. Попробуйте воспользоваться отладочными символами (как своими так и от microsoft) для точного проделения места возникновения проблемы.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Legion13, Вы писали:
L>>В чем может быть дело? Я не провожу у себя в длл никаких GC.Collect(), GC.WaitForPendingFinalizers() и прочего, просто закрываю коннект с ремоутинг-сервером. L>>Очень надеюсь на помощь, бьюсь уже 2 дня.
TK>Простой вариант возвращать из DllCanUnloadNow S_FALSE (если уверены, что проблема точно не ваша). С другой стороны, проблемы как таковой в DllCanUnloadNow быть не должно. Попробуйте воспользоваться отладочными символами (как своими так и от microsoft) для точного проделения места возникновения проблемы.
Разобрался. Дело было в том, что не была инициализирована CRT.
Добавал __crt_dll_initialize() и __crt_dll_terminate, всё стало работать нормально (т.е. пропала ошибка при выгрузке).
Что касается символов — то у меня почему-то отладчик не проваливается в функции из позцепленных статических либов (я писал об этом здесь
BE>Разобрался. Дело было в том, что не была инициализирована CRT. BE>Добавал __crt_dll_initialize() и __crt_dll_terminate, всё стало работать нормально (т.е. пропала ошибка при выгрузке).
BE>Что касается символов — то у меня почему-то отладчик не проваливается в функции из позцепленных статических либов (я писал об этом здесь
Проблему решил (точнее, не решил, а пока проигнорировал).
Краткое описание: проблемную библиотеку я разделил — всю основную начинку скомпилировал в unmanaged-код, и сделал еще одну dll — враппер, который скомпилирован с ключом /clr и обращается к дотнетовским сборкам. Враппер линкуется к основной библиотеке.
Как только я все это проделал, отладчик тут же показал, какой именно метод выдаети ошибку — это был метод Disconnect, который вызывает враппер, враппер вызывает интерфейсную сборку и т.д. В результате на сервере должен вызваться метод Disconnect, который, по задумке, освобождат все ресурсы, затребованные клиентом.
С наскоку выявить причину обвала не удалось (вроде бы какой-то объект помер, но считается живым), поэтому ее временно отставили, очиску ресурсов решили другими методами.
Здравствуйте, Legion13, Вы писали:
L>Проблему решил (точнее, не решил, а пока проигнорировал). L>Краткое описание: проблемную библиотеку я разделил — всю основную начинку скомпилировал в unmanaged-код, и сделал еще одну dll — враппер, который скомпилирован с ключом /clr и обращается к дотнетовским сборкам. Враппер линкуется к основной библиотеке.
Я уже тоже склоняюсь к такому решению.
С этой выгрузкой вообще какие-то чудеса творятся. После добавления __crt_dll_initialize() и __crt_dll_terminate в DEBUG-билде ошибка при выгрузке исчезла, а в RELEASE — осталась!
Вообще чушь какая-то...