2025年的13,14代CPU降压教程 z790主板+0x12B微码高稳定性降压 防止缩缸 减少性能损失 稳定运行生产力

本教程适用于13,14代CPU + z790主板 以我的华硕z790a和14700kf为例

(12代也可以用本教程降压,但是其实没太大必要)

 12900kf降压 12900ks降压 13900kf降压 14700kf降压 14900kf降压 14900ks降压

13代CPU降压 14代CPU降压 12代CPU降压 z790主板降压 z690主板降压 b760主板降压 b660主板降压

前言:

本文章提供一种稳定有效的CPU降压设置方法, 适用于13代, 14代中高端CPU, 可以有效减少缩缸风险, 提高稳定性, 同时性能损失极少

随着24年微软接连推送0x129和0x12B微码来提升14代CPU的电压安全性,现在基本上主板都可以直接使用默认bios选项+开启xmp直接使用而无需担心安全问题了。

(2025年6月14日更新:最近又更新了0x12F微码)

但是随之而来的问题就是性能损失比较多,并且各种场景下下功耗稍高,本文将介绍在0x129/0x12B/0x12F微码下对14代CPU实现降压操作,目的是为生产力/长时间使用场景的大稳定性的前提下,降低电压和功耗,并且尽可能地保留原有的性能。

本次降压教程是第三期,本期教程设置中摸稳定电压所消耗的时间是全三期教程中最少的,并且稳定性最高,无需学习前两期教程,直接按照后文的方法设置即可!

 (附前两期教程链接,若对降压或bios内操作有问题可以参考这两期)
CPU降压分享 14700KF降压 华硕吹雪Z790A主板 0x104微码
CPU降压分享第二弹 14700KF降压 我的14700kf玩大型3A可以1.208v电压!

降压效果展示:

降压前默认R23测试: 全核睿频满载功耗300w左右 R23 10分钟跑分35500分 满载核心电压约1.2v

降压后: 满载功耗250w R23 10分钟跑分34735分 满载核心电压约1.16v( 大核睿频由5500降低到5300-5400波动 小核睿频4300)

降压的参数如下: 14700kf + 12F微码 + IA VR Voltage=1400mV

(测试环境 室温20° cpu温度最高82°)

虽然睿频看着降低的多 但是实际分数接近3w5已经是一个很好的结果了(正常不降压未缩缸的14700kf使用早期微码跑分35500-36000)

(以前的对比数据请翻前两期的链接查看)

(附我的机箱散热环境: pa401机箱 短风道 前置两把16cm进风风扇14700kf 散热器库里奥p60t)

降压详细操作教程:

注:操作bios之前请确保事先升级到了最新版本0x12B或0x12F微码的bios(0x12B性能略好, 0x12F安全性更好, 在华硕官网发布的bios中看更新日志, 选择对应微码版本的bios进行更新即可, 两个版本微码的性能有略微差别, 在文章最后有介绍)

步骤①重置bios为默认状态 然后根据自己的习惯切换语言即可

步骤②切换CPU的性能配置文件从intel baseline/intel default setting切换为 ASUS OC

-->performance preferences 选择 ASUS Advanced OC profile

步骤③打开内存XMP

步骤④(可选)设置多核心增强功能为开启--90°温度墙

这个选项开启后主板会限制cpu package的温度墙为90°, 除了避免电压过高之外, 还可以防止温度过高损坏CPU和主板

因为我的电脑用的风冷 所以每次喜欢这么设置,不过降压后总功耗最大也之后255w 室温20° 散热器p60t风冷压制 CPU温度最高也只有82°

 步骤⑤ 修改电压补偿曲线为L4

Ai Tweaker --> DIGI+ VRM --> CPU Load-line Calibration修改到Level4

步骤⑥ 检查mirco code选项是否选择了当前微码 + 后续开机后用软件确认微码

(设置完后续的步骤后再)开机使用hwinfo软件再次确认,我使用的是12B微码版本的bios,所以软件的MCU一栏显示12B微码

步骤⑦ 检查功耗墙设置 全部为AUTO即可(恢复bios为默认后一般都是AUTO,如想检查的话,具体操作可以查看看前两期教程)
步骤⑧关闭IA sep, SA cep

步骤⑨设置IA VR Voltage

IA sep, SA cep往下翻一点点就是这个设置

或者bios主界面中使用搜索工具 搜索:IA VR Voltage

并根据下面的推荐范围设置一个电压值, 推荐先设置个中间的值, 然后执行步骤⑩ 开机测试

(该设置的单位是mV, 我的14700kf设置的是1400mV)

不同CPU电压设置推荐范围:

  • 14700kf/13900kf设置范围:1380-1420
  • 13900ks,14900kf设置范围:1420-1450
  • 14900ks设置范围:1440-1480

具体值可以从最低值开始每次向上+5或10mv 然后跑R23多核测试 稳定过测且跑分降低不多的话即可使用,但电压最好不要超出推荐的范围

如何后续调整电压:

开机后跑分R23 10分钟,先看是否会出现蓝屏,再看你的跑分对比正常跑分是否正常

  • 跑分过低则需要提升电压, 但是电压值不要超过推荐的范围!
  • 蓝屏需要降低电压

        --->如果你的CPU已经确认有过缩缸或体质很差, 则蓝屏优先考虑降低电压求稳定

        --->电压低于推荐值太多也可能是因为电压太低的导致蓝屏,

        --->如果CPU未缩缸, 蓝屏的话也可以酌情加高一点点电压(常见于电压墙设定值太低, 导致游戏时蓝屏闪退)

13,14代其他CPU和12代CPU设置为1400及以下的值即可,一般不会有稳定性问题

12700kf 13600kf具体值可以从1380开始,不断向下减 一次5或10mv 直到不稳定或跑分大幅度下降停止(同时本文的操作类似, 记录正常不降压的跑分和降压后跑分对比, 选择一个电压较低, 能效比最好的电压使用即可)

13400 12400及以下就不用凑热闹啦 不会缩缸滴

步骤⑩开机验证稳定性和跑分, 然后重新调整电压

设置好一个电压值之后, 开机, 查看微码是否正确

然后跑R23 10分钟压力测试

跑分结束后 参考跑分再重新设定新的IA VR Voltage值, 开机再跑分 找到自己最合适的电压即可

用于参考的各电压对应跑分结果如下: 

我的跑分结果以及对12B和12F两个微码的补充如下:

2025年6月14日:

最近从12B微码更新到12F微码了, 实测在更新之后 使用同样的电压设置 我的14700kf跑分从3w5降到3w4 同样 是1380mV的电压, 但是损失了一点点性能, 是否要更新到最新微码大家看个人喜好啦 不过实测大部分网游游戏中单/双核最高睿频没变 但是多核高负载情况下的频率现在只能大核稳定了5200mhz了

2025年7月13日:

最近抽空做了下12F微码整体的测试, 结论是从12B微码更新到12F微码之后损失了一点点多核性能, 单核/双核的游戏性能基本不受影响

更新为12F微码后的性能损失可以通过电压墙放宽20mV以恢复损失的大部分性能(1380mV --> 1400mV) 并且12F微码更加安全一些

以下是我测试了一下部分电压设置下R23的跑分 各位可以参考(最新bios 12F微码下的结果):

1350mv R23跑分3w3(截图忘了截 性能的性价比不高 但是非常安全 1.35v一下的核心电压安全到不得了)

1380mv: R23跑分3w4 (烤鸡中核心最高电压1.146v-1.154v 其中1.146v电压是我在Intel为推出安全补丁之前的bios版本冒着缩缸的风险测到的我的CPU保持全核最高睿频的极限电压, 低于这个电压就会降频, 用比这个低一点的核心1.137v电压 强行设置全核最高睿频跑r23就会蓝屏 --> 对于我的U来说, 1380是最具性价比的电压设置)

 

1400mv:R23跑分3.47w(相比1380档的设置, 这个跑分很接近在12B微码版本下1380mV电压的跑分了(34900分) 目前我用的就是1400这个电压)

1420mv: 跑分提升不大 3w5分, 但是满载核心电压最高来到了1.199v 功耗也高 实在是性价比低

最后的最后, 如果Intel持续更新微码的话 大概率是可以直接更新bios然后照搬设置的, 大不了就是再测试一下下新的最有性价比的电压即可, 我有空了也会自己测试一下然后继续更新进来.

不过推荐的电压值范围大概率是不会变的, 所以大家还是要在安全范围内设置电压哦

<think>嗯,用户的问题是关于如何通过分析DMP文件中的堆栈信息来定位程序崩溃的原因,特别是涉及KERNELBASE、VCRUNTIME140和Qt5Core这些模块。首先,我需要回忆一下处理Windows崩溃转储文件的一般步骤,并结合用户提供的引用内容来给出准确的建议。 首先,用户提到他们想分析DMP文件中的堆栈信息,但之前尝试使用~*k命令没有找到正确的堆栈,可能崩溃发生在其他线程。根据引用[1]中的建议,可能需要切换到其他线程查看堆栈,比如使用~2s切换到二号线程,然后使用k命令查看该线程的堆栈。这一点很重要,因为有时候崩溃并不在主线程,而是在工作线程中,所以检查所有线程的堆栈是必要的。 接下来,用户需要加载DMP文件,这里可以用windbg,如引用[2]提到的命令:windbg -z "c:\mydumpfile.dmp"。加载之后,首先应该使用!analyze -v命令进行自动分析,这会提供初步的崩溃原因,比如异常码和可能引发问题的模块。例如,如果分析结果显示访问冲突(ACCESS_VIOLATION),通常意味着有无效的内存访问,比如空指针或已释放的内存。 然后,查看具体的堆栈信息。用户提到的模块包括KERNELBASE.dll、VCRUNTIME140.dll和Qt5Core.dll。KERNELBASE.dll通常是Windows系统模块,当它出现在堆栈中时,可能意味着系统级别的异常处理被触发,而实际的问题可能出在应用程序码中。VCRUNTIME140.dll与Visual C++运行时有关,可能涉及到运行时错误,比如内存分配失败或异常处理问题。引用[5]提到的问题就是错误地delete了非new分配的对象,这会导致运行时错误,可能触发VCRUNTIME140中的异常处理。 Qt5Core.dll的问题可能涉及Qt框架的内部机制,比如信号槽连接错误、跨线程访问对象等。需要检查堆栈中Qt相关函数的调用链,比如是否在非主线程操作GUI元素,或者使用了无效的QObject指针。 用户需要结合堆栈中的函数调用顺序,确定崩溃发生的具体位置。例如,如果堆栈显示崩溃发生在某个Qt函数内部,那么可能需要检查应用程序中对应的Qt码部分,是否有不正确的使用方式。同时,查看异常发生时的寄存器值和内存状态,使用命令如r查看寄存器,dd/po查看内存地址,可以帮助确认是否有空指针或越界访问。 另外,用户之前可能遇到了析构函数中错误释放栈对象的问题,如引用[5]所述,这种情况会导致VCRUNTIME140的异常。因此,在分析时需要检查码中是否有类似的错误,比如在ClassManager的析构函数中是否正确处理了对象的所有权,是否误用了delete。 总结一下,步骤应该是:1. 使用windbg加载DMP并自动分析;2. 检查所有线程的堆栈,找到崩溃点;3. 结合模块信息定位可能的码问题;4. 检查内存和寄存器状态,确认具体错误原因;5. 根据分析结果修改码,比如修复内存管理错误或线程安全问题。 此外,用户可能需要生成相关的符号文件(PDB)以确保堆栈信息可读,特别是对于Qt5Core.dll这样的第三方库,需要确保符号路径正确设置。如果堆栈信息显示在Qt内部函数崩溃,可能需要查看Qt的文档或社区,确认是否有已知的问题或正确的使用方式。 最后,用户可能需要复现崩溃并附加调试器进行实时调试,或者添加日志来跟踪变量状态,帮助进一步确认问题根源。</think>### 通过DMP文件分析崩溃原因的步骤 #### **1. 加载DMP文件并初步分析** 使用Windbg加载DMP文件(命令:`windbg -z "c:\mydumpfile.dmp"`[^2]),输入以下命令自动分析: ```bash !analyze -v // 自动分析崩溃原因,显示异常类型、触发模块及堆栈摘要 ``` - **重点关注**: - **异常码**(如`ACCESS_VIOLATION`表示内存访问错误) - **崩溃模块**(如`KERNELBASE.dll`、`VCRUNTIME140.dll`、`Qt5Core.dll`) - **堆栈顶部函数**(如`RaiseException`或`Qt`内部函数) --- #### **2. 定位具体崩溃堆栈** - 若自动分析未明确主线程崩溃,需检查所有线程堆栈: ```bash ~*k // 显示所有线程堆栈 ~2s // 切换到2号线程(示例) k // 查看当前线程堆栈 ``` - **关键堆栈示例**: ``` KERNELBASE!RaiseException+0x69 VCRUNTIME140!_CxxThrowException+0x66 Qt5Core!QMetaObject::activate+0x1a3 ``` 表示异常通过`VCRUNTIME140`抛出,可能与Qt信号槽或对象生命周期相关[^1][^5]。 --- #### **3. 分析模块关联性** - **KERNELBASE.dll**:通常为系统异常分发点,实际崩溃原因需结合调用链分析。 - **VCRUNTIME140.dll**:C++运行时异常(如内存泄漏、类型错误)。检查是否: - 错误释放栈对象(如`delete`非`new`分配的内存) - 未捕获的`std::exception` - **Qt5Core.dll**:常见于Qt对象跨线程操作、信号槽连接失效或野指针访问。 --- #### **4. 检查内存状态** 通过寄存器和内存命令验证崩溃点: ```bash r // 查看寄存器值(如`eax`可能存储空指针) dd <address> // 查看内存数据(如崩溃地址是否为空) !heap -p -a <address> // 验证堆内存状态(是否已释放) ``` --- #### **5. 码修复建议** - **VCRUNTIME140相关崩溃**: - 检查`new`/`delete`配对,避免重复释放或无效指针。 - 使用`std::shared_ptr`或`std::unique_ptr`管理对象生命周期。 - **Qt5Core相关崩溃**: - 确保跨线程操作使用`QObject::moveToThread`。 - 验证信号槽连接有效性(如接收者是否存活)。 ---
评论 33
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

P1nkB1ood

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值