Здравствуйте.

Ситуация: есть библиотека 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.

STACK_TEXT:
0012faf4 792a93d9 c0020001 00000001 00000001 kernel32!RaiseException+0x53
0012fb0c 792c52bd 8007042b 06485db0 0012fb44 mscorwks!COMPlusThrowBoot+0x1c
0012fb1c 792e1214 064912e0 08e02130 06485db0 mscorwks!UMThunkStubRareDisableWorker+0x4d
0012fb38 06809a9d 06938b4c 0012fb58 7752d183 mscorwks!UMThunkStubCache::CompileMLStub+0x60a
0012fb44 7752d183 06485db0 0012fb64 00000000 NativeClient!_DllCanUnloadNow+0xd (это моя длл)
0012fb58 7752d462 ffffffff 774e1ae8 00000000 ole32!CClassCache::CDllPathEntry::CanUnload_rl+0x3b
0012fc98 7752d3be ffffffff 00144e40 0012fcd0 ole32!CClassCache::FreeUnused+0x70
0012fca8 7752d1e9 ffffffff 00000000 5dc65f79 ole32!CoFreeUnusedLibrariesEx+0x36
0012fcb4 5dc65f79 00000000 5dc6a95b 00000000 ole32!CoFreeUnusedLibraries+0x9
WARNING: Stack unwind information not available. Following frames may be wrong.

В чем может быть дело? Я не провожу у себя в длл никаких GC.Collect(), GC.WaitForPendingFinalizers() и прочего, просто закрываю коннект с ремоутинг-сервером.

Очень надеюсь на помощь, бьюсь уже 2 дня.

Здравствуйте, 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, всё стало работать нормально (т.е. пропала ошибка при выгрузке).

Что касается символов — то у меня почему-то отладчик не проваливается в функции из позцепленных статических либов (я писал об этом здесь

Автор: BoresExpress
Дата: 24.08.07

).

BE>Разобрался. Дело было в том, что не была инициализирована CRT.
BE>Добавал __crt_dll_initialize() и __crt_dll_terminate, всё стало работать нормально (т.е. пропала ошибка при выгрузке).

BE>Что касается символов — то у меня почему-то отладчик не проваливается в функции из позцепленных статических либов (я писал об этом здесь

Автор: BoresExpress
Дата: 24.08.07

).

Проблему решил (точнее, не решил, а пока проигнорировал).
Краткое описание: проблемную библиотеку я разделил — всю основную начинку скомпилировал в unmanaged-код, и сделал еще одну dll — враппер, который скомпилирован с ключом /clr и обращается к дотнетовским сборкам. Враппер линкуется к основной библиотеке.
Как только я все это проделал, отладчик тут же показал, какой именно метод выдаети ошибку — это был метод Disconnect, который вызывает враппер, враппер вызывает интерфейсную сборку и т.д. В результате на сервере должен вызваться метод Disconnect, который, по задумке, освобождат все ресурсы, затребованные клиентом.

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

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

L>Проблему решил (точнее, не решил, а пока проигнорировал).
L>Краткое описание: проблемную библиотеку я разделил — всю основную начинку скомпилировал в unmanaged-код, и сделал еще одну dll — враппер, который скомпилирован с ключом /clr и обращается к дотнетовским сборкам. Враппер линкуется к основной библиотеке.

Я уже тоже склоняюсь к такому решению.
С этой выгрузкой вообще какие-то чудеса творятся. После добавления __crt_dll_initialize() и __crt_dll_terminate в DEBUG-билде ошибка при выгрузке исчезла, а в RELEASE — осталась!
Вообще чушь какая-то...

BE>Я уже тоже склоняюсь к такому решению.

На всякий случай — враппер делал на основе статьи Пола Дилации из MSDN Magazine за апрель 2005-го года. ManWrap его проект называется. Потом он еще одну статью написал, где адаптировал свои наработки под новый синтаксис C++, появившийся в VS 2005, но точного номера я не помню.