Get latest CPU microcode without modding the BIOS

First of all this is for expert users and you should not do it, it’s more a theoretically guidance in case you want to test another microcode.


I do not recommed this method, it’s only to show how you theoretically update the microcode the mopst easiest way.


All you need is VMware CPU microcode update driver for Windows and files with microcodes.

  • Here is page with VMware driver (same as in instructions page above)
  • Here are Intel latest microcodes
  • Here are AMD not latest microcodes (since I have Intel CPU I need AMD microcodes just for the sake of “install.bat” from VMware driver bundle)
  • RWEverything – Read & Write Everything (free/portable)
  • HWInfo64 (free/portable)
  • Intel, AMD & VIA CPU: Microcode Repositories by plutomaniac
  • 5 minutes time, a cup of coffee and some luck

Don`t worry about word “Linux” – luckily bin-files with microcodes are appropriate for Linux and Windows. B

Both downloaded bundles with CPU microcodes from Intel and AMD are just archive files supported by any modern archive apps. You will need to paste files “microcode.dat” (Intel), “microcode_amd.bin” and “microcode_amd_fam15h.bin” (AMD) to the folder where you extracted VMware driver bundle.


The installer expects the microcode files to be present even if the CPU it’s running on does not need them, ie both Intel and AMD files. Run install.bat from the uCode folder and the microcode files and driver will be copied to the Windows\System32\Drivers folder, the driver executed and micro code updated if the microcode files contain a newer version.

If successful you should see the following screen.

The installed driver should have updated the microcode and will now automatically update with (max  2x) reboots. The “uninstall.bat” can be run to uninstall it if not needed. Intel may only update the microcode.dat file once every 3-6 months, so what to do if a new critical patch is available but not included in microcode.dat. Well we can add for ourselves as long as it’s in the same ascii format so that might mean having to convert a binary patch into an ascii patch.

Be aware though that it only reads the microcode version once during start-up so for instance if you have it running then run the VMware utility you will not see it update in HWiNFO unless you close HWiNFO and restart it. Example showing microcode version 0x1A.
HWiNFO can also display the microcode. 1A (0x1A)
Microcode revision can also be shown via HWiNFO

Example output

Log Name: System
Source: cpumcupdate
Date: 05.01.2018 16:23:41
Event ID: 42
Task Category: None
Level: Information
Keywords: Classic
User: N/A
No CPUs needed an update. Your system might not need this driver. 
Event Xml:">

Check your System event log to know whether downloaded microcode was applied or not after you installed it. If everything was updated then you can uninstall the VMware driver.

Words of Wisdom

If you need to ask anything after reading the guide, just don’t do it, it requires simply some experience and background if you really want to flash it, otherwise ask your OEM to deliver you an BIOS update. Sorry to say but don’t take the risk.

  • I’m not responsible for any BIOS/Mobo damage.
  • Updating the microcode can be risky and you should (as mentioned) only do it in case there is an urgent reason.
  • Loading microcode by software at boot should take practically, and almost literally, no time, some programs doing it which means you need to re-apply the procedure each time you reboot/power off your machine.
  • Microcode is stored in nonvolatile memory and must be loaded at every boot anyway. And I can assure you that Linux boots significantly faster than windows already, while loading CPU microcode via a software mechanism. Writing a few KB to CPU doesn’t take long.
  • Checking HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 might help to identify the revision and update revision since some tools read it differently, you can check it manually (just in case).

Open questions – Why is this microcode update not being delivered via a Windows Update, as has been done in the past? It is possible.

Is a new microcode update via driver a solution? I answer it myself, NO! It’s a workaround until the real problem got solved by Microsoft. The main issue is that the boot order can be mixed-up which means when Windows is started the ‘old’ code could be already loaded, so there is no guarantee that you load the ‘update’ at first, which then makes it pointless to use. Linux handle it a bit better here, since there is a strict order.

Evidence that the driver-update solution doesn’t work in most cases.



Comments are closed.

Blog at

Up ↑

%d bloggers like this: