在 x64 中第二次 RichEdit 初始化后崩溃
根据 使用 Rich Edit Controls 我使用RichEdit 的方式如下：
MyControl::OnCreate()
{
handle = LoadLibrary(_T("Riched20.dll"));
}
MyControl::OnDestroy()
{
FreeLibrary(handle);
}
它适用于 win32，但最近我构建了 x64 配置，现在我的控件在页面重新加载后失败。
我注意到，如果这样做：
MyControl::OnCreate()
{
handle = LoadLibrary(_T("Riched20.dll"));
FreeLibrary(handle);
handle = LoadLibrary(_T("Riched20.dll"));
}
一切正常。
我不想将此代码投入生产，那么有什么关于更好的解决方案/解决方法的建议吗？
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 if 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于报告的故障模块是 Richedit20.dll_unloaded，这意味着您正在卸载 DLL，而其中的代码仍在使用中。
例如，如果在（完全）释放 DLL 时仍然打开着 RichEdit 窗口，那么一旦任何事件触发对控件的 window-proc 的调用，您就会看到类似的崩溃。这是因为控件的 window-proc 位于卸载的 DLL 代码内。
多次调用 LoadLibrary 和 FreeLibrary 应该是安全的（只要调用平衡），所以我怀疑这就是问题所在。它可能只是触发问题。此外，这个问题也存在于 32 位版本中；你只是运气好，从未触发过它。
OnDestroy 是调用 FreeLibrary 的错误位置。 有几个窗口消息会在 WM_DESTROY 之后发送到窗口（例如 WM_NCDESTROY）。
当调用 OnDestroy 时，子窗口仍然存在。如果 Richedits 是您的控件的子级（而不是控件本身），那么将 FreeLibrary 移至 OnNcDestroy 可能会拯救您。 （子窗口在调用 WM_NCDESTROY 时被销毁。）但是，我仍然会说这不是释放库的好地方。
所以你肯定想移动你的 FreeLibrary 调用。我会将它和 LoadLibrary 完全移出控制本身。在创建库实例时控制加载/释放库是不正常的。相反，在某处放置一些静态 init/uninit 代码，这些代码可以一劳永逸地加载您需要的库，并在应用程序关闭时释放它们。
（如果您的应用程序很少使用该控件，那么仅当使用该控件的窗口处于活动状态时加载/释放库可能才有意义。不过，这种情况很少见。通常您最好只保留加载的 DLL。）
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.)