Yeah, I looked up Dell Command and Configure and CCTK but neither one seems to support this system. I might try CCTK 2.2.1 anyway though.
@EvieSigma - Here is package I created with DDCU 3.1 using a modified HDR as source, leave the exe in folder when executing because during process it generates a bunch of files.
Close all open apps, stuff you need to save etc, then run the exe and wait 3-5 minutes as it updates system, then it will auto-restart once done flashing.
http://s000.tinyupload.com/index.php?filā¦191881666293359
Then on reboot check current in-use microcode version using HWInf64 or AIDA64, if version 612 then success!
If fails, it may be due to I created the exe on my system, you may need to do it on your system instead. If you need to try that, and want the updated HDR let me know I will send to you with DDCU and you can create new exe on your end that way its made on your system.
I am unsure if it pulls info/settings etc form system to create the exe, thatās why I said maybe it will fail due to being made on my system, I am unsure of what all it does during the exe creation process.
I think you should send those to me anyway, @Lost_N_BIOS , just in case, since itās going to take a little time to reinstall Windows 7 with the original CPU and then install your update.
EDIT: It turns out that it failed as it gave the update failed message once again and my microcode remains at 68 in HWinfo.
@EvieSigma - Sorry it did not work! Iām not sure how to do the exe properly like @DeathBringer did, wish he would reply here and drop me a hint 
If not, you could ask him at BIOS-mods forum to kindly make you another exe with 2015 version microcode.
Here is updated HDR and DDCU if you want to try and make an EXE on your end to see if that makes it work - http://s000.tinyupload.com/index.php?filā¦958303488145238
To use DDCU, after install open the shortcut and it will open your browser, at the top section only, browse to HDR file, then still in top section on the far right there is a little blue text line to create the exe installer.
@Lost_N_BIOS well Iāll be darned, it STILL failed, even when made on original hardware. Iāll have to contract Deathbringer and see what he can do.
Yes @EvieSigma - I saw you mentioned that at BIOS-Mods, maybe that program isnāt compatible with your system, Iām not sure.
Hopefully DeathBringer will give me some info over there, I hoped in right behind you to ask if heād fill me in so I can do for others in the future too.
Hi,
i need to Update cpu10676_plat80_ver0000060C_2008-01-19_PRD_FBAC0EED but canĀ“t find on Github the Microcode for this PlatformID.
Ideas ?
@Starfox
Maybe your platform was included in an other platform # since 2008 or someone forgot to add the newer code to the database. I suggest that you ask your question to Plutomaniac in this thread. It is the best place to get a precise answer to your question.
@Starfox - Because it was superseded by >> cpu10676_plat80_ver0000060F_2010-09-29_PRD_8FE1A1C7 and then platforms combined into 91 for your originally 80 (7) >> 91 now contains (0,4,7) >> cpu10676_plat91_ver00000612_2015-08-02_PRD_1750A2A6
So to update cpu10676_plat80_ver0000060C_2008-01-19_PRD_FBAC0EED to latest version you want >> cpu10676_plat91_ver00000612_2015-08-02_PRD_1750A2A6
Ok thanks 
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.
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.
I got the Idea when i update this Microcodes that i have Spectre Protection.
Now i know there i was wrong.
But anyway now i know how to update the Microcodes 
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
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.