Could you please post this latest dump with 62CN97WW? Thanks
Unfortunately there’s a write protection for the bios region which wont let you software flash it (fpt).
You mean biosreg.bin ??
Yeah, that’s what I thought, so is it possible to repair the original dump and flash it through a progammer ?
If it’s too much work (for you) I can live with the current SN and UUID if that won’t make problems in the future (which supposed not to).
biosreg.rar (2.11 MB)
As written problem is probably NVRAM grown too big. This bios uses 3 EVSA stores, the other 3 EVSA stores are static. Seems that there’s on block (< 4 kB) corresponding to the brown EVSA stores in padding. Your updated bios doesn’t have the last EVSA store and corresponding to that only one 4kB block used in padding. Green arrow => board specific data.
This bios seems to have a wrong size for the uefi volume holding the EVSA stores. See structure on the left, 5th EVSA and Flash Map are hidden in padding (changing the volume size makes them visible again). The bios doesn’t seem to care too much about that (until the NVRAM get’s too large).
Your old bios (left) had an additional error in the parser: “NvramParser::parseNvramVolumeBody: one of stores inside overlaps the end of data” So it seems to me that this construction works until the 5th EVSA store in this area is created/ used and grows larger than given size. Then it seems that the bios no longer can write to NVRAM, giving you the error message.
Cure would be to replace the 5th EVSA store in this volume (and the corresponding block in padding at 452000) with the corresponding empty areas (“FF”) of a stock bios, or to transfer the board specific data to a stock bios. Stock bios does have a short flash instruction in one EVSA store which possibly should be removed, but maybe it doesn’t hurt either. Programming can’t be done by update since NVRAM normally isn’t touched.
(There are some flash tools that can delete NVRAM, Samsung had such a problem for it’s 6- series UEFI bioses, could be solved by software. But if board and tool aren’t compatible one might also delete necessary standard defaults for restoring and get a brick…)
In your case I simply put in the board specific data into your dump and combined the bios region with FD/ME from your original dump.
Flash it back with programmer, read back the content of the chip and compare it to the source file, has to be a 100% identical.
own.zip (3.18 MB)
@lfb6 thanks for your efforts, I really appreciate it.
To be honest, I don’t understand much.
You mean my current updated BIOS or my OLD Corrupted BIOS ?
Gonna have to take the laptop apart and desolder the BIOS Chip again and take it to the repair shop by Monday,
By programmer also ? or with fpt ?
In your opinion, would that fix the problem (change the SN and UUID with no real issues) ?
@WGenius Both bios seem to have this “flaw”. Even for stock bios the Flash Map isn’t displayed correctly in UEFIToolNE. So it’s possible this error will come again after a certain amount of changes in NVRAM.
You have to flash back via programmer, fpt doesn’t work without tricks since certain areas of the bios region are write protected. You can always make a backup of the bios region with fpt, but you’re not able to write it (completely). Recommendatons for writing were given as if you’d have a programmer, sorry.
Changes are minimal, it’s just the earlier mentioned block that’s inserted. Since the bios region is taken from your working laptop (last fpt backup) and FD and ME are from your first (real) own backup there’s (if programmed correctly) zero chance to brick the machine. But disassembling and flashing itself has a risk of course.
It might seem that I made it more complated than necessary, I could’ve simply copied this block into your dump and call it a day. But I wanted to understand what possibly caused your error and what these 2 other bocks in padding were good for just to avoid sendnig you a file that’d cause a brick.
Currently, I’m using MBR instead of UEFI (UEFI disabled), this is the 2nd lenovo that has UEFI issues (You might ask how did I fix the 1st one, well the answer is simple: updated the BIOS through windows, luckily secure boot wasn’t enabled by default and BIOS version was old), so I’m not gonna use UEFI again, at least for Old models.
You said "it's possible this error will come again after a certain amount of changes in NVRAM" how to prevent this from happening again ? not using UEFI will solve the problem ?
So, by changing the earlier mentionned block, the SN, and the UUID will change also right ?
Sorry for the hassle buddy, and thanks again for your great help.
I did that for him 6 days ago. 
Not sure why he doesn’t just buy a programmer himself; they’re dirt cheap.
I did that for him 6 days ago.
Not sure why he doesn’t just buy a programmer himself; they’re dirt cheap.
I wouldn’t mind if I had the chance, the problem is, the only model available (here in Algeria where I live) is "beeprog" which cost too much, and I don’t have a credit card, plus if I want to order a cheap one like (CH341A) it would take up to 3 months to arrive, and sometimes it won’t.
Ah, that sucks. PM me your address and I will see if I can have one shipped to you from Aliexpress. Sure it will take a long time (if it ever arrives), but better than not having one at all. Let me know if it’s better to have it shipped from Turkey or China.
Ah, that sucks. PM me your address and I will see if I can have one shipped to you from Aliexpress. Sure it will take a long time (if it ever arrives), but better than not having one at all. Let me know if it’s better to have it shipped from Turkey or China.
That is very kind of you, but please don’t waste your money, I asked my friend before (who has a Paysera card) to order me a couple of things from Aliexpress multiple times but didn’t receive a lot of things since June (because of Covid-19 Probably), I don’t know if they stole them or something, well, welcome to Algeria
.Again, thanks for your kindness and generosity, I really appreciate it.
@lfb6 @Plastixx
Update:
BIOS flashed successfully, Notebook booted successfully, SN/UUID restored to their original values.
if I had a programmer at hand in the first place, I could just did what @Plastixx asked me to do since the beginning. but thanks anyway.
Still have one question: @lfb6 You said
How do I prevent this from happening ? by not using UEFI option ?
Thank you @lfb6 for your assistance and guidance this whole time, god bless you both @lfb6 @Plastixx 
.
Thread might be closed afterwards.
Glad you got it all as sorted out!
Glad to hear you got it fixed.
Regarding this ‘flaw’: There are some assumptions regarding the structure/ correct UEFI volume header and this isn’t fixed in the last bios version. There might be fixes in the bios code itself that make uncontrolled growth of EVSA store less likely- I don’t know. But many of these 'early UEFI flaws got never fixed.
You have a working backup of your own bios- in the worst case you just have to flash it back! Just use this machine normally without thinking too much about it- you’ll proably never experience it again- and if it happens you know how to fix it 
Will never use UEFI with old models again.
Thanks again, really appreciate it.
@WGenius Good to know it’s all sorted out. Thanks for letting us know.
Just to be clear: did you flash with the programmer or Intel FPTw ?