How to update the CPU's microcode

In a heavy virtualized environment, little glitches in a CPU's microcode - or small inefficiencies - that may not be apparent in a desktop setting, can cause a VM to crash or misbehave. This may be my long term Linux experience speaking out. But - to back that up - why would VMWare create a utility to update the microcode, if they hadn't experienced issues with their own virtualization products?

You may not have experienced it yourself DeaconFrost, as this is usually handled in BIOS updates. My MB mfg is MSI, they have a history of not updating their BIOS - and as a result the microcode in a given CPU does not get updated to fix issues Intel finds in a CPU's microcode. My MB is new, but my BIOS is from 2016 and four generations out of date with microcode. My previous MB mfg was Gigabyte - they are the opposite - they update their BIOS frequently - and include new microcode in those releases.

For those of us who have moved from Linux to Windows as their desktop (such as I did) - this may be considered a Linux user's holdover habit. Every Linux distribution that I have ever used, had native built-in mechanism to update the CPU's microcode as soon as it comes out. And that makes sense, because in the server room, Linux is heavily virtualized both as a hypervisor, and as a guest OS.

Thus - VMWare's products - popular in data-centers, sometimes had issues related to the CPU's microcode, and not necessarily their products. Issues that causes VMWare tech support issues, but is not directly related to their products. Issues that a microcode update remedied. I would imagine that they created this utility for that specific purpose. Think of it like a Windows update. If I write code using a specific Win32API, and that API misbehaves - it's not my code misbehaving, it's the Win32API. But to the end user, it looks like my program is the thing misbehaving and I get the nasty calls from the customer - when in reality it is a Windows issue.

I am not sure how old you are (I'm 61 and have been doing this for 35 years now), but way back when the first Pentium first came out - which was for the first time - a marriage on-die of a CPU and a FPU - there were math issues that the CPU did not calculate correctly. Thus the need for live microcode updates was born. Just recently, the latest AMD CPU "Ryzen" has issues. And AMD is hard a work fixing the microcode in their misbehaving CPU's.

Although to support your point, as I am on a 6th gen Core-i7 - you would expect that the microcode would have a lot of spit and polish on it by now....But when I virtualized (I have several VM's) - I began to have issues - that (as of yesterday) have evaporated since I updated the CPU's microcode. And Intel released new microcode for my CPU in July.

Hope this helps explain things -

Dave

Hi,

@dcbdis : Thanks for this.
Just updated a Kaby Lake 7700K. MicroCU shows version 5E which is the same as it was originally according to Event Viewer.
Finding the AMD files isn't exactly easy. Could dummies be used to fool VMware's installer on an Intel system ?
Or modify the batch file so it stops looking for these perhaps...
It surprises me these updates aren't widely supported for Windows, they're so important for system stability.

I'm planning on updating a I7 6700 and a 4770 as well.

In the past we used microcode updates to make a bios accept a newer gen. same lga cpu, motherboard and all that allowing of course.

Anyway, thanks for your contribution.

Cheers,

Yes, thank you. Very helpful. I've been running ESXi in various forms for 6 years now. In my current job of just under 2 years, we're running 225 VMs across multiple hosts and two VCE vBlocks. I've still never heard of it, but I don't mean that to say I am questioning it's need or existence.

I'm building a new ESXi box for home, based on a 3770K. I'm going to download that tool and see what it says about the proc. It ran perfectly fine as a Windows 10 gaming system, but this will be the first time it gets ESXi thrown at it.

My CPU is a Core i7 6900K on an MSI X99A Workstation MB. It is a new CPU for me, but not a new CPU on the market. I came from an AMD FX-8350 Piledriver and a Gigabyte MB which I bequeathed to a film student once I landed my latest software dev contract. For the new contract, I really needed an Intel platform despite the higher price. The FX is not the most efficient single-threaded CPU - but certainly a good CPU for multi-threaded applications such as video editing, 3d rendering, etc. Microcode updates really helped settle the FX CPU down - especially under VM workloads. On the Intel side, the i7 6900K is a great CPU - I can recommend it wholeheartedly. Although it's still a tad pricey.

I went with Intel because the FX platform was frankly - a disappointment in a lot of areas. I've been on AMD since the original Bulldozer family. I had recompiled all of FreeBSD from source. The system, ports, and the kernel, all with Bulldozer specific compiler flags set to try to deal with some of Bulldozer's inefficiencies. In ~ 48 hours worth of compiling, I estimate that I only gained about 10% improvement - if that. It was so small as to be very subjective. I was disappointed. Then I landed a large software development contract for Windows, about the same time as the AMD Ryzens came out of the gate. The Ryzen's had too many embedded issues specific to the CPU's microcode, that according to a lot of users' blog's I've read, caused a lot of stability issues. AMD announced that they have a microcode update about ready to be released for the Ryzen's to fix the issues.

I chose to go with Intel because in my new contract - I needed a CPU family that was well tested and not plagued with design/microcode issues. Thus I did not feel comfy with either the new AMD Ryzens, nor the new Intel Core-i9's. Both CPU's came out of the gate with their own unique issues.

The i7 6900 is every bit as much of a multi-threaded beast as the FX-8350. It has not disappointed me at all. @fdegrove - if you do any type of 3d modeling (Blender, 3dsMax, Maya, or Video editing, etc) I would recommend the 6900 or the 6950 (if your wallet doesn't pass out first at the cost). And, the 6900 according to my watt meter, uses < 50% of the wattage than the FX did. So my system runs a lot cooler. I have no experience with the Ryzens so I don't know how efficient they are. I don't trust spec sheets. But I do trust my watt meter. I had lost faith in the AMD brand with the Bulldozer/Piledriver families.... and even the lower price-point for the Ryzens, along with fairly favorable reviews I've read of the Ryzens didn't sway me. I was skittish about a new CPU family for mission critical work.

I appreciate all who responded. I hope this discussion helps others, be that with AMD or Intel platforms - especially those users who need microcode updates with the Ryzen or Core i9 platforms. This is a solution for those Windows users where their MB mfg's are not releasing new BIOS either to address the microcode updates.

I would not have gone down this road had MSI had a policy of releasing newer BIOS's that had the newer microcode in them.

Probably would not have gone down this road either if I didn't use a lot of virtualization on my workstation and those VM's were operating stably.

Still again, I would not have gone down this road if this forum would have told me that Windows 10 receives new microcode in Windows updates.

I had also contacted MSI via technical support's webpage and asked about CPU microcode updates. There are no new BIOS's planned for my MB. So this tells me that my system is stuck at version 1.0.0. Not a bad thing, I'm not having any other operational issues - until I start using virtualization. Then I get the occasional VM crash.

My CPU did need updating and the VMWare tool gave me the mechanism of updating the CPU apart from a new BIOS. And none of my VM's have crashed since the microcode update - none. That's a good enough proof test for me that my CPU needed the microcode update and it was all beneficial and worthwhile.

Again, my thanks to all who have responded to this thread. I sincerely appreciate it.


Dave

@DeaconFrost,

If you are throwing ESXi at your new CPU, I encourage you to throw something like SiSoft Sandra at your VM's and make them cry in stress tests. You may be surprised. They may be stable, they may burp. Everyone's mileage may vary in today's world...I am assuming your VM's are Windows guests. SiSoft's not applicable to Linux/BSD guests.

Today things are so much more sophisticated - and unpredictable sometimes. The days of us drawing pencil'd lines across two PCB etches of our old PC-XT's to get the CPU up to 10Mhz from the factory 4.77Mhz (that's no typo younger ones) are long gone. It's much more complex these days. My experience does not mean everyone else's is going to be the same.

I would just encourage you to stress test your VM's. If they pass - then I would recommend against fixing something, that's not broken in the first place. I had some things that "broke". You may not.

My unrequested $0.02.

Dave

dcbdbis said:

Under Linux, CPU microcode updates were easy to deploy.

That is true. Basically you just apply them during boot - see Microcode - ArchWiki

Windows will automatically do the same thing through Windows Update and you can check it as descried here windows - How do I see CPU microcode version? - Super User

@lx07,

Arch was my favorite distro!........Until SystemD that is. Then I switched to FreeBSD. SystemD caused me a lot of issues with the server's I support. Two of my customers have gone to Windows Server 2012 as a direct result of SystemD being pushed out too fast before it was usable - just like PulseAudio was - and by the same numbskull. I didn't/don't appreciate SystemD stopping daemons without asking, that I had launched manually. SystemD has morphed from an init system replacement - into a multi-tenacled monster that does nothing well. And binary logging? Just plain dumb.

I am no fan of Lennart Poettering nor RedHat. SystemD is what pushed me back to Windows as a primary platform. And frankly - I don't regret that move at all - painful as it was to move 20 TB's of data from EXT4 onto NTFS.

Bottom line W10 is being good to me, and good to my clients. I'm a happy camper.

I admit a strong BIAS against SystemD. Mea-Culpa. Others love it - I hate it. Caused me a lot of professional grief and grey hair so I got rid of it and any distro that used it.

And I openly admit that I cut my PC teeth on AT&T Unix, and Xenix on a mainframe where I worked way back when. As a teenager I interacted with an ENIAC via a 150baud acoustically coupled modem. Got excited when the first 300 baud acoustically coupled modems came out. Yep... I'm an oldie.

Back to Windows as the Main Topic:

Frankly, my Windows 10 box (after I recovered my privacy from W10) is operating quite nicely. And it requires a lot less maintenance work to keep it running well I might add. For my customers that have moved to Windows servers, I get a lot less calls from my customers about issues as well. Which allows me to focus on my development - instead of system maintenance like I used to.

For now, I can't envision moving myself - nor my clients from a Windows platform to anything else. They're simply working too well...I'm happy - my clients are happy.

I need to shutup I'm getting way off topic...Dear Moderator - My Apologies....


Dave

dcbdbis said:

Two of my customers have gone to Windows Server 2012 as a direct result of SystemD

I'm not sure I was even born in 2012. That was the previous millennium right?

SystemD is OK though. You get used to it.

Anyway, for microcode (Intel on Windows), you don't have to do nothing.

@lx07,


I have a question. My W10x64 Pro is current with updates. If what you say is true, why was my microcode out of date? There have been two major cumulative updates to W10 since Intel released the latest microcode in early July.

Why didn't my CPU's microcode get updated in the process?

This is not a flame - but rather a question and a concern....If I am manually updating microcode on a W10 system that does it's own microcode updates...I'm concerned that at sometime I may get out of sync - backwards. And in my attempt at stability - actually make matters worse. I don't want to be fighting against what Windows is trying to fix.

Does MS do some sort of regression testing on the microcode before it's pushed out in a Windows Update - and then cherry pick the microcode version that they feel is best? Or something else?

Can you enlighten me with some technical details on how W10 handles Intel Microcode updates please?

Thanks!

Dave

PS: Got to get to class now. I teach in the evenings. Won't be able to respond until tomorrow sometime. I'm -7 UTC. Colorado, USA.