Crash after the second RichEdit initialization in x64

According to Using Rich Edit Controls I use RichEdit in such way:

MyControl::OnCreate()
{
    handle = LoadLibrary(_T("Riched20.dll"));
}

MyControl::OnDestroy()
{
    FreeLibrary(handle);
}

It works fine for win32 but recently I’ve built x64 configuration and now my control fails after the page reload.

I’ve noticed that 开发者_如何学JAVAif do this:

MyControl::OnCreate()
{
    handle = LoadLibrary(_T("Riched20.dll"));
    FreeLibrary(handle);
    handle = LoadLibrary(_T("Riched20.dll"));
}

everything works fine.

I don't wish to put this code into production, so is there any suggestions about better solution/workaround?

Since the reported fault module is Richedit20.dll_unloaded it means you are unloading the DLL while code from it is still in use.

For example, if you still have a richedit window open when you (completely) free the DLL, you can see crashes like that as soon as anything triggers a call to the control's window-proc. This is because the control's window-proc was inside the unloaded DLL code.

It should be safe to call LoadLibrary and FreeLibrary multiple times (so long as the calls balance out), so I doubt that is the problem. It may just be triggering the problem. Also, the problem was there in 32-bit builds; you just got lucky and never triggered it.

OnDestroy is the wrong place to call FreeLibrary. There are several window messages which get sent to a window after WM_DESTROY (e.g. WM_NCDESTROY).

Child windows also still exist when OnDestroy is called. If the richedits are children of your control (rather than the control itself) then moving the FreeLibrary into OnNcDestroy may save you. (Child windows are destroyed by the time WM_NCDESTROY is called.) I'd still say it's not a good place to free the library, however.

So you definitely want to move your FreeLibrary call. I would move both it and the LoadLibrary completely out of the control itself. It's not normal to have controls which load/free libraries whenever an instance of them is created. Instead, have some static init/uninit code somewhere which loads the libraries you need once and for all and frees them when the application is shutting down.

(If your app only rarely uses the control then it might make sense to load/free the library only when windows using the control are active. That situation is rare, though. Usually you're better off just leaving the DLL loaded.)