Поскольку указанный модуль неисправности - Richedit20.dll_unloaded, это означает, что вы выгружаете DLL, пока код из нее все еще используется.
Например, если у вас по-прежнему открыто окно richedit, когда вы (полностью)Освободив DLL, вы можете увидеть такие сбои, как только что-нибудь вызовет вызов в window-proc элемента управления.Это связано с тем, что window-proc элемента управления был внутри выгруженного кода DLL.
Безопасно вызывать LoadLibrary и FreeLibrary несколько раз (при условии, что вызовы уравновешиваются), поэтому я сомневаюсь, что это проблема.Это может быть причиной проблемы.Кроме того, проблема была в 32-битных сборках;вам просто повезло, и вы никогда не вызывали его.
OnDestroy - неподходящее место для вызова FreeLibrary. Есть несколько оконных сообщений, которые отправляются окну после WM_DESTROY (например, WM_NCDESTROY).
Дочерние окна также все еще существуют при вызове OnDestroy.Если средства являются дочерними элементами вашего элемента управления (а не самого элемента управления), перемещение FreeLibrary в OnNcDestroy может спасти вас.(Дочерние окна разрушаются к тому времени, когда вызывается WM_NCDESTROY.) Однако я все же сказал бы, что это не очень хорошее место для освобождения библиотеки.
Так что вы определенно хотите переместить вызов FreeLibrary.Я бы переместил и его, и LoadLibrary полностью из самого элемента управления.Нормально иметь элементы управления, которые загружают / освобождают библиотеки, когда создается их экземпляр.Вместо этого, где-нибудь есть статический код init / uninit, который загружает нужные вам библиотеки раз и навсегда и освобождает их при завершении работы приложения.
(Если ваше приложение использует элемент управления очень редко, тогда может иметь смыслзагружать / освобождать библиотеку только тогда, когда окна, использующие элемент управления, активны. Однако такая ситуация встречается редко. Обычно лучше просто оставить DLL загруженной.)