Windows 10: How to update the CPU's microcode

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

 

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

 

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.

 

Ive no idea actually. I do know microcode is (1) pushed faster to Linux and (2) don't require anything as they can be run at boot time.

These same changes are pushed somewhat later to Windows OS (there was some dull malware a month or two ago) but what testing they do I've no idea. Presumably it is confidential.

You can't get in a muddle with Microcode though - Linux kernel abstracts it and so does Windows. AFAIK anyway.

 

I perused and searched through MS's knowledge-base. Not finding my answer, I contacted Microsoft directly.

Unless there is a severe problem causing Windows stability issues - traced to errant CPU microcode, MS does not issue microcode updates as part of the normal Windows Update process. So in a Windows environment there are only two options for Microcode updates:

1) Updated BIOS from the MB mfg.
2) Using the VMWare tool as outlined and suggested near the beginning of this thread.

Outside of these two solutions - there is no native Windows mechanism of updating the CPU's microcode.

FYI folks,

Dave

 

Hi,

The estimated life cycle of which is 5 years at best. Beyond they just do no not care. Which is why 2) is a godsend to some of us.

Cheers, *Wink