我正在开发一个在 Windows 上崩溃的跨平台 Firebreath 插件。我使用包含引用 boost.asio 的类的静态库。当我将此库与插件 dll 链接时，我观察到在与 io_service 子系统交互时（即在套接字构造期间）发生崩溃。当我将静态库链接到普通可执行文件时，不会出现问题。当我将静态库的内容直接编译到插件dll项目中时，crash并没有发生。我已经竭尽全力确保我在 Windows 上构建环境的所有方面都是一致的（构建模式、Visual Studio 版本等）。此外，我对 boost.asio 标头进行了防火墙保护，因此插件 dll 代码无法看到 boost.asio 子系统（不幸的是，vs2008 和 vs2010 无效）。据我所知，我已尽一切可能确保构建环境运行良好，但问题仍然存在。
社区能否就可能暴露或解决问题的潜在风险或方法提供任何建议？
链接静态库与加载 DLL 之间有两点截然不同：
全局初始化：在一个 DLL 中，它们都运行。在静态库中，链接器仅在满足某些未解析的外部时才引入目标文件，因此依赖于使用全局对象的构造函数或初始化表达式注册自己的组件的系统会失败。
共享 CRT：在静态库中，对标准库的所有调用都在链接时解决，主应用程序和库函数都调用标准库的同一副本。在 DLL 中，您可能会拥有标准库的两个副本，如果您小心不要在库和应用程序之间共享任何标准库对象（如FILE*、std::string或什至malloc/free对），则可以这样做。
第二件事很可能是什么在咬你。有一种懒惰的方法来修复它：使用标准库 DLL，以及更好的修复方法：计算内存和对象的生命周期，不要尝试一边分配一边释放，或者共享 C++ 类布局边界。虚函数可以在边界上正常工作。
“更好”方式的优点是可以在任何版本的编译器中构建插件，这对于开发周期后期的维护来说是一件大事。
在 FireBreath 插件准备脚本中，尝试打开 WITH_DYNAMIC_MSVC_RUNTIME 标志。