How to to confirm the Intel microcode revision for your CPU has Spectre patches

First things first. There are two attacks, Meltdown and Spectre, and three total vulnerabilities, with two being variants of Spectre. Only one of the Spectre variants requires a microcode patch. Here is a more accurate description:

Spectre CVE-2017-5753 Variant 1 Bounds Check Bypass Requires software/browser update.
Spectre CVE-2017-5715 Variant 2 Branch Target Injection Requires microcode AND Windows update.
Meltdown CVE-2017-5754 Variant 3 Rogue Data Cache Load Requires Windows update.

Now, the fix for variant 2, has a hardware (microcode) and software (Windows) component. Windows will only enable the mitigation IF it detects hardware support for the patch. This hardware support is delivered through a microcode update.

On Jan. 8, Intel released a new >>>Linux Processor Microcode Data File<<<. This is essentially a package that contains the latest microcode revisions for most of Intel’s CPUs going back decades, revisions that can be applied by the Linux kernel on boot. However, it’s important to understand that not all microcode updates in this package have the Spectre patches, so not all CPUs have received the fix yet. Some microcodes in this package are very old, so this seems to create some confusion.

Another thing that creates confusion is that even the microcodes updates that DO have the Spectre patches were not actually compiled on Jan. 8. Some of them have creation dates from November. It’s just that they were made public on Jan. 8 when the new package as a whole was updated. Remember that Intel has known about the Spectre vulnerability since early June when it was reported to the company by researchers at Google. Therefore, it had a lot of time to come up with fixes and prepare them, which is why an actual microcode revision date of November is not unusual and is not an indication that the microcode update does not contain the Spectre patch. Intel said that it will release microcode updates for additional CPUs by end of January, so we will likely see yet another Linux Processor Microcode Data File update until then. Here are the changes compared to the previous Microcode Data File release from November:

– Updates upon 20171117 release –
IVT C0 (06-3e-04:ed) 428->42a
SKL-U/Y D0 (06-4e-03:c0) ba->c2
BDW-U/Y E/F (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx (06-45-01:72) 20->21
Crystalwell Cx (06-46-01:32) 17->18
BDW-H E/G (06-47-01:22) 17->1b
HSX-EX E0 (06-3f-04:80) 0f->10
SKL-H/S R0 (06-5e-03:36) ba->c2
HSW Cx/Dx (06-3c-03:32) 22->23
HSX C0 (06-3f-02:6f) 3a->3b
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
KBL-U/Y H0 (06-8e-09:c0) 62->80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
CFL U0 (06-9e-0a:22) 70->80
CFL B0 (06-9e-0b:02) 72->80
SKX H0 (06-55-04:b7) 2000035->200003c
GLK B0 (06-7a-01:01) 1e->22

I guess you could try to figure out which CPUs got updates from that, but if you really want to make sure, you can use the >>>VMware CPU Microcode Update Driver<<<, also known as a fling, to temporarily test. You can follow the instructions on that page, or the ones bellow. It’s pretty simple:

– First, use HWiNFO64 or some other tool that can read your CPU’s current microcode revision and note it down.
– Download and unpack the VMware driver to a folder of your choice.
– Download the AMD microcode updates from the Linux Kernel repository. The tool needs both the Intel and AMD microcode update packages to be present, but will only use the Intel one if you have an Intel CPU. Unfortunately, AMD no longer distributes its microcode updates publicly but does provide them to the Linux kernel developers. So grab them from >>HERE<<. You need the microcode_amd.bin AND microcode_amd_fam15h.bin. Put these files in the same folder as install.bat from the VMware application.
– Download the latest Intel Linux Processor Microcode Data File (see link above). This will be archived as tgz. Unpack it and you should have a file called microcode.dat and a folder called intel-ucode. Copy only the microcode.dat file to the same folder where you copied the AMD files.
– You’re now good to go. Right click on install.bat and execute with administrator privileges.
– Open the Windows Event viewer (Win key + R, type eventvwr). Go to Windows Logs > System and look for an event from cpumcupdate. Click on it and it should say “Successfully updated microcode on one or more CPUs” if a microcode update was found for your CPU and was applied. If it says something else, there’s nothing new for your CPU.
Note that this does not mean the microcode update actually has the Spectre patches. It just means the tool has found a newer microcode for your CPU than you had and applied it.
– Reboot your computer and then use HWiNFO64 to check the CPU’s revision. It should be different.

OK. At this point we want to check if this new microcode has the hardware patch for Spectre. For that we will use Microsoft’s Speculation Control Validation PowerShell Script. You can follow the instructions in this Microsoft support article, but I’m pasting them bellow for convenience:
1. Go to
2. Download to a local folder.
3. Extract the contents to a local folder, for example C:\ADV180002
4. Start PowerShell and type these commands:


PS> # Save the current execution policy so it can be reset
PS> $SaveExecutionPolicy = Get-ExecutionPolicy
PS> Set-ExecutionPolicy RemoteSigned -Scope Currentuser
PS> CD C:\ADV180002\SpeculationControl
PS> Import-Module .\SpeculationControl.psd1
PS> Get-SpeculationControlSettings
PS> # Reset the execution policy to the original state
PS> Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser

If the microcode update contains the Spectre patch, the output should look like this:
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False

and lower:
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False

If you see False instead of true, but your microcode got updated, it means your CPU had a newer microcode available, but not one with this particular patch. You might also have noticed the line saying "Windows OS support for branch target injection mitigation is enabled: False" even if you have the hardware patch. This happens because the microcode update is re-applied at every reboot and the VMware driver is a kernel driver. This means it starts later in the kernel initialization process after the kernel has already seen the older microcode update applied by your BIOS and has disabled the Windows support for the Spectre mitigation. The PowerShell script, however, gets executed much later (manually) and sees the new microcode eventually applied by the VMware driver.

So, while offering an elegant way of applying microcode updates, the VMware driver can only be used for verification purposes and not for mitigation in this case, because it executes too late in the boot process. You need something to apply the microcode update earlier, before the Windows kernel starts. And that something is BIOS/UEFI. You can go ahead and remove the microcode update and the VMware driver at this point, by using the uninstall.bat provided with the application.

If you're one of the lucky people who got a microcode update with the Spectre patch, you can use the other guides on this forum to extract the specific microcode for your CPU from Intel's .dat file, insert it into your BIOS/UEFI image and flash it. That process won't be covered here.

For those who have trouble with PowerShell script (or PowerShell itself) I converted (literally) PowerShell script into .Net application:…s-check.418918/

Updated: But be aware that according to testing neither script nor utility works in unpatched Windows 7 due to unsupported parameters for Win API function NtQuerySystemInformation used there for checking the status of both mitigations. Probably with Spectre/Meltdown patch MS added support for new parameters of NtQuerySystemInformation .

As i write again and again dont use the new microcodes they are all problematic.
1 – (Kaby Lake U/Y, U23e, H/S/X) Symptom: Intermittent system hang during system sleep (S3) cycling. If you have already applied the firmware update and experience hangs during sleep/wake, please flash back to the previous BIOS/UEFI level, or disable sleep (S3) mode on your system; and then apply the improved update when it becomes available. If you have not already applied the update, please wait until the improved firmware level is available.

2 – (Broadwell E) Symptom: Intermittent blue screen during system restart. If you have already applied the update, Intel suggests continuing to use the firmware level until an improved one is available. If you have not applied the update, please wait until the improved firmware level is available.

3 – (Broadwell E, H, U/Y; Haswell standard, Core Extreme, ULT) Symptom: Intel has received reports of unexpected page faults, which they are currently investigating. Out of an abundance of caution, Intel requested Lenovo to stop distributing this firmware.


Also the vwmare tip dont work to enable protection it to slow to load as u said. Only a microcode in the uefi-bios can help here.

As I said, the VMware Driver method can only be used to verify that a) there is a new microcode available for your CPU and b) that microcode contains the Spectre fixes. Once you determine that, you have to either push your motherboard/laptop/computer vendor for a BIOS/UEFI update, or use a tool to mod your BIOS and insert the microcode update.

Actually, the VMware Driver method, even if it starts late, could help Windows servers that run virtualization hypervisors like VMware because it will expose the fixes to them and they can further expose them to guests OSes. It won’t help the servers themselves though. Also, the microcode updates might contain other stability/bug fixes that will get applied.

The reason why I wrote this guide is that a lot of users who haven’t received BIOS/UEFI patches in years might now be looking for Spectre patches. They might find this latest Intel microcode package that contains a microcode update that’s newer than the one they have (years old). But while this microcode update might be newer than what they have on their own computers, it might not actually contain the Spectre patches. My guide provides a method for testing that.

But in either case, even without the Spectre patches, it’s probably a good idea to deploy any microcode update you find with the VMware Driver method because it could fix other stuff. I don’t think the problems you describe actually occur if Windows doesn’t also enable the mitigation. And if you have problems, you can easily remove the VMware Driver and return to your old microcode.

@Skello ,
It will be more reasonable if Intel does published the exact list of µCode Revision which does patch Spectre (partially or fully).
At the moment it does seem the confusion, and the VMware Driver ‘exercise’ does seem reserved for IT engineer only and not for the standard users.
I hope some synthetic “Spectre” diagnostic (cpu, gpu drivers, antivirus, etc…) Tool be available soon for the user’s under Windows or others OSs.

I agree, but it is what it is.

There is this simple tool, but it will only tell you whether your computer is vulnerable or not to Spectre or Meltdown, or both, without other details.


Try my utility. I made it from PowerShell script published by Microsoft…s-check.418918/

It is .Net application built with .Net framework 4.5

And another user gave a link to Linux tool (see in OP).


I will try the tools you refer to see if my PC ASUS Sabertooth X99 Haswell-E is now 100% protected against Spectre or Meltdown or Spectre/Meldown combination.
But I am not sure if the tools does analysis of ALL the critical ingredients.

I had done specific performance benchs before all “patchs” were applied (W10 January updates, GPU Nvidia driver update, Intel µCode update to “3B”, antivirus, etc…).
I plan to do to the same benchs after all the “patchs” applied to evaluate the performance downgrading.

Here are some links about the Meltdown/Spectre debacle.


Personally I have “experimented” on a antique AMD Sempron 3000+ K7 64bit W7 PC (used only for pure technical tests) the MS update improvisation (PC not rebooting):

My recommendation: do a daily system disk backup during this fiasco period…

Please can you provide me the link to get your Tool ?

Here is the current screenshot I have with Shampoo tool with "3A" µCode for Haswell-E and all updates applied (Meltdown not vulnerable):
[[File:Spectre_Meltdown CPU checker_µCode_3A.PNG|none|auto]]


It has same output as SpeculateControl PowerShell command published by Microsoft

Thanks for your Tool.
I got this screen:


Please, can you comments the "False" (yellow items) ?
Does it confirm the Ashampoo Tool diagnostic ?
What do you suggest to do to be 100% protected ? Do you think µCode_3B will assure 100% the protection ?

Another question: under W7 SP1 32bit I got this error with Ashampoo Checker:

What is your opinion ?


You only need updated CPU microcode and you will be protected better.
And you could just select text in window of tool and copy-n-paste it here.

here is the screenshot for the AMD machine:


What do you think about this case ?


I do think µCode Update trying to patch the Intel CPUs are not ready and fully reliable at the moment even if the bugs were identified from June 2017.


According to the above link Intel, µCode Revision Plan does seem now delayed for Skylake and above are ETA end of Jan 2018, Haswell and Broadwell are Feb 2018, Sandy Ivy Maybe late March 2018. Westmere and Nehalem May April 2018.

Code of PowerShell script (and which I translated to C# code) suggests that AMD systems are not affected, so it doesn`t check mitigation for Meltdown.

Here are the tests results after CPU Haswell-e Update µCode from “3A” to “3B”:
1) Ashampoo Checker Tool does diagnostic no vulnerability, and this is confirmed by Mitigation Status Tool:

Nota: Checker Tool does warm ‘internal error’ is there is no internet connection during the test !

2) Performances does seem downgraded from 8% to 13% (Anvil benchmark) for the system disk.
Chris Win Index does also report a similar downgrade performance of the system disk.

@mbk1969 , @Skello , @Lex
Here are some questions about the 2 tools I used to detect Meltdown/Spectre vulnerabilities on two different platforms:

1) Ashampoo Spectre Meltdown CPU Checker Tool v1.1.0
The requirements are:


Another requirement not reported is the need of a internet connection active.
Why ?
(If the PC is not connected you get an ‘internal error’…)

This tool does work on Intel_X99_W10_64bit_RS3 platform with these .NET Frameworks and PowerShell versions installed and updated:


This tool does fail on antique AMD_Sempron_3000_W7_32bit_SP1 with these .NET Frameworks and PowerShell versions:



Is it because .NET Frameworks v5.1 is not installed ?
Is it because PowerShell v2.0 is obsolete ?
May be, but trying to install .NET Frameworks v5.1 (Win7_KB319566-x86 file) does offer a BSOD.
So, its egg and chicken … this tool does require a MS piece of software which is not supported!
This does seem a conceptual bug.

Moreover, Lex reported me this Tool does seem bugged and does open the vulnerability of the PC because "It changes ExecutionPolicy in PowerShell to less secure. After use you probably need to execute:
Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope LocalMachine

Please can you explain in more details what does it mean ?
Any additional action to do after each time the Tool is run ?

It does seem a conceptual non sense that a such tool does open the vulnerability to check if the PC is vulnerable ?
If my PC is more vulnerable after running the tool than before, what is the interest ?

2) Mitigation Status Tool

This tool does work on Intel_X99_W10_64bit_RS3 Haswell-E CPU for µCode "3A" and "3B".
Does this tool also open the vulnerability of the Intel_X99 PC ?

This tool does fail on antique AMD platform as reported to mbk1969.
Is not it PowerShell version v2.0 instead of v5.1 ?
Is not it .NET Frameworks version problem ?
Does this tool also open vulnerability of the AMD platform ?

1) You should understand that since I did not develop this Ashampoo tool I can only guess.

If they state that tool requires Windows Management Framework then I can assume that it simply installs PowerShell module published by Microsoft and use it to evaluate vulnerability. And to do this tool can decrease the execution policy (by Set-ExecutionPolicy) to be able to download PowerShell module, install it and execute. And of course it needs Internet connection.

You mistake .Net Framework for Windows Management Framework (WMF). They are not related, but WMF can contain parts implemented on .Net.

Versions of .Net framework: 4.0, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1. Any 4.x version can be upgraded to newer one. There are older .Net framework versions 1.0, 2.0, 3.0, 3.5, but we can omit them here.

Win7 comes only with .Net 3.5, and you can install any .Net 4.x; Win8 comes with .Net 4.5, Win8.1 with .Net 4.5.1, Win10 with .Net 4.6.

Here is the link to download Windows Management Framework 5.1…s.aspx?id=54616

Now to PowerShell (PS). Win7 comes with PS 2.0, Win8 with PS 3.0, Win8.1 with PS 4.0, Win10 with PS 5.0. But you can upgrade to any newer version. To check version of PS, launch PS , type “$PSVersionTable” and press <Enter>, and you will see something like this:


Name Value
---- -----
PSVersion 5.1.16299.98
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.16299.98
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3

Value "PSVersion" gives you actual version of PS.

Now to "Set-ExecutionPolicy". It only sets PowerShell policy for execution of PowerShell scripts on your computer. You can decide whether to allow execution of PS scripts downloaded from network (allow, allow only to signed ones, disallow). So it is not a system wide setting.

[quote="100PIER, post:17, topic:32312"]
2) Mitigation Status Tool

This tool does work on Intel_X99_W10_64bit_RS3 Haswell-E CPU for µCode "3A" and "3B".
Does this tool also open the vulnerability of the Intel_X99 PC ?

This tool does fail on antique AMD platform as reported to mbk1969.
Is not it PowerShell version v2.0 instead of v5.1 ?
Is not it .NET Frameworks version problem ?
Does this tool also open vulnerability of the AMD platform ?


2) My tool works with .Net framework 4.5 or newer. It doesn`t need PowerShell or Windows Management Framework. I just read PowerShell script published by Microsoft and translated it from PowerShell script syntax to C# syntax. All this script (and my tool) does is calling one specific Win API function to retrieve info about mitigations, plus it uses Windows Management Instrumentation (WMI) component of Windows to retrieve details on CPU.

Thanks for the information.

1) About W7 SP1 AMD platform.
Ashampoo Tool:
Yes, I am not familiar with WFM and .NET items.
Ashampoo Tool does need WFM v5.1.
Under W7 x86 WFM v5.1 is offered via “” file. As I said in my last post, trying to apply this KB does offer BSOD on W7 SP1 platform.
So, does it mean this tool does not work on any W7 SP1 platform ? (contrary to the listed requirements) ?
Do I have first install .NET v4.x over the native v3.5 on W7 SP1 ? and then may be WFM v5.1 is installable ?
Do I have also to upgrade native PS v2.0 to PS v5.x ?
Is there an order to respect to install these 3 components (.NET, WFM, PS) ?

Mitigation Status Tool:
Do you have validate your tool as well for W7 SP1 32bits ? I don’t understand why the error code "0xC0000003"
If I understand your tool does need only .NET Frameworks v4.5 or upper (no PS, no WFM used).

2) About W10 platforms.
I have also tested the tools on a P8Z77-V Deluxe W10 x64 RS3 platform with Intel IvyBridge CPU.
Here are the screenshots:



BEFORE W10 Cumulative Updates January:



AFTER W10 Cumulative Updates January:


Why the "false" value for item (PCID performance) for CVE-5754 after W10 January updates for ?
On X99 Haswell-e the value is "true".

All .NET 4.x just upgrade older 4.x in-place, replacing completely.
All .NET 3.x just upgrade older 2.0 in-place, replacing completely.
That means that .NET 2.0/3.0/3.5 coexists with any .NET 4.x.

As for order, first you install/update .Net framework, then on Win7 I recommend to update at list to PS 3.0 (on newer Windows you can skip), then WMF.

And for WMF 5.1 we read among requirements:
WMF 5.1 requires Microsoft .NET Framework 4.5 or above. You can install Microsoft .NET Framework 4.5 or above by following the instructions at Installing the .NET Framework.

Correct - tool needs .NET 4.5 or higher.
And I did not test it with any 32-bit Windows because I dont have such at hands. But tool should work because it is built as 'Any CPU'&quot; .Net application (so on 64-bit OS it should execute as 64-bit process and on 32-bit OS as 32-bit process).<br /><br />Code &quot;0xC0000003&quot; means that Win API function just doesnt understand/support input parameters, which only possible if user did not install certain Windows update (for these mitigations). That`s the way to distinguish Windows with and without installed patch.
Here are two values of error for that:

MessageText: {Not Implemented} The requested operation is not implemented.

MessageText: {Invalid Parameter} The specified information class is not a valid information class for the specified object.


Because PCID is a hardware feature which is present in new CPUs since the 2010 Westmere microarchitecture - Process Context IDentifier. It just allows to boost memory operations.