1. 先搞清楚 R6025 到底在说什么1.1 什么是纯虚函数调用错误先别急着百度那个英文报错框R6025 这个错误全称是Runtime Error! Program: ... R6025 - pure virtual function call。它是 Microsoft Visual C 运行时库MSVCRT / MSVCP抛出来的一个非常经典、也非常经典的场景。只要你用过 C 写过稍微大一点的程序或者装了某个用 C 写的商业软件十有八九遇到过这个弹窗。拆开来看报错名称里的 pure virtual function call 直译是纯虚函数调用。在 C 里纯虚函数是基类中以virtual void Func() 0;形式声明的函数它本身没有实现是给派生类定的接口契约。正常情况下你永远不会直接调用一个纯虚函数——因为它是没有函数体的调了就要出事。但 R6025 这个错误正是程序在某个时间点真的去调了一个当前对象根本没法响应的纯虚函数。为什么说当前对象没法响应因为 C 的虚函数分发走的是虚函数表vtable对象内存里本身就藏着一个指向 vtable 的指针。当一个对象被销毁到一半、或者构造到一半时vtable 指针可能还指向基类那一层——而基类的纯虚函数在 vtable 里填的是运行时库预先放好的一个错误触发桩stub。你一调用运行时库一看是调用到了这个桩就直接弹出 R6025顺便帮你打印一个崩溃点。我拿个生活化一点的例子类比就像你给某个部门打电话结果电话那头是空号提示音但你明明是从通讯录里翻出来的号码。问题多半不在按了拨号键这个动作而在通讯录里的号码已经失效或者部门已经合并撤销了。R6025 弹出来其实就是一个号码失效却还在播的信号。1.2 为什么这个错误如此阴魂不散很多人的第一反应是重装程序结果发现更烦人的是重装完了没几天又弹出来。为什么 R6025 这么难缠因为它的触发大多不是单一原因而是跨模块生命周期管理出问题。一般常见的触发类型有几种对象已被销毁但还有别的地方拿着它的指针或引用不放比如窗口关了、对话框关了但某个后台线程还拿着这个窗口对象的指针去调成员函数。如果这个类的析构函数里没有把虚函数表指针重置又或者调用点晚于析构完成就会撞上纯虚函数桩。构造函数或析构函数中直接或间接调用了虚函数这是 C 书里讲了八百遍的常识。在基类构造期间对象的动态类型是基类不是派生类。此时调用一个虚函数根本不会分发到派生类版本如果这个虚函数刚好是纯虚函数那就是 100% 触发 R6025。DLL 与插件边界问题程序通过动态链接库DLL加载插件插件里导出了一些接口。若 DLL 内部自己维护了一个对象池而宿主程序在卸载 DLL 时没有先把所有对象清理干净就会出现调用还在、实现已卸载的状态。也可以说vtable 跟着 DLL 一起被卸载了指针悬空了再调用就崩。多线程并发销毁与使用一个线程正在delete对象另一个线程还在调它的方法。这种竞态条件在 Release 版里特别难复现但在用户的机器上却可能频繁爆炸。一句话总结大多数 R6025 不是代码写错了写出了一个纯虚函数调用而是对象生命周期管理出了问题导致在对象不可用的状态下代码仍尝试走虚函数分发。把思路转到生命周期管理上后面排查才有方向。2. 哪种场景最容易撞鬼高发场景实况2.1 程序启动和退出时的高危地带从实际操作来看R6025 不是随机出现的它有非常明显的时间窗口。统计下来,启动阶段的加载顺序问题、退出阶段的资源释放顺序问题占了故障数量的一大半。启动阶段如果你在全局对象或静态对象的构造函数里做了一些 花活比如启动了线程、调了某个模块注册的回调而那个模块还没完成初始化那么回调触发时可能调到一个初始化尚未完成的虚函数表。更隐蔽的是某些程序会把应用初始化成功的标记放在全局对象构造之后但全局对象的构造顺序在不同编译器、不同优化等级下并不完全保证。一旦出现跨翻译单元的初始化顺序逆差加载阶段就会撞 R6025。退出阶段程序退出时全局/静态对象会按构造的逆序析构。如果你的退出逻辑里一个网络线程还在回调、而持有该回调的全局对象已经被析构那么线程回调时一触发虚函数就会直接炸。我见过最典型的案例是一个后台更新线程在主窗口关闭后依然在运行里面调用了一个纯虚的OnProgress()接口而实现它的对象已经被主窗口析构掉了。结果就是每次关闭程序时有概率弹 R6025概率还不低。2.2 DLL、插件和 COM 组件的隐形边界凡是用了插件的程序R6025 的触发概率都会高一个量级。插件编程的本质就是让宿主程序在运行时加载一组未知的、可能由不同人编写的 DLL然后通过接口互相调用。这套机制看起来灵活但隐藏着一个很严重的生命周期问题插件 DLL 内部创建的 C 对象通常使用 DLL 自己的堆heap分配。如果宿主程序拿到这个对象的指针然后在 DLL 被卸载之后再去delete或调用其方法轻则触发 R6025重则整个进程直接崩溃。有些插件框架没有设计好卸载协议宿主程序卸载插件时直接把 DLL 释放掉而插件内部还在跑后台线程。线程里如果有虚函数调用就会命中已释放模块中的纯虚函数桩。还有一类高频触发源是 COM 组件。COM 接口本质上是一张纯虚函数表——是的COM 接口全部由纯虚函数组成这也就是 R6025 在 COM 场景里特别频发的原因。当你通过CoCreateInstance拿到一个 COM 对象指针但某个引用计数漏了Release或者对象已经跑到析构过程中再调用接口方法就会踩到纯虚函数桩。很多老的 ActiveX 控件崩在OnDestroy里就是这么来的。3. 定位问题从现象到根源的排查思路3.1 先看调用栈用调试器抓现行如果说 R6025 是一起交通事故那么调试器就是你的事故现场勘查工具。别急着猜是哪个软件的问题先想办法把案发现场抓下来。首选方案是使用 Visual Studio 自带的实时调试Just-In-Time Debugger功能或者用 WinDbg 挂到进程上。具体操作打开 Visual Studio或者单独装 Windows SDK 里的 WinDbg把调试器设置为实时调试器。复现 R6025 弹窗时选择调试程序让调试器附加到崩溃进程。在调试器的调用堆栈窗口查看当前线程的完整调用栈。关键就看栈顶是不是停在_purecall或__purecall这个符号上。如果能看到就顺着调用栈往下翻找到是哪个模块在调用、从哪个函数进来的。注意Release 版程序没有 PDB 符号文件时调用栈会是一堆地址看不到函数名。所以更实用的做法是在你自己程序崩溃时让 release 版也生成 PDB 文件并保留版本对应关系。哪怕没有 PDB至少能看到调用栈里各个 DLL 的模块名缩小排查范围。如果实在没法用调试器还可以用另一种办法把 Windows 错误报告WER的 LocalDumps 注册表项打开让系统在程序崩溃时自动生成 dump 文件。注册表位置在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps设置一个DumpFolder例如C:\Dumps再把DumpType设为 2完整转储。下次 R6025 一弹dump 文件就落盘了你再拿去分析。这个方法在客户机上特别好用。3.2 拆分变量最小化复现与排除外部干扰拿到调用栈只是第一步因为 R6025 的调用栈往往很短甚至只有两三层就断了真正的问题藏在上游的逻辑里。这时候就需要做变量剥离。我建议按下面这个顺序做排除免安装/绿色版测试把软件整个目录拷到一台干净的、刚装完系统的虚拟机里跑一遍。如果同样触发 R6025说明大概率是程序自身问题如果不再出现那很可能是宿主环境里某些软件注入了进程导致。关闭第三方可疑软件杀毒软件、输入法、屏幕取词翻译、系统优化工具、远程控制软件这些都爱往别的进程里注入 DLL。分批关闭它们再复现程序关闭操作排查是否是注入导致。更换运行时库版本安装最新版 Microsoft Visual C Redistributable包含 2005 到 2022 的各版本运行库排除运行库损坏的情况。这一步很无脑但确实能解决不少老程序的 R6025。跑系统文件检查以管理员身份运行sfc /scannow扫描被破坏的系统核心文件再配合DISM /Online /Cleanup-Image /RestoreHealth修复被篡改的系统映像。有些 R6025 问题其实是系统文件被第三方软件替换、损坏导致的尤其是老系统上非常常见。3.3 排查清单从进程外部到代码内部快速对照一下以下因素能让你少走很多弯路排查角度具体检查项优先级环境是否安装了匹配的 VC 运行库高环境显卡驱动、声卡驱动是否有更新或异常中环境是否被第三方软件注入杀毒、输入法高程序自身退出时是否有后台线程未停止高程序自身析构函数中是否调用了虚函数高程序自身全局对象是否有隐晦的循环依赖中程序自身插件 DLL 的加载卸载顺序是否正确中程序自身COM 引用计数是否正确释放中4. 实操修复不同场景对应的解决方案4.1 环境优先运行库检查、修复与更新在处理 R6025 时我个人的习惯是先动环境再动代码。因为环境问题最快能验证而且不用重新发布程序。首先检查系统里安装了哪些 Visual C 运行库。打开控制面板 - 程序和功能找 Microsoft Visual C Redistributable 相关项。比如Microsoft Visual C 2005 RedistributableMicrosoft Visual C 2008 RedistributableMicrosoft Visual C 2010 RedistributableMicrosoft Visual C 2012 RedistributableMicrosoft Visual C 2013 RedistributableMicrosoft Visual C 2015-2022 Redistributable如果缺失了某一项直接到微软官网下载对应的VC Redistributable安装包按需装齐。我见过很多老程序本身编译时用的是 VC 2008 的运行时但 Windows 10 或 Windows 11 默认不带这么老的运行库程序能装不能跑或者跑一阵就弹 R6025。把微软官方运行库合集装齐往往立竿见影。其次如果你的程序用到了 DirectX 图形接口也建议顺手装一下 DirectX End-User Runtime Web 安装程序。有些显卡驱动路径下的 DLL 会在特殊场景下触发 R6025尤其是老 DirectX 9 游戏或工业软件在双显卡笔记本上跑的时候。最后更新显卡驱动。NVIDIA、AMD、Intel 显卡驱动中与图形 API 相关的模块如果过旧也可能在某些绘制路径上触发 R6025。这个概率不算高但如果客户反馈只在特定电脑上出问题优先排查显卡驱动。4.2 代码层面的根治构造函数与析构函数的调用纪律如果你就是软件开发者想在自己的代码里避免 R6025那么第一条铁律就是不要在构造函数和析构函数中调用虚函数。这条规则所有 C 教材都会讲但工作中还是会有人踩原因在于间接调用。什么叫间接调用就是构造函数里你不直接调virtual void Foo()但你调了一个普通函数Init()而Init()内部调用了Foo()。这在编译期不会报错运行期也不会立即崩因为它调用的其实是当前构造阶段对应的那一层虚函数。但如果Foo()是纯虚函数在这一刻的基类构造阶段它就是会被解析到_purecall桩上。那怎么根除记住两个原则构造函数里只做基础类型和成员的初始化不启动任何可能依赖派生类行为的逻辑。如果确实需要在构造阶段完成某些多态行为改用两段式初始化先构造对象再调用一个显式的Init()方法让外部在对象完全构造好后触发派生类实现。析构函数同理。不要在析构函数里分发虚函数也不要在析构函数里启动线程的停止逻辑而期待派生类能响应回调。正确的做法是在析构的最开始先把所有线程join或停掉再释放成员最后进入基类析构。顺序千万别反否则线程回调很可能撞上正在销毁的对象。4.3 第三方组件与插件生命周期管理如果你是软件维护者但 R6025 出现在第三方插件或某个 SDK 的边界上情况会更棘手。好的方法是建立一套安全的插件接口会话管理机制插件加载成功后给每个插件实例分配一个独立的生命周期上下文对象。宿主程序卸载插件前必须通过一个反注册接口通知插件停止一切后台线程、释放所有资源并等待线程退出后再真正卸载 DLL。DLL 卸载之后在宿主侧确保没有任何悬空指针还能被访问。对于已经发布、没法改代码的存量程序还有一个很实用的兜底方案用屏蔽单线程单元或在独立进程中运行插件的思路隔离风险。比如某些老应用在 Windows 10 上频繁 R6025但同样的程序在 Windows 7 上没事就是因为新系统对进程加载、DLL 卸载的处理时序变了。这时候可以考虑用兼容模式运行程序右键程序 - 属性 - 兼容性 - 勾选以兼容模式运行这个程序选择 Windows 7 或 Windows XP SP3。这个土办法虽然不优雅但在很多工业上位机软件上确实能救急。4.4 自制崩溃拦截的备选技巧如果你维护的程序确实无法快速定位 R6025 的根源还有一个临时缓解手段在程序里拦截纯虚函数回调让它在触发的时候不要直接弹窗崩溃而是记录日志并尝试安全退出。虽然不能根治但至少能把崩溃现场的信息留下来。方法是在你的工程里定义一个全局函数并用_set_purecall_handler注册它。示例代码#include stdlib.h #include stdio.h void MyPureCallHandler() { // 把现场信息写入日志文件 FILE* f fopen(purecall_log.txt, a); if (f) { fprintf(f, R6025 pure virtual function call at %s %s\n, __DATE__, __TIME__); fclose(f); } // 这里可以选择直接退出避免继续执行不可信代码 abort(); }然后在程序入口最早期调用_set_purecall_handler(MyPureCallHandler);我没有把这个作为推荐方案是因为它并不能防止对象生命周期错乱导致的崩溃它只把触发点变成日志点可以不弹系统级报错框对终端用户体验稍微好一点。真正要解决问题还得靠前面的代码纪律。5. 实战案例复盘三次 R6025 的完整排查记录5.1 案例 A杀毒软件注入导致退出崩溃一次客户反馈某桌面客户端只要一关闭就有概率弹 R6025。开发同学在本机怎么点关闭都复现不了最后远程到客户机器上用 WinDbg 抓到 dump。调用栈显示崩溃点在mhook.dll的某个函数里触发路径是_purecall。顺着往下看发现调用_purecall的是ss_IocpThreadFunc这类网络 I/O 线程函数。这个mhook.dll其实是某安全软件注入的 DLL它 hook 了进程里的网络发送函数而我们的客户端在退出时已经把网络模块对象销毁安全软件的 hook 回调还在尝试调用一个已经失效的虚函数。解决过程先卸载那款安全软件R6025 立刻消失。结论明确后我们在自己客户端里加了一个防御性判断退出时先短暂等待网络线程完全停止、线程句柄全部关闭再继续走退出销毁流程。同时联系安全软件厂商确认 hook 兼容性。后续版本中故障率明显下降。这里想强调一个经验只要崩溃调用栈里出现第三方 DLL 模块名先把它禁用再做对比测试是性价比最高的排查动作。5.2 案例 B插件 DLL 的生命周期错乱另一个案例来自一个 CAD 类软件。用户加载某个第三方插件后执行另存为操作时有概率弹 R6025。最初开发团队怀疑是文件保存代码里用了纯虚函数但代码审查没有发现问题。后来用 dump 分析发现崩溃点在一个 Excel 导出插件的代码里该插件在文档关闭事件里异步调用了宿主提供的接口而这个接口的纯虚函数在插件 DLL 被卸载后仍在被调用。实际上用户另存为之后紧接着关闭了文档宿主程序按先保存后卸载插件的逻辑执行但插件内部的异步任务队列没有与卸载过程同步。任务队列里的回调触发时插件 DLL 已经被卸载虚函数表指针悬空于是撞 R6025。解决过程在宿主端给每个插件实例增加一个卸载令牌token。插件所有异步任务在执行前检查令牌是否有效无效则直接丢弃任务。同时在卸载接口中增加等所有异步任务完成的同步屏障。这个案例给我们的教训是任何跨模块的异步回调都必须绑定一个统一的生命周期令牌而不能只是简单地判断指针是否为 nullptr。因为指针非空不代表对象可用。5.3 案例 C双显卡切换下的显卡驱动兼容问题最后一个案例比较冷门。某 3D 可视化软件在某些笔记本上启动时报 R6025但台式机完全正常。排查发现出现问题的笔记本都有双显卡Intel 核显 NVIDIA 独显而崩溃点在一个负责渲染上下文初始化的模块里。通过日志和 dump 追踪确认流程是这样的程序启动时调用ChoosePixelFormat和wglCreateContext创建 OpenGL 渲染上下文但系统先用了核显驱动接着切换成独显驱动。在某个时序下显卡驱动 DLL 被动态加载和卸载而渲染模块的虚函数表指针还指向了旧的驱动上下文导致后续调用触发_purecall。解决过程并不是我们代码的直接问题而是旧版 Intel 核显驱动与 NVIDIA 驱动的兼容性 bug。更新核显驱动到最新版本后问题彻底消失。为了保险起见我们还在代码里加了渲染上下文有效性的主动检测一旦发现上下文失效就不再走后续渲染逻辑而是弹提示并优雅降级。这个案例是很好的提醒R6025 不一定都是 C 代码问题某些驱动或系统组件在异常情况下也会触发。排查心态要从我代码写错了变成这个调用链上有哪个环节失效了眼光放宽一点。6. 常见问题速查与预防经验6.1 问题排查速查表现象特征优先排查方向常见解决动作只在程序关闭时弹出 R6025线程未停止、对象提前析构、第三方 hook等待线程完全退出后再释放对象禁用第三方注入测试只在特定电脑上弹出显卡驱动、缺失运行库、系统文件损坏更新显卡驱动安装 VC 运行库运行 sfc /scannow启动时弹 R6025全局对象初始化顺序、插件加载顺序调整初始化依赖推迟插件的启动逻辑调用插件功能时弹 R6025插件 DLL 生命周期管理、异步回调增加卸载令牌确保所有异步任务完成后卸载 DLL运行一段时间后随机弹 R6025内存越界、悬空指针、COM 引用计数用 PageHeap / Application Verifier 做内存检测检查 Release 调用老程序在 Windows 10/11 上弹 R6025运行库版本不兼容、兼容模式缺失安装对应老版本 VC 运行库尝试兼容模式运行6.2 预防 R6025 的五个实操建议把所有虚函数调用都当成有风险的操作。在 C 里虚函数意味着运行时动态分发也就意味着对象状态可能已经变化。每次调用前都问自己一句这个对象的完整生命周期真的在这里有效吗统一线程生命周期管理。建议在类内维护一个std::atomicbool的停止标志线程循环每次检查该标志析构函数中先置位停止标志再join所有线程最后才释放成员对象。顺序严格不要图省事。慎用全局对象。全局对象的构造和析构顺序在大型项目里非常容易失控。从 C14 开始建议用函数级局部静态变量Magic Static替代全局对象例如class Config { public: static Config Instance() { static Config inst; return inst; } };。它可以推迟构造时机也能按首次使用顺序初始化大幅降低初始化顺序逆差。给每个跨 DLL 接口设计版本机制。插件接口、SDK 接口、任何可能跨模块传递 C 对象的接口都应当包含版本号字段并在调用前校验版本。很多时候 R6025 是插件与宿主版本不匹配导致 vtable 错位版本校验能提前拦下不兼容的插件。崩溃后不要急着甩锅。我见过不少团队因为 R6025 互相推诿开发说是运行库问题运行库说是系统问题系统说是驱动问题。实际上非代码原因和代码原因一半一半。正确的做法是第一时间抓 dump、留日志让数据说话。6.3 最后再分享一点排障心态R6025 是我排查过的最容易让人摸不到头脑的错误之一因为它不像 Access Violation 那样直接告诉你非法地址是多少也不像分段错误那样能一眼看到冲突位置。它更像是一个症状病名背后对应的病因五花八门。但只要建立好生命周期管理这个认知框架再配合调试器和 dump 分析绝大多数 R6025 都能在半天内定位出方向。我在实际工作中见过有人为了 R6025 重写了整个插件架构结果最后发现只是缺一个 VC 2008 运行库也见过有人重装了三遍操作系统仍然崩溃最后排查出是一个远程控制软件的老版本 hook 了系统所有进程。所以拿到这个报错先别慌按环境 - 第三方 - 自身代码的顺序一层层剥你总能找到那根真正的刺。