加载卸载含C++代码的DLL后调用GetOpenFileName()崩溃的解决方法

你的核心问题是：MSYS2 GCC编译的DLL被VC编译的主程序加载并卸载后，调用GetOpenFileName会触发崩溃，崩溃地址指向已卸载的DLL。根源在于：

1. 你编译DLL时静态链接了大量依赖库（glib、pango、cairo等），这些库在DLL加载时会初始化全局对象、注册系统回调/钩子（如GDI、字体相关），卸载DLL时这些对象被析构，但系统仍持有指向DLL内存的引用，GetOpenFileName调用时会访问已释放的内存。
2. GCC的C++异常处理机制与VC不兼容，即使未调用DLL函数，加载卸载过程也会在进程异常处理链中留下失效的回调地址，GetOpenFileName内部触发异常（哪怕是内部处理的）时会访问已卸载的DLL区域。

1. 改用动态链接依赖库（优先推荐） #

将编译命令中静态链接的依赖库改为动态链接，让依赖库的全局状态保留在各自的DLL中，避免卸载你的DLL时破坏系统相关状态。

修改后的编译命令：

# 编译dll.c为目标文件
gcc -DNDEBUG -I/c/msys64/mingw64/include/pango-1.0 -I/c/msys64/mingw64/include/cairo -I/c/msys64/mingw64/include/glib-2.0 -I/c/msys64/mingw64/include/harfbuzz -I/c/msys64/mingw64/include/freetype2 -I/c/msys64/mingw64/include -I/c/msys64/mingw64/lib/glib-2.0/include -fvisibility=hidden -c -o dll.o dll.c

# 编译为动态链接的DLL
gcc -shared -fPIC -o test.dll dll.o -L/c/msys64/mingw64/lib -lpangocairo-1.0 -lpangoft2-1.0 -lpangowin32-1.0 -lpango-1.0 -lharfbuzz -lcairo -lpixman-1 -lgraphite2 -lfontconfig -lfreetype -lbrotlidec -lbrotlienc -lbrotlicommon -lexpat -lthai -ldatrie -lbz2 -lpng -lz -lfribidi -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lpcre2-8 -lpcre2-16 -lpcre2-32 -lpcre2-posix -lffi -luuid -lintl -liconv -lstdc++ -lgcc_eh -lpthread -lshlwapi -ldwrite -lWs2_32 -lrpcrt4 -lshell32 -lmsimg32 -lusp10 -lgdi32 -lole32

• 移除-static-libgcc -static-libstdc++和-Wl,-Bstatic，让所有依赖库动态链接。
• 确保MSYS2的动态库（如libglib-2.0-0.dll、libpango-1.0-0.dll等）与你的DLL放在同一目录，或加入系统PATH。

2. 显式控制DLL的初始化与清理 #

若必须静态链接依赖库，需手动管理库的初始化和清理，避免全局对象析构残留系统引用。在DLL中添加DllMain函数：

#include <windows.h>
#include <glib.h>
#include <pango/pango.h>
#include <cairo/cairo.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
        case DLL_PROCESS_ATTACH:
            // 初始化依赖库
            g_type_init();
            break;
        case DLL_PROCESS_DETACH:
            // 强制清理所有全局状态
            cairo_debug_reset_static_data();
            pango_shutdown();
            break;
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
            break;
    }
    return TRUE;
}

注意：部分库可能不支持在DLL中动态卸载，此方法仅作为备选。

3. 禁用C++异常处理 #

若你的DLL代码不需要C++异常，可通过编译选项移除异常处理链的残留：

gcc -DNDEBUG -fno-exceptions -I/...（其他编译参数）-c -o dll.o dll.c

该选项会阻止DLL向进程注册C++异常回调，避免卸载后异常处理链访问失效地址。

4. 延迟卸载到UI操作完成后 #

若以上方法无法完全解决，可在主程序中确保所有系统UI操作（如GetOpenFileName）完成后，再调用FreeLibrary。可封装为程序退出前的统一清理逻辑。

修改编译命令后重新编译DLL和主程序，执行「加载DLL→卸载DLL→调用GetOpenFileName」流程，检查是否崩溃。

内容的提问来源于stack exchange，提问作者Andreas