自研游戏引擎多DLL依赖下关闭阶段触发0x0000执行访问违规求助

触发 Access violation executing location 0x00000000 属于销毁阶段调用无效函数指针的典型表现，结合你的架构和依赖配置，问题集中在三类场景：

1. 跨DLL内存管理冲突：所有模块独立静态链接mimalloc、eastl时，每个模块持有独立的内存堆和库全局状态，跨模块释放内存、析构eastl容器时会触发内存访问错误，仅在资源销毁阶段触发
2. DLL卸载顺序异常：你的架构中Sandbox同时依赖两个DLL，若Windows卸载DLL时SRendererVulkan先于SCore卸载，SCore或Sandbox中持有的渲染模块函数指针、虚函数表会随DLL卸载失效，销毁时调用就会触发空地址执行
3. 跨DLL静态对象析构顺序错乱：不同DLL的全局/静态对象析构顺序无明确约定，若某模块的静态对象析构时调用了已被析构的其他模块静态对象的方法，也会触发该错误

• 内存管理一致性修复
  • 调整premake配置，将mimalloc、eastl改为动态库编译，所有上层DLL和主程序统一动态链接这两个库，保证全局共用同一内存堆和库状态
  • 所有跨DLL传递的对象，由分配对象的模块提供专属的销毁接口，禁止跨模块直接delete、析构外部模块分配的对象或eastl容器
• DLL卸载顺序修复
  • 显式控制资源销毁时机：主窗口关闭后，先手动调用SRendererVulkan提供的全量资源销毁接口释放所有渲染资源，再调用SCore的全局资源销毁接口，确保所有资源在对应DLL卸载前完成释放
  • 调整Sandbox的链接顺序，保证链接时先关联SCore再关联SRendererVulkan，使加载顺序为SCore -> SRendererVulkan -> Sandbox，对应卸载顺序为Sandbox清理 -> SRendererVulkan卸载 -> SCore卸载，避免依赖模块提前卸载
• 接口兼容性修复
  • 所有跨DLL导出的接口类添加虚析构函数，禁止在DLL对外接口中直接暴露eastl容器、内存分配相关的类型，仅使用纯虚接口或C兼容类型传递参数
  • 调试时抓取崩溃的调用栈，确认触发异常的调用点是否为虚函数调用、外部模块传入的函数指针调用，针对性校验指针有效性

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