1. 这个报错的真面目：不只是弹个窗那么简单
先说说我最近处理的一台机器。同事的电脑跑着一套老旧的工业控制软件，某天操作到一半，屏幕突然弹出一个英文对话框，标题栏写着“Microsoft Visual C++ Runtime Library”，正文是“Runtime Error! Program: ... R6025 - pure virtual function call”。点确定之后，程序直接闪退，再打开还是同样的问题，连带着整个系统都像是被什么东西拽了一把，偶尔还会卡顿一会儿。
说实话，这个报错在Windows平台上有年头了。从XP时代到现在Win11，时不时就有人碰到。很多人第一反应是重装系统，但重装完再装同样的软件，问题照样回来。也有一些朋友把锅甩给“电脑中毒”或者“硬件老化”，其实都不准确。要真正解决它，得先搞清楚这个错误到底是什么、在什么情况下会被触发。
R6025是微软C/C++运行时库定义的一个错误代码，英文全称是pure virtual function call，翻译过来就是“纯虚函数调用”。从名字就能看出，这个报错和C++的面向对象机制强相关。它不是病毒，不是硬盘坏了，也不是系统文件损坏那么简单，而是一个程序在运行时发生逻辑混乱的信号。
换句话说，你看到这个弹窗，其实是软件本身在执行过程中踩进了一个不该踩进去的“坑”。系统只是被程序拉着一起遭殃，真正的问题藏在那个崩溃的程序里。
那到底是什么样的“坑”才会导致纯虚函数被调用？这里就得往C++的底层原理走一走了。别急，我会用比较直白的方式来讲，保证不是搞C++开发的朋友也能听懂个七八分。
2. 源码层面的根因：析构阶段调用虚函数的雷区
2.1 什么是“纯虚函数”，它为什么不能碰
先做个类比。一个C++类里如果定义了纯虚函数，就相当于在蓝图上留了一个“接口槽位”，等着子类来填上具体实现。正常的程序运行时，子类对象创建后，调用虚函数会通过一张叫“虚函数表”的表做跳转，拿到真正子类实现的那个函数地址，然后执行它。
一切正常的情况下，纯虚函数本身是不该被调用的，因为它没有真正的实现体。如果代码强行走到了这一步，那么程序只能抛出一个运行时错误——也就是我们看到的R6025。这时候程序自己也不知道该执行什么，干脆直接崩溃。
2.2 最容易踩中的雷：析构函数里直接或间接调用虚函数
那什么情况下会强行走到“调用纯虚函数”的路径上？最常见、也是最经典的一种场景，是在构造函数或析构函数中调用了虚函数。
听起来很反直觉对吧？我建一个子类对象，然后在基类的析构函数里调用一个虚函数，想让它做一个“清理工作”，结果程序却崩了。原因在于：
- 对象构造时，先从基类开始构造。但此时子类部分还没有构造完成，虚函数表还指向基类的版本，所以就算你调用虚函数，也无法跳到子类的实现。
- 对象析构时，顺序反过来，先析构子类部分，再析构基类部分。当基类析构函数执行时，子类部分已经被销毁了，虚函数表重新指向基类版本。如果这个虚函数是纯虚函数，等于直接踩雷。
也就是说，设计上应该保证：构造函数和析构函数中不要调用虚函数。但在真实项目中，尤其是老代码和第三方库的代码里，写这种“危险操作”的人不在少数。
2.3 其他触发纯虚函数调用的隐蔽场景
除了析构函数这个最经典的雷区，还有一些不那么容易一眼看出来的场景，同样能触发R6025：
- 在析构函数中调用了另一个成员函数，而那个成员函数内部又调用了虚函数。这种间接路径最难排查，因为表面上看你不觉得是在纯虚函数上踩雷。
- 对象本身已经被删除，但代码仍然持有这个对象的引用或指针，并且继续调用虚函数。这在多线程程序里特别常见，一个线程负责清理对象，另一个线程还在用这个对象。
- 某个动态库（DLL）被卸载之后，留下了一个悬空的对象指针，之后代码又通过这个指针去调用成员函数。
- 编译器优化与代码生成在某些未定义行为（UB）情况下，导致虚函数表被错误地覆盖。
这里需要注意的是，R6025对于普通用户来说可能只是“程序崩了”，但对于软件开发者来说，它是一个非常明确的信号，说明代码里存在“对象生命周期管理”或“虚函数调用时机”的问题。
3. 实战排查链路：从弹窗到定位问题源头
遇到这个报错，不建议直接格式化重装，也不建议立刻去下载各种“修复工具”。我的习惯是花十几分钟做一次定向排查，往往比盲目折腾省时间。下面是我自己常用的排查链路，按顺序走。
3.1 第一步：判断是“单程序崩溃”还是“系统级崩溃”
先观察报错弹窗里那行“Program: 路径”，它通常会告诉你到底是哪个程序触发了这个错误。
比如我处理过的一台机器，弹窗里写的是Program: C:\Windows\System32\rundll32.exe，那就不是某个业务软件的问题，而是某个加载到rundll32里的DLL出了问题。如果是Program: C:\Program Files\XXX\xxx.exe，那问题大概率出在这个软件自身。
这一步决定了后续排查方向：是围绕着特定软件排查，还是围绕系统公共组件排查。
3.2 第二步：看Windows事件查看器里的线索
很多人点掉弹窗就完事了，其实事件查看器里藏着不少可用信息。展开“Windows日志 → 应用程序”，找红色错误级别的事件，来源一般是“Application Error”或“Windows Error Reporting”。双击进去，能看到崩溃程序的模块名称和异常代码。
R6025对应的异常代码在事件里不一定直接写R6025，更多时候会看到0xC0000005（访问违规）或类似的崩溃记录。重点看两项：
- 错误模块名称：比如是一些第三方DLL、显卡驱动DLL，还是软件自己的主程序模块。
- 触发时间：和软件安装、系统更新的时间对比，往往能看出关联。
3.3 第三步：回忆时间线，找“最近发生的改变”
软件崩溃很少有完全随机的时候。我一般会问自己三个问题：
- 最近有没有装过新软件、新驱动、新插件？
- 最近有没有更新过Windows补丁？
- 程序是在特定操作后才崩溃，还是启动就崩溃？
这三类时间线索，配合事件查看器的记录，能很快把搜索范围缩小。
3.4 第四步：用调试工具抓崩溃现场（开发者向）
如果说前三步是普通用户也能做的，那这一步更适合软件开发者和技术型玩家。如果你是软件的使用者，看到这步可以先跳过，后面的解决方案里有更快的路子；如果你是开发者，想真正找到崩溃根源，得会用下面这套方法。
目标是抓取崩溃时的调用堆栈（Call Stack），看看到底是哪个函数、哪个模块在调用纯虚函数。
我常用两种方式：
方式A：在Visual Studio中启用“本机调试”
- 用VS打开崩溃程序对应的工程源码，在“调试 → 选项 → 调试 → 符号”里勾选“Microsoft符号服务器”。
- 然后在“调试 → 窗口 → 异常设置”中，把“C++ Exceptions”的“抛出时”勾上。
- 接着按F5直接运行，程序崩溃时VS通常能抓到调用栈。
方式B：使用WinDbg分析崩溃转储文件
如果拿不到源码，只有程序崩溃生成的DMP文件，那就用WinDbg这种方式：
- 在事件查看器的事件详情里，找到“应用程序崩溃”事件对应的DMP文件路径，通常在
C:\Windows\Minidump或C:\ProgramData\Microsoft\Windows\WER\ReportArchive目录下。 - 用WinDbg打开DMP文件，执行
!analyze -v命令，它会自动分析崩溃原因和调用栈。 - 重点查看栈回溯中是否有
pure virtual function call字样，以及是哪个模块发起的调用。
老实说，抓到调用栈之后，故障源就无所遁形了。多数情况下你会看到某个DLL或者某个类的析构函数在捣鬼。有一次我在分析一个插件崩溃时，最后定位到的就是插件DLL卸载时没有正确清理对象数组，导致虚函数表指针悬空。
4. 症状与对应解法：六类常见场景的实战修复方案
下面这部分是对我这些年处理过的R6025案例做的一个归纳。每一类场景都从“为什么触发”到“怎么解决”做了完整梳理，大家可以根据自己的情况对号入座。
4.1 场景一：老软件、老游戏在新系统上运行时报R6025
这个场景几乎可以说是R6025的“高发区”。很多老软件是用VC6、VC2005、VC2008时代的编译器编写的，发布时用的是当时的动态运行库。到了Win10、Win11上，系统的运行库版本变了，或者缺失，程序在初始化、析构时就会出现兼容性错乱。
解决方案：
- 安装完整的“Visual C++ 运行库合集”，从2005到2022的x86和x64版本都装一遍。很多老软件虽然主程序是x86的，但同一环境里可能还有x64组件，缺一不可。
- 如果装了运行库还不行，可以右键程序exe文件，进入“属性 → 兼容性”，尝试通过以Windows 7或Windows XP SP3兼容模式运行来规避。
- 老游戏类程序，尽量把安装目录放到非系统盘的纯英文路径下，避免Unicode路径问题导致DLL加载异常。
4.2 场景二：多个杀毒软件共存或安全软件“插管”
这种情况在重灾区排第二名。杀毒软件、系统优化工具为了监控程序行为，会对目标程序注入DLL。多个安全软件同时注入时，容易在DLL加载、卸载过程中破坏对象的生命周期，导致虚函数调用指向已释放的内存。
我自己就遇到过一台机器，装了两个杀毒软件，打开某个财务软件时必现R6025。逐个卸载之后才恢复正常。
解决方案：
- 保留一个杀毒软件即可，卸载其他安全工具，并在卸载后使用官方提供的专用清理工具清除残留驱动。
- 如果是公司强制安装的安全管控软件导致业务系统崩溃，需要联系IT管理员把业务程序加入白名单，或者调整注入策略，这个不建议用户自己乱改。
4.3 场景三：DLL版本冲突或者动态库被“顶掉”
Windows系统里有个常见问题：多个软件共用同一个DLL文件，但不同软件需要的版本不一样。后来安装的软件可能覆盖了公共DLL，先装的那个软件再去调用时，就会因为函数签名不匹配、对象布局不一致而崩溃。
解决方案：
- 打开程序所在目录，看看它有没有自带的DLL文件夹（很多软件会把依赖的运行库放在自己的目录里），确认程序用的是本地DLL而不是系统DLL。
- 使用“DLL修复工具”时要谨慎，很多此类工具本身就会引发更严重的问题。手动操作的话，可以下载对应的官方运行库安装包进行覆盖安装，而不是去网上下载来源不明的DLL文件丢进System32。
4.4 场景四：显卡驱动、声卡驱动等硬件驱动引发的回调问题
这个场景比较隐蔽，但确实多发。有些软件会注册硬件回调函数，当硬件状态变化时驱动程序主动通知软件。如果驱动的版本和软件预期不匹配，回调函数可能指向一个正在析构的对象，从而触发R6025。
特征表现是：报错不是每次都能复现，有时运行一段时间才出现，且崩溃模块指向某个驱动相关的DLL。
解决方案：
- 去硬件厂商官网下载并安装最新版驱动，不要在第三方驱动软件上一键更新。
- 如果更新驱动后问题出现在特定软件上，也可以反向操作，回退到过去的稳定版驱动试试。
- 重点检查显卡驱动、声卡驱动和外设驱动（游戏手柄、采集卡等）。
4.5 场景五：输入法、第三方软件Hook注入
输入法、截图工具、录屏软件这类工具，为了全局生效，往往会对各个进程注入DLL。某些不规范的注入实现会干扰目标程序的虚函数表，导致R6025。
我排查过一次：一个用户浏览器总是随机崩溃，报R6025。事件查看器里错误模块指向输入法相关DLL，卸载换用系统自带输入法之后，马上消停。
解决方案：
- 切换成系统自带的微软输入法测试一段时间，看问题是否复现。
- 退出所有截图、录屏、弹窗拦截类工具再做测试。
- 逐个排查后找到“肇事者”，就可以考虑找替代工具了。
4.6 场景六：系统更新补丁（Windows Update）破坏运行库文件
Windows更新之后突然开始报R6025，这种情况也蛮常见的。系统更新可能会替换掉C++运行库的某些文件，或者新增的更新包和旧版运行库存在兼容问题。
解决方案：
- 先去控制面板的“程序和功能”里，找到所有Microsoft Visual C++ Redistributable相关项。
- 将每个运行库依次点“卸载”，然后用官方工具或安装包重新安装一遍。
- 如果重装运行库还是不行，看一下最近的更新历史，尝试卸载最近安装的更新补丁。
5. 针对普通用户和开发者：两套不同的处理策略
5.1 普通用户：以恢复运行为目标，不深挖源码
如果你不是开发者，只是正常使用某个软件时遇到了R6025，建议按照下面这个顺序处理，成本从低到高，不用一开始就上手那些高难度的操作：
- 重启软件测试：如果是偶发的，重启后能正常使用，就继续用，只是留意触发条件。
- 重装该软件：卸载干净（包含配置文件和注册表残留，推荐用工具监视卸载过程）后重新安装最新版。
- 安装或修复VC++运行库：这一步对R6025尤其重要，大部分情况都能cover住。
- 排查最近安装的软件：如果能关联到最近装了什么，先卸载掉看看。
- 系统还原：Windows自带系统还原点，如果知道问题从哪天开始，还原到之前的状态会很快。
- 重装系统：最后的选择，但我必须说一句大实话——如果前五步都试过了还是不行，重装系统其实也未必管用，因为根源在第三方软件。所以我更建议在重装系统后，别急着把原来那些软件一股脑装回去，而是逐个安装、逐个测试。
5.2 开发者：修复代码里的对象生命周期问题
如果你是这个崩溃程序的开发者，或者你有能力拿到源码和崩溃现场，那目标就更明确了——必须修复代码里的隐患，不能靠用户重装系统来“碰运气”。
我根据实践经验，总结出三个必须检查的代码模式：
模式一：析构函数中调用虚函数
这类代码属于硬伤，必须重构。如果析构时确实需要根据子类型做差异化清理，正确的做法是：让每个子类在自己的析构函数里完成清理工作，基类析构函数只做通用的、不依赖子类状态的事情。
class Base { public: virtual ~Base() { // 危险：不要在这里调用 anyVirtualFunction(); // CleanupCommon(); // 可以调用非虚函数 } }; class Derived : public Base { public: ~Derived() override { // 在这里做 Derived 特有的清理工作 } };模式二：异步回调中使用了已析构对象的裸指针
这个模式在多线程程序中非常猖獗。某个工作线程执行完后，把结果回调给UI线程，但UI线程上的接收对象可能已经被销毁了。如果回调函数内部又调用了一个虚函数，那R6025就是大概率事件。
正确做法是使用智能指针或弱引用，在回调入口处检查有效性。比如使用std::weak_ptr配合lock()来判断目标对象是否还活着。不要把一个裸指针跨线程传来传去。
class Worker { public: void DoWork(std::weak_ptr<UIReceiver> receiver) { std::thread([receiver]() { auto recv = receiver.lock(); if (recv) { recv->OnWorkComplete(); } else { // 对象已销毁，直接丢弃回调 } }).detach(); } };模式三：DLL边界上的对象传递
如果你的程序使用插件机制，DLL之间相互传递对象指针时要格外小心。不同模块可能使用不同的堆分配器、不同的CRT版本，在一个模块里new出的对象，被另一个模块delete时，析构逻辑就可能跑飞到错误的地方。如果在析构链路上再触发虚函数调用，R6025便会直接现身。
比较稳妥的做法是定义明确的COM风格接口，或者让跨DLL的对象生命周期完全由创建方管理，通过导出函数来做创建和释放。插件对外暴露统一的接口，不直接暴露C++类对象。
6. 实测记录：一次完整的R6025修复过程复盘
前面讲了原理、排查和方案，可能有些抽象。我挑一个真实的处理案例，把从看到报错到最终解决的完整过程写出来，这是我在实际工作中处理过的一个典型情况，希望对你有参考价值。
6.1 现场情况
用户使用的是一套基于C++编写的内部业务系统客户端，操作系统是Windows 10 22H2。用户反馈：软件启动登录之后，只要进行“报表导出”操作，就会弹出R6025报错，随后软件关闭。未执行该操作时，软件其他功能一切正常。
6.2 排查过程
这个现象有很强的规律性，不是随机崩溃，而是固定操作必现。这给我省了很多事，不用瞎猜。
第一步，查看了事件查看器，确认崩溃记录的时间点，看到错误模块是业务系统主exe名称，而不是某个第三方DLL。这说明崩溃主因大概率在软件自身。
第二步，考虑到是固定操作触发，我推测是“报表导出”这个功能模块在退出时，某个对象的析构函数里调用了虚函数。因为用户每次导出报表都会创建一个新的报表对象，导出完成后销毁该对象，正好落入析构阶段。
第三步，我让开发团队在本地复现问题，把报表模块的析构链路上所有虚函数调用逐一排查，最终锁定了一段代码：一个报表基类的析构函数里调用了UpdateStatus()，而这个UpdateStatus()在基类中定义为了纯虚函数。
6.3 问题本质
代码如下面这样：
class ReportBase { public: virtual ~ReportBase() { UpdateStatus(Closing); // 问题就是这一行 } virtual void UpdateStatus(Status s) = 0; // 纯虚函数 };当程序执行delete reportObj时，基类析构函数开始执行。此时如果对象的实际类型是ExcelReport，那么在这一刻，ExcelReport部分已经被析构完毕，虚函数表指针回退到ReportBase。但ReportBase中UpdateStatus是纯虚函数，没有实现，所以运行库检测到“调用纯虚函数”这一非法操作，直接抛出了R6025。
6.4 最终修复
修复方式很简单，把基类析构函数中的UpdateStatus调用改为只调用一个非虚的保护成员函数来实现公共清理逻辑，同时将子类特有的状态更新放在子类自己的析构函数中。
class ReportBase { public: virtual ~ReportBase() { Cleanup(); // 非虚函数，基类可控 } void Cleanup() { // 只有基类自己知道如何处理的部分 m_status = Closing; } virtual void UpdateStatus(Status s) = 0; }; class ExcelReport : public ReportBase { public: ~ExcelReport() override { // 子类特有清理 UpdateStatus(Closing); } };6.5 修复后验证
修改后，开发团队在本机编译并进行了多轮“报表导出”操作测试，确认问题不再出现。然后在用户机器上替换客户端程序，同样验证通过。
修复完这次之后，我最大的感受是：R6025这类报错，很多时候并不是什么东西坏了，而是软件代码本身对对象生命周期的管理不够严谨。作为用户，能靠重装运行库、调整兼容模式来“绕过去”；作为开发方，还是得从源码层面解决。
7. 处理这个报错时最容易犯的三个错误
7.1 一见到R6025就格式化重装
重装系统对R6025来说往往是很痛但无效的操作。原因很直接：系统装好之后，你还要装回业务软件、驱动、输入法、办公软件，只要那个触发崩溃的程序还在，问题照样出现。我见过很多用户因为反复重装，数据丢失了，问题也没解决，最后才发现只是因为某个补丁版VC++运行库没装。
7.2 用来历不明的“系统DLL修复器”一键修复
这类工具十有八九是从网上爬来的各种版本的DLL文件，打包在一起给你“自动替换”。而R6025的根源多数不是“DLL真的缺失”，而是DLL的版本和调用方不匹配。盲替换会造成更大的系统稳定性问题，甚至导致多个程序同时崩溃。建议要么自己从微软官方渠道装运行库，要么就不要动系统DLL。
7.3 直接禁用Windows错误报告或报警服务来“让弹窗消失”
这属于掩耳盗铃。弹窗虽然不出现了，但程序还是照样崩溃，只是你不知道而已。与其让问题隐藏在后台，不如保留默认的错误报告设置，至少能让你知道是哪个模块崩了。
8. 线下的最后几个建议
处理R6025这件事，我没有放之四海皆准的“一键修复脚本”，因为每次崩溃背后的原因都可能不同。但如果你愿意花点时间做好以下三件事，很多问题是可以直接在初期就规避掉的。
第一，养成看事件查看器的习惯。不论是什么软件崩溃，事件查看器里基本都有记录，花五分钟看一眼日志，比在论坛刷半天帖子“求解决办法”实在得多。我知道很多普通用户可能不习惯操作这种工具，但打开控制面板、进入事件查看器、把错误事件的截图发给懂行的人，这已经能帮对方省很多事。
第二，保持系统里VC++运行库完整。很多人不知道，Windows本身不会主动帮你装上所有版本的VC++运行库，而很多软件却对这些运行库有依赖。我的做法是每年重装一次“VC++运行库全家桶”，把可能缺的x86和x64版本都补齐，很多莫名其妙的软件崩溃都能在这个环节被拦住。
第三，如果长时间找不到原因，别死磕。排除法是个体力活，但方向对。把崩溃程序之外的所有非必要启动项临时禁用，再逐个放行，最终一定能锁定那个“罪魁祸首”是谁。多数情况下，最后找到的都是一些不起眼的小工具。
这个报错本身并不神秘，它就是C++程序对象生命周期管理出问题后，运行库在兜底时抛出的最后一道警示。理解它背后的逻辑，按步骤排查，就算修到最深处也不会是无头苍蝇。希望这篇文章能帮到正在被R6025困扰的你，无论是作为用户还是作为开发者，都能少走点弯路。
