Hi,

i have updated the Microcodes successfully (see attached Picture) and flashed it.

My Problem is under Windows 10 Spectre and Meltdown Checkers says Spectre ist not protected.

Zitat von plutomaniac im Beitrag #332

---

How exactly do you expect to be protected against Spectre from a 2015 microcode when mitigations were first published in early 2018? There are no new microcodes for that platform and there won't be since it's EOL.

---

@Starfox - Windows update might give you some protections?

Nope Windows Update KB4100347 and the newer Microsoft Updates for Microcode fixing does not work for my System. It run´s into Error Message: Your System is incompatible.

It´s an older Laptop with Intel T9500 Core 2 Duo.

@Starfox - Nothing you can do then, except keep fingers crossed until you upgrade. Backups, backups, backups, of important data

I wrote the post here : Help microcode update for Aspire-531P Acer BIOS v1.22

Hello,

I think I have managed to update microcodes in a X58 gigabyte bios, but I just wan't to verify if it's normal that cbrom /d won't output microcode information at the bottom? Method used was /nc_cpucode ncpucode.bin (according to instructions in OP) Original bios list microcodes fine. MCE lists updated microcodes just fine by the way.

Regards,
Triv

@Triv

If cbrom /d was providing an output with the original Bios and you don't get one after the modifications then no, it is not normal. This already happened to me but it was a long time ago and, unfortunately, i really don't remember what was causing it and how i fixed it at the time. But here are what you could verify:

- Verify that each of your microcodes files you used to update it are the same size as the older ones. Note: I don't suspect this one that much because, usually, that would cause MCE to report some kind of errors in the microcodes.
- Verify that you didn't put the same microcode twice. This could make MCE to report that a microcode is fine but it won't report that it is there twice. (i don't suspect this one much either)
- Be sure that your old NCPCODE.BIN in your Bios was completely erased before your modified one is put in place. This one is important because if it is not erased, then cbrom will NOT try to replace the old one with the new one. It will instead try to combine the old one and the new one and that can cause problems. (I suspect this one.) Note: To be sure everything is fine related to this, after each procedure, take the time to verify that 1- the file in Cbrom was really deleted or at least emptied (0 k in it) AND that your new file that your are preparing was not modified or combined in any way. This is why there is write protection step in the procedure in the first post.

To do that last part right, you must ideally understand the (weird) way how cbrom works when you enter a command to update your microcodes, so here is what happens in the background:

1- Cbrom extract the NCPUCODE.BIN file from the bios, but don't erase it in the Bios, and copy the data in YOUR NCPUCODE.BIN that is on your PC (i don't remember if it just replace it or combine it at this point)
2- Then cbrom read the file on your PC and put that all back in the file in the Bios. (i don't remember if it just replace it or combine it at this point either)

You can now see where the potential problem is... Any file that is not empty will be put back in the Bios and, according to this, it will never be empty because it gets it from the Bios. It is a mad circle...

The solution to break that circle is to make the file on your PC write protected at the right times. By doing so, you can erase the file in the Bios (well... better said make it empty) and start fresh. You do this by creating an empty file write protected. This cause cbrom to extract the data, fail to write it on your PC, then put back the empty file in the Bios. Then you prepare your file on your PC with all your microcodes needed (modified AND unmodified), and you do the command again that cause 1- cbrom to try to put the empty file in the Bios on your PC but fail because it is write protected, 2- then put back your prepared microcodes in the Bios by replacing the empty file that was there by this time.

- Last thing worth checking is to replace your last OROM in the Bios by itself to restore the checksum. This one can also be suspected to cause the data at the bottom to not be reported by cbrom if the checksum is not right.

Hope this help.

@Triv - in addition to above thoughts, sometimes this can be normal, depending on the BIOS and the cbrom version. What would not be normal is if whatever cbrom you used showed microcodes before your edit, but then no after.
Some Gigabyte X58 BIOS is tricky to edit too, so you have to be careful. And always drop BIOS into MC Extractor afterward to be sure no packed errors shown or duplicates.
For X58 I use 115 for inspection (/D) and extract, and 155 for insert mainly, this version can/will crash at end of /d scan sometimes after mod, yet BIOS is fine so I always just scan with 115 post edit and compare/inspect/check etc.
If microcode entry is doubled, wrong version cbrom used to insert (or method to delete first as mentioned above not used), if you used 155 and didn't delete first, and it doubled in size, try with 115.
Often, you will need to manually hex edit/correct, as mentioned at post #1 FAQ #1, this is why you always check with MC Extractor post-edit, that's where you'll notice the dupe or packed error

If your final file does not have a 4 digit 16-bit checksum in hex editor (more, or less = bad) then mod is bad, redo it differently or ask for someone to mod for you.

@Phoenix48 @Lost_N_BIOS

Thanks for your through answers!

Let's see here now...

- Sizes match, the NCPUCODE entry inspected with 115 shows correct size as well for the whole bin file.
- I checked with HxD there's only one of each microcode
- And as you suspected here's comes problem after /nc_cpucode ncpucode.bin (empty) MCE still list microcodes even if inspect reports empty microcodes. However with HxD I don't seem to find any doublets.

Here's what I did to fix it (I hope), used 198, /nc_cpucode Release, got confirmation it's free, then with 155 I inserted ncpucode.bin empty then regular. Inspect now list microcodes and MCE shows no errors.
Is it fine to use 198 for releasing without risking any mess before MINIT? If not here's the bios I'm dealing with if anyone wants to take a look at it.

Thanks in advance.

edit: Where exactly do I find the checksum?

@Triv

That seems to be a brilliant way to go around the problem. The question about a mess before MINIT is a good one too. My guess is that doing only a release command should probably not have caused any problems there. If it is alright in MCE and you now get an output with /d then you seems ready for the last test: Trying to flash it. If there is a problem with the checksum then the flasher will refuse to flash it and will tell you that the verification did not passed. If you made the replacement of the last ROM to restore your checksum after all your modifications then the checksum should pass the verification test and the flasher should be able to flash it successfully.

I tried to flash it and it worked just fine. Thanks again guys!

I try cbrom 155 but nothing displayed i think its only for gigabyte mobo thanks

@Sober - No, 155 works for many brands. You post in 10 threads but in none of your posts have you mentioned what model system you have, so no one can help and all your replies on various threads only look like random replies
Please give your full model name and a download page for your BIOS/drivers etc