I don’t understand. Do you mean MCE?
What do you propose?
@Fernando, nothing :
Yes, MCE, TYPO
Changed structure MCE.DB
All questions to our friend @plutomaniac
Sorry, @Ditier
I have a new problem,
After building MCE.exe for v1.96.0 r279, it says:
“MCE Extractor v1.96.0 r0 Dev” instead of “v1.96.0 r279”, why is that? 
EDIT: @MeatWar, Can I fix it?
Pre built user, before the official builds from the dev.
EDIT: There’s nothing to fix… its pre builds with new mcodes between the dev releases, perfectly useable, as he can’t do it every time a new mcode pops… understood now?
As soon as the dev releases a new build, replace it, simple.
Every user can do their own mce db and exe.
It’s all documented.
You can edit your posts to add more info, no need a new post with every single time for same subject.
Watch the code on my edit to your post…simple.
1 Like
I have found the solution, it only needs creating a new directory to work with.
There is new file build at Release DB r280 · platomav/MCExtractor · GitHub
And can work under UBU being v1.96 r280. 
This needed editing ubu.bat thanks to @ro_beri again.
1336: remove “-ubu”
1339: rem whole line
1430: remove “-ubu”
Answer from UBU developer:
Так то да, можно убрать -ubu, но этот ключик давал 2 возможности:
1 - при выводе списка сами мкрокоды не извлекались
2 - вёлся счёт количества микодов в биосе, что очень важно при замене АМД микодов на Аптио 4, да и на А5 тоже можно было увидеть что обработаны все микоды. (для Интел это не критично, они всегда в своём контейнере)
cpu806F4_plat87_ver2B000580_2023-11-20_PRD_93AAEF8F
cpu806F5_plat87_ver2B000580_2023-11-20_PRD_93AAEF8E
cpu806F6_plat87_ver2B000580_2023-11-20_PRD_93AAEF8D
cpu806F7_plat87_ver2B000580_2023-11-20_PRD_93AAEF8C
cpu806F8_plat87_ver2B000580_2023-11-20_PRD_93AAEF8B
Intel.zip (2.8 MB)
4 Likes
hi Guys
new microcodes intel 12-13Th IDs:
cpu90672_plat07_ver00000035_2023-12-05_PRD_5B76074D
cpu90675_plat07_ver00000035_2023-12-05_PRD_5B76074A
cpuB06F2_plat07_ver00000035_2023-12-05_PRD_5B7406CD
cpuB06F5_plat07_ver00000035_2023-12-05_PRD_5B7406CA
Extracted from bios MSI B760M Mortar M81 Beta build date 22-02-2024
Archive contains Files below.
not in database MC extractor
Enjoy
Intel MCode 22-02-2024.rar (876.8 KB)
3 Likes
I’m coming across an interesting issue when pulling microcode from some ASUS board files. The microcode cpuFF0671_plat32_ver00000104_2022-04-19_PRD_A0E54C6F is corrupted. I’ve verified this across multiple different BIOS versions and it seems to be all across the board. Any idea what’s going on here?
Without a link to a firmware or a productname or the µcode itself the question might be difficult to answer. Sure you’re using latest MCE?
The mCode
I can’t upload it directly as I’m a new user just for this reason. But I am using the latest version of the MCE from like two days ago. It at least identifies that the code exists, but it determines incorrect checksum and that it must be corrupt. This is the case for most Z790 BIOS I’ve found. I’m not for certain what’s going on, but it appears to have some data in the padding area that it’s not registering. That’s purely speculation though.
Edit: Sorry. I didn’t realize that I had the file locked. The link should work correctly now.
0x104 for cpuid 0xB0671, which allow 13th k series cpu with non-z motherboard turn off cep so that have lower voltage but no performance loss.
Could it be possible that it extends to other CPUIDs as well? If so, the CPUID would be excessively long which might account for the supposed corruption if it exceeds the expected value length. Though, I’m not programmer.
Thanks for Sharing the information.
Interesting, I had already seen that corrupt microcode in the past but had discarded it as a mistake from Asus. The only change is at the headers, where “B0” was altered to “FF”:
It is interesting that they also altered the CPUID at the “extra” header, I was under the impression that this field is protected by the RSA signature as it is part of the RSA block:
Maybe only some fields of the “extra” header are protected and not all. This can be validated only by attempting to load that microcode and check whether the CPU microcode loader rejects it or not (which Asus probably did).
So, you’re saying that this is a “modded” older microcode which allowed a certain behavior that Intel blocked in subsequent releases.
In that case, I can mark it as a known “modded” microcode in MCE, and it won’t show the warning message, just a note that it is User/OEM modified.
1 Like
Actually, from what I can tell, the microcode is valid Intel microcode that’s used on various different board manufacturers’ boards. I pulled BIOS files from two different manufacturers lately and the CRCs match. So they’re sourced from the same location. I pulled Gigabyte and ASUS.
Also, these were pulled from Z790 boards. So it’s not non-Z. And it also extends to 14th gen CPUs as indicated here:
Intel CPUID Format v008
And this may be of use in figuring out why the microcode is listed as corrupt:
Intel Microcode Caused “Unsupported CPU” BSOD Issue
No, these are not related. Intel would not push a microcode with an invalid CPUID (i.e. FF0671) and broken Checksum. That is usually, as dsanke said, a very clear indicator of OEM modification to accomplish a specific goal. This type of modification has been done in the past to allow non-K overclocking, AVX-512 support, BCLK alterations etc. For example:
- 306C3 → 99
- 506E3 → FF
- 90672 → FF
- 90675 → FF
The vendors either trick the OS to not load a newer microcode during boot (e.g. version FF) or implement BIOS-level loading in which a different microcode blob gets picked up according to a feature/setting, installed CPU etc. The latter is what is probably happening here. These types of modifications tend to propagate to other similar vendors so that they also offer the same capability. It is not weird for this to start with Asus and then find it itself at MSI, Gigabyte etc.
EDIT: As explained here, the 104 microcode is used to allow undervolting without performance loss. This confirms that it is a “modded” microcode for a specific capability no longer offered/allowed by Intel. Asus decided to modify the header to an invalid CPUID and (apparently) use BIOS-level logic to switch to that microcode under certain situations. Other vendors (e.g. MSI) appear to maintain both 104 and newer microcodes for that CPUID without messing with the header.
2 Likes