Raider GE68HX 13VF - BIOS .113 but MCU is stuck at 0x2C. Need 0x12B microcode update

[apmraide15b602e4]

Hi everyone,

I own an MSI Raider GE68HX 13VF (Intel Core i7-13700HX) which came from the factory with BIOS version E15M2IMS.113 (Date: 2025/10/16).

The issue is that despite being on this relatively recent BIOS, HWiNFO64 reports that my Microcode (MCU) is stuck at 0x2C. This is very concerning as it lacks the critical Intel 0x12B update for voltage stability and CPU protection.

I’ve already contacted local MSI support, but they were unable to provide technical guidance or explain why the MCU hasn't been updated.

System Specs & Status:

• Model: Raider GE68HX 13VF (International/US Layout)
• Current BIOS: E15M2IMS.113 (Pre-installed)
• Current MCU: 0x2C
• Intel ME FW: Updated to the latest available tool.
• Problem: Experiencing crashes in Unreal Engine 5 games (shader compilation errors) which are classic symptoms of the Intel 13th Gen instability issue.

Is there a newer Beta BIOS (like .114 or higher) available for this model that correctly injects the 0x12B microcode? I want to ensure my CPU doesn't suffer permanent degradation.

Thank you for your help!

 

[electrostingz]

It's probably due to Intel stating the impacted processors are desktop only.

https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239

In terms of the flaw, when a CPU is damaged by elevated voltages there is no fix so if you are saying your crashes are due to a degraded CPU an update will not fix anything.
But also most of the CPU's being damaged were the ones capable of exceeding 1.55V, which is mainly at 5.6GHz+.

Another issue not related to the above and specific to the Unreal engine was the Game engine causing the CPU boost to push quite high clocks / temperatures which meant some systems were crashing. This is not part of the Intel specific Vmin Shift defect but more of the game causing the CPU to work extremely hard and some poorly cooled ones / systems with poor BIOS settings would crash. https://www.techspot.com/news/101978-newer-high-end-intel-cpus-crashing-unreal-engine.html

Given the above is it more reasonable to assume your crashes are not Vmin related?

 

[apmraide15b602e4]

I understand that the Vmin Shift issue was primarily linked to desktop CPUs. However, MSI has released BIOS updates with the 0x12B microcode for many mobile HX models exactly like mine. If the issue didn't affect laptops, MSI wouldn't be releasing these patches. Regardless of whether my current crashes are UE5-specific or Vmin-related, running on MCU 0x2C is objectively outdated and unsafe according to Intel's latest recommendations. I just want the protection that the 0x12B update provides to avoid any potential future degradation

 

[apmraide15b602e4]

I appreciate your perspective, but I have to respectfully disagree with the notion that this isn't a cause for concern.

While Intel initially focused on desktop stability, it is well-documented that the 13th Gen HX series (like my i7-13700HX) shares the same silicon architecture as their desktop counterparts. This is precisely why MSI and other manufacturers have been rolling out BIOS updates with the 0x129 and 0x12B microcodes for their high-end laptop lineups. If there were no risk for mobile HX chips, MSI wouldn't be bothering with these patches at all.

The fact that my system remains on MCU 0x2C (March 2023) despite being on the latest available BIOS (.113) suggests a technical oversight in this specific firmware build. Running a high-performance Raptor Lake chip on a 2-year-old microcode—one that lacks all the critical voltage limiters released by Intel—is objectively unsafe.

Even if my current crashes in UE5 are 'engine-specific' as you suggest, the lack of the 0x12B patch means my CPU is currently unprotected against the Vmin Shift defect. I am not just looking to fix a crash; I am looking to ensure that my hardware doesn't suffer irreversible physical degradation due to a faulty power management policy that MSI has already fixed for other models but missed on this one.

As shown in the official Intel Processor Identification Utility report I've shared, the update is simply not being applied. This is a legitimate firmware issue that needs to be escalated to MSI's engineering team

 

[electrostingz]

I think maybe you misunderstood my points, it is worth chasing the microcode update but in the meantime whilst you wait or try to resolve...

1) Ignoring the microcode update for a moment I'm suggesting that perhaps your crashing issue lies elsewhere. (what have you done to try and resolve this / check?)

2) And given your CPU does not exceed 5GHz the Vcore should remain well under 1.5V, check it in hardware monitor / HWINFO under a single core benchmark / light load. So if you are not sure about your CPU and the implications of hardware degradation consider this as some form of peace of mind in the event you do not get an updated microcode.

 

[lbtan8415a602e5]

You can update microcode accoding to:

https://www.reddit.com/r/GamingLaptops/comments/1engies

Mine got more stable after updating to the latest microcode

 

[electrostingz]

The BIOS loads the code on boot which the OS will then read, the above link is a soft version that will inject into the boot loading stage of the OS so this will only work in Windows. The actual BIOS version / CPU will not be updated with this method but it is a workaround if successful.

 

[lbtan8415a602e5]

It works for my i9-13950HX, no more random 'status_access_violation' error.

 

[apmraide15b602e4]

la solucion es para el CPUID B0671 , yo necesito el CPUID i7-13700HX (B06F2)

 

[apmraide15b602e4]

Besides, I believe MSI blocks software-based microcode updates, and it can only be done through a BIOS update. I tried doing it manually using the 06-bf-02 file from the Intel GitHub repo, and it didn't work either. It initially shows as successful, but after rebooting, it’s still on revision 2C, so MSI is definitely blocking it. (https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20241029)

 

[lbtan8415a602e5]

Have you disabled virtualization through Windows and Intel virtualization and VT-d in the BIOS? Microcode will downgrade if you enabled them.

 

[apmraide15b602e4]

Thanks for the suggestions. I’ve tried everything mentioned:

1. Disabled Intel Virtualization Technology and VT-d in the BIOS (using the MSI hidden advanced menu).
2. Turned off Core Isolation (Memory Integrity) in Windows.
3. Disabled the Windows Hypervisor and Virtual Machine Platform via features and bcdedit.
4. Verified the microcode file (06-bf-02) was correctly named and recognized by the driver (getting Code 0 on install).

Despite all these layers being disabled, HWiNFO64 still reports revision 2C. It seems that this specific MSI model (with BIOS 113) has a hardware-level Microcode Write Protection (Lockbit) that seals the microcode during the initial boot sequence.

It appears that for this laptop, the only way to move past 2C is to wait for a future official BIOS update from MSI that includes the 0x12B/0x136 patch natively. Software injection via the VMware driver is blocked by the motherboard's security policy.

 

[lbtan8415a602e5]

That's weird. I have the same model with a different CPU (also BIOS 113, my second MSI laptop bought in 2023), I also turned off Hyper-V and WSL in Windows features, and I'm able to update the microcode to 0x136 (at least HWiNFO64 and CPU-Z say so). Thank you for mentioning the microcode update, it finally fixed the random broswer crash issue (which bothered me for months, I tried everything else and almost gave up), without having to disable C states in BIOS, which produce way too much heat. I'm on Windows 11 Pro Insider Preview (29580.1000) by the way.

 

[apmraide15b602e4]

Weird , but still stuck in 2c , all I can do is wait for MSI to release a new BIOS.