[REQUEST] & [HELP] MSI PE70-6QE BIOS mod via CH341A


I created a BIOS mod from the directly downloaded BIOS from MSI’s website, and mistakenly flashed it with Intel’s Flash Programming Tool instead of dumping the BIOS first, effectively bricking my laptop.

Long story short, with the very kind and very patient assistance from Lost_N_BIOS, I currently have a CH341A connection to the laptop pending for a flash, I kindly request assistance to attempt to make the laptop functional again and hopefully be provided with a properly modded BIOS for it as I have overextended my hand rushing through the field of ignorance I created for myself.

Thanks for reading!

BIOS Dump looks OK, so 1.29 and whatever ID you used must be OK for reading. Be sure when writing you use 1.30 or 1.34 and BV ID first before anything else

Best I can tell, since you are 100% sure your board already had 11D BIOS (E1795IMS.11D = 285 decimal) on it, and or NEVER had 07 or whatever that current older one they have onsite is (Yes, 107 - E1795IMS.107 = 263 in decimal)
He simply copied some other boards dump to your board, or downloaded some other dump and put on there (unsure if he tried to save or correct any NVRAM data from the old BIOS or not, but I assume not, since you wiped BIOS region, inserted stock BIOS region and was never able to start the system)
The BIOS you dumped currently has a heavily populated NVRAM area (so BIOS had been running plenty, not just once etc) and the BIOS version is E1795IMS.10F = 271 decimal version - so this is some interim version between 107 and 11D

Probably he just dumped some other BIOS, or already had a dump, or downloaded from some online source and programmed it to your board.
It may not be running due to EC FW of 11D may not work with the older BIOS he put on there, that’s why I asked you to be 100% about what BIOS was on there when you messed it up initially, so I’d know how to move forward.
For now, I will not use the NVRAM stuff in this, and make you a BIOS with stock stuff only, so serial and UUID will be gone (probably someone elses in that NVRAM anyway, same for LAN MAC ID)
Do you ever use the LAN MAC (Ethernet)?

Anyway, so we test 11D stock BIOS only and see the outcome. Program this in with programmer as outlined below using software 1.30 >>
1. Open program, on the auto function, uncheck erase and blank check, then close program.
2. Open program again, detect, choose W25Q64BV
3. Erase
4. Blank check
5. Open BIOS file I sent you
6. Hit auto This write/verify in one action
7. If match success = OK, great! >> Now, close program, then reopen
8. Read chip
9. Verify - if chip and buffer match = OK great! >> you can remove clip and try starting system.

If fail at #7 or #9 above, then try FV ID instead. If fail again, try 1.34 and repeat all steps above

Unzip first of course, this is a 7zip file in case you are unaware

Edit - I’m not sure I mentioned initially, your FPT flash should not have bricked the board, so either something was flashed wrong and you proceeded anyway against some warning, or your mod BIOS was bad (Send me a copy to check)

Thank you for your quick response!

Yes, this laptop does get connected via ethernet on occasion, but if it cannot be saved I will not complain as the alternative is very grim indeed.

I am not getting a report on W25Q64BV, only on GD25Q64, which is also automatically detected by v1.29, and even though it is not automatically detected by 1.34, this is the one I get a report on after I manually select it. Am I missing something here?

Additionally, after installing 1.30 and trying to "Detect" I received a error "Access violation at address 0097EA42. Read of access 0097EA42". This is the only version so far giving me this.

Should I proceed the steps with 1.34 and GD25Q64 or is there something I am missing?

EDIT: I am missing the original mod file, it was a simple automatic BIOS mod as per what UBU allowed, nothing else. Do you want me to recreate it?

@Fabulist - What do you mean “A report”? I only mentioned using W25Q64BV because you said your chip was W25Q64FV, GD25Q64 is totally different brand.
Look at the chip, with a flashlight and magnifying glass if you have to, what is the actual chip ID?

There is no “Install” of these programs, all are ran directly from the folders they are in, unless you aren’t using the package I usually link people to

Access violation error can be ignored, this is normal.

Yes, if you can, recreate the BIOS mod you did originally, using same version UBU and same version BIOS etc. This way I can see what the issue was, if mod was OK it shouldn’t have bricked, only made you loose serial, MAC etc.

Sorry, my bad, the W25Q64BV is the one mentioned in the guide here [GUIDE] Flash BIOS with CH341A programmer and I mistakenly mentioned it in my PM to you. As per the software detection, GD25Q64 is the correct one, as it is the only one providing a “report” meaning the data reported on the left column of these programs mentioning size, manufacturer, device id, etc.

The chip is not clearly visible, on the bottom I see a P0T333 and on its top a 258BS… something, with a big “G” on the top left, the rest has something on it making it not clearly visible, should I attempt to clear it in some way? Since GD25Q64 is the one being auto-detected and the one I backed up and sent to you and verified, it should be the correct one, no?

The only program that needed an installation was “ch341a-usb-programmer-1.30”, the others did not. This should be the same file, and you can verify that the 1.30 requires an installation, am I selecting the wrong file? Should I use 1.30 after all?

OK I did update a BIOS with UBU, however a) UBU seems to have been recently updated to a different version than the one I used about a month ago, b) the UBU link also contained the Intel RST modules, which currently does not and I do not know why, so only the .rom and not the .efi is updated to v17.5.3.4203 and, c) I see new options being updated under “Video OnBoard” which did not exist before. Unfortunatelly, the original modded BIOS and UBU versions are on the laptop’s NVMe driver, which I cannot currently transfer to another system.

Please let me know how do you want me to proceed, thanks again!

mod_E1795IMS.rar (3.81 MB)

OK, then sorry for all the info I mentioned about 1.30 or 1.34 and using the BV ID, that only applies to W25Q64FV chips. Although, I would still suggest using 1.30 or 1.34 for your GD25Q64 chip.
No, don’t clear anything, especially not before you dump it and let me see. Really, best to not clear anyway, since it’s often hard to find EC FW for certain models, so if you have EC FW on some chip then you want to make sure it’s there and valid. So you can dump if you want, then let me see a copy.

Yes, whatever you sent me was OK. No, 1.30 doesn’t require or install from the package I send out, linked above.

As mentioned, please use the UBU version you used previously if at all possible, don’t you still have a copy on your end?
If not, then it wouldn’t be a valid test, but I’ll still check the file out. RST modules are never included in UBU that I’ve ever seen.
If you can remember what version you used, I may have it and can send you a copy.

You don’t have another system you can connect the NVME drive to as a secondary device?

How’s the progress with post #2, did you try yet?

I already cleared and blanked checked it, I did make a backup before though, the one I sent you via PM earlier (reuploaded here). Should I flash it back and then flash the one you sent me?

I still see 1.30 asking me to install, it is “ch341a-usb-programmer-1.30” right?

No, unfortunatelly I do not currently have a system that can support a NVMe disk, I can however sent you the original modded BIOS if the laptop functions.

I have no tried anything yet because I am not sure everything is OK:

1. I have already erased it, backup before erase uploaded in this post.

2. If the file I mention above is correct, should I still try 1.30 first?

3. Do you want me to just flash the file you sent me considering all of the above or have I done something wrong?

Give me the go and I will start!


MSI_BIOS_BAK.rar (3.9 MB)

No need to program in some other BIOS, than the one I sent you after that, that doesn’t make any sense to do

That is not the package I sent, so I can’t vouch for the use or functionality of that version. Some are edited, some are hacked, some are filled with viruses, so you have to be careful.
Ohh, I see that is the one in my package, sorry! I downloaded my own package to check, that was driving me crazy Yes, that is fine, I have it installed and use it too
But, if you want, here is the 1.30 one I thought was in there, this one runs from folder as-is, either is fine same/same >> http://s000.tinyupload.com/index.php?fil…600371491894010

Yes, no rush, once back up and running, then you can get me your original mod BIOS so I can check it.

Yes, program in the BIOS I made and lets see outcome.

My lord and savior Lost_N_BIOS bless me with knowledge! It powered on and it works!!!

Fan control was lost, but reinstalling dragon center apparently provided fan control back!

Everything seems to be working smoothly, which is great! Will we try updating VBIOS now as well? Can I proceed to update MEI with this BIOS?

I have also uploaded in a .rar the following:

a) E1795IMS.11D is the BIOS that bricked the Laptop, as I made it via UBU.
b) A setup.ffs file from Intel’s Flash Programming Tool (pre-flash), if it can provide you with any useful information at all (this is where I found the BIOS lock line).

Can I close the laptop down and continue the updates from within the BIOS, or do you still need it open?

Thanks again!!!


Also, should I remove the yellow thermal tape we talked about before, which is also on this chip? https://i.imgur.com/d3qiBtC.jpg

Yayyyyy.rar (2.8 MB)

Sweet bud, that’s great!!

Now, we can try getting NVRAM back in there too, this probably why you lost fan controls, not sure. Did you load optimized defaults?

I unlocked FD, and BIOS Lock (but only in Stock NVRAM area, due to unsure if boo guard is active or not)… This needs checked before you make any real edits, as boot guard is possibly enabled at the PCH, it’s not on BIOS side, but you need to confirm if it is at PCH before doing anything.
In the ME System tools package (V11), from MEinfo Folder, run the following and check the end of the report for Measured OR Verified Boot at the left/FPF side, if either are enabled then there is a lot of the BIOS you can’t touch >> MEInfoWin.exe -verbose

Thanks for the files, I will check them later today when I have more time and see if I can tell you what went wrong initially. It’s too bad you do not have a pre-issue BIOS backup made, with any tool, if you did then I could put back all your original NVRAM (Serial, controls, MAC ID etc)

Yes, you can put system back together now! Please test >> FPTw.exe -bios -d biosreg.bin
Then >> FPTw.exe -bios -f biosreg.bin

This will let us know if BIOS lock is disabled from NVRAM only, of if it has to be also changed at setup or AMITSE/Setupdata

Leave that tape there, it’s to protect the chip from something that sites over it, or to protect what sits above it from any heat.

No no, I did get the fan control back, I just needed to reinstall dragon center!

I did update MEI firmware in the past with MSI’s original BIOS, if it worked then, it should work the same way now too right? But I will do this after the VBIOS update you mentioned because MEI will get wiped again with a new BIOS, correct?

I will run the test, thanks!

OK, FPTw results:

@Fabulist - It all depends on how you flash ME FW/BIOS etc, if vBIOS would get flashed over again or not. You can update ME FW via the ME FW Update tool, then nothing in BIOS would be touched, here’s the command for that >> fwupdlcl -f me.bin
If you use FPT to flash ME FW, you have to update it via the ME FW Cleanup and update guide here, using the BIOS I sent you as a whole (it’s easier this way), then extract the ME Region (name it me.bin) after you are done with UEFITool, then use that via FPTw.exe -me -f me.bin
I can update the ME FW if you want, I planned to initially, but stopped what i was doing and wanted to see if we could get you recovered and running again first, so we’d know if all was OK or if that guy damaged something or not.
I can also update vBIOS at same time too if you want, and whatever else you want too (be specific on versions if you want stuff updated, except vBIOS and ME I would use latest)

Great, BIOS region is unlocked as I hoped, I assume ME is too since I unlocked both. Lets test and see >> FPTw.exe -d SPI.BIN
Then immediately >> FPTw.exe -f SPI.BIN

If 100% success, no error and FPT operation successful, then all is unlocked as I intended and you can for sure put system back together

I checked your mod BIOS and I see two possible issues and both can = bricked BIOS
One, if Intel Boot Guard is enabled at the FPF of the PCH chipset, then boot guard is enabled and you can’t mod many of the BIOS volumes, you’ll have to check to confirm if this is case or not using MEINfowin.exe -verbose
Look at the bottom of that report, on the Left/FPF side, do you see Measured or Verified boot enabled on the Left/FPF side? If not, then boot guard cannot be enabled properly so it’s not this that caused the brick. MEInfo folder in ME System tools package has that exe ^^

Other thing was a padding file is removed above microcode during UBU microcode or other edits. I would need to do all edits one by one with exact version of UBU to find the exact edit that made it happen, could be any of the edits would do it, or only one, or only the microcode edit.
But, anyway, this exact thing can often = brick BIOS, and it happens often during BIOS edits with some tools so it’s something I always check for when doing mod manually or checking anyone’s UBU/MMTool/UEFITool edited BIOS.

I was not even aware there is a ME cleanup guide nor did I understand what exactly it does after reading the thread, is it to just clean it? But why not update it directly??

I did update ME firmware on this laptop before, by downloading Intel CSME System Tools v11 r26 and updating to Intel CSME Firmware v11.8.65.3606 (CON H DA) via the FWUpdate. Currently, Intel CSME 11.8 Consumer PCH-H D,A Firmware v11.8.70.3626 is the latest, which I have not tried. That is what I do on desktops too, and I do get the correct version reported, is this not the correct way? Am I doing a mistake here?

FPTw.exe -d SPI.BIN >> FPTw.exe -f SPI.BIN:

I pressed Q at the end. Should I have accepted the operation?

I would like to have everything that can be updated, updated. For me what I know can be updated is whatever UBU tells me that can be updated, such as:

Intel RST: Intel RST RAID ROM/EFI v17.5.3.4203

VBIOS: Whatever is its latest version (9.0.1080?)

Network: OROM Intel Boot Agent CL 0.1.14 & EFI Lx Killer Network UNDI

CPU Microcodes: Again what UBU provides to be the latest:

1│506E3│36 (1,2,4,5)│ D4 │2019-08-14│PRD │0x18C00│ 0x18 │Yes ║
2│506E2│ 14 (2,4) │ 2E │2015-08-15│PRD │0x12C00│0x18C18│Yes ║

The above are again what I see in UBU, but if you believe something cannot be updated as such or should be updated differently or not at all, I will go with that.

So instead of you taking your time with this, we cannot try UBU again? I am saying this because I do not know how long does this take for you to do and I think you have already done more than enough! As far as I remember you said that UBU cannot update the VBIOS completely, but the rest it can?

MEINFO verbose reports this:

Windows OS Version : 10.0
FW Status Register1: 0x90000245
FW Status Register2: 0x00F60506
FW Status Register3: 0x00000000
FW Status Register4: 0x00084000
FW Status Register5: 0x00000000
FW Status Register6: 0x40000000
CurrentState: Normal
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: CM0 with UMA
InitComplete: Complete
BUPLoadState: Success
ErrorCode: No Error
ModeOfOperation: Normal
SPI Flash Log: Not Present
FPF HW Source value: Not Applicable
ME FPF Fusing Patch Status: ME FPF Fusing patch NOT applicable
Phase: ROM/Preboot
ICC: Valid OEM data, ICC programmed
ME File System Corrupted: No
FPF and ME Config Status: Match
FW Capabilities value is 0x31111940
Feature enablement is 0x31111940
Platform type is 0x11220321
No Intel Wireless device was found
Intel(R) ME code versions:
Table Type 5 ( 0x 05 ) found, size of 0 (0x 00 ) bytes
Table Type 11 ( 0x 0B ) found, size of 40 (0x 28 ) bytes
BIOS Version E1795IMS.11D
Table Type 5 ( 0x 05 ) found, size of 0 (0x 00 ) bytes
Table Type 11 ( 0x 0B ) found, size of 40 (0x 28 ) bytes
Table Type 0 ( 0x 00 ) found, size of 74 (0x 4A ) bytes
Table Type 1 ( 0x 01 ) found, size of 106 (0x 6A ) bytes
Table Type 2 ( 0x 02 ) found, size of 112 (0x 70 ) bytes
Table Type 3 ( 0x 03 ) found, size of 118 (0x 76 ) bytes
Table Type 8 ( 0x 08 ) found, size of 25 (0x 19 ) bytes
Table Type 9 ( 0x 09 ) found, size of 23 (0x 17 ) bytes
Table Type 10 ( 0x 0A ) found, size of 33 (0x 21 ) bytes
Table Type 12 ( 0x 0C ) found, size of 21 (0x 15 ) bytes
Table Type 32 ( 0x 20 ) found, size of 22 (0x 16 ) bytes
Table Type 34 ( 0x 22 ) found, size of 19 (0x 13 ) bytes
Table Type 26 ( 0x 1A ) found, size of 29 (0x 1D ) bytes
Table Type 36 ( 0x 24 ) found, size of 18 (0x 12 ) bytes
Table Type 35 ( 0x 23 ) found, size of 27 (0x 1B ) bytes
Table Type 28 ( 0x 1C ) found, size of 29 (0x 1D ) bytes
Table Type 36 ( 0x 24 ) found, size of 18 (0x 12 ) bytes
Table Type 35 ( 0x 23 ) found, size of 27 (0x 1B ) bytes
Table Type 27 ( 0x 1B ) found, size of 30 (0x 1E ) bytes
Table Type 36 ( 0x 24 ) found, size of 18 (0x 12 ) bytes
Table Type 35 ( 0x 23 ) found, size of 27 (0x 1B ) bytes
Table Type 27 ( 0x 1B ) found, size of 17 (0x 11 ) bytes
Table Type 36 ( 0x 24 ) found, size of 18 (0x 12 ) bytes
Table Type 35 ( 0x 23 ) found, size of 27 (0x 1B ) bytes
Table Type 29 ( 0x 1D ) found, size of 27 (0x 1B ) bytes
Table Type 36 ( 0x 24 ) found, size of 18 (0x 12 ) bytes
Table Type 35 ( 0x 23 ) found, size of 27 (0x 1B ) bytes
Table Type 26 ( 0x 1A ) found, size of 29 (0x 1D ) bytes
Table Type 28 ( 0x 1C ) found, size of 29 (0x 1D ) bytes
Table Type 27 ( 0x 1B ) found, size of 30 (0x 1E ) bytes
Table Type 29 ( 0x 1D ) found, size of 27 (0x 1B ) bytes
Table Type 39 ( 0x 27 ) found, size of 184 (0x B8 ) bytes
Table Type 41 ( 0x 29 ) found, size of 26 (0x 1A ) bytes
Table Type 248 ( 0x F8 ) found, size of 16 (0x 10 ) bytes
Table Type 7 ( 0x 07 ) found, size of 29 (0x 1D ) bytes
Table Type 4 ( 0x 04 ) found, size of 186 (0x BA ) bytes
Table Type 16 ( 0x 10 ) found, size of 25 (0x 19 ) bytes
Table Type 17 ( 0x 11 ) found, size of 112 (0x 70 ) bytes
Table Type 19 ( 0x 13 ) found, size of 33 (0x 21 ) bytes
Table Type 20 ( 0x 14 ) found, size of 37 (0x 25 ) bytes
Table Type 130 ( 0x 82 ) found, size of 22 (0x 16 ) bytes
MEBx Version
GbE Version Unknown
Vendor ID 8086
PCH Version 31
FW Version H
Security Version (SVN) 1
LMS Version Not Available
MEI Driver Version 1914.12.0.1256
Wireless Hardware Version 2.1.77
Wireless Driver Version
FW Capabilities 0x31111940
Intel(R) Capability Licensing Service - PRESENT/ENABLED
Protect Audio Video Path - PRESENT/ENABLED
Intel(R) Dynamic Application Loader - PRESENT/ENABLED
Service Advertisement & Discovery - NOT PRESENT
Intel(R) NFC Capabilities - NOT PRESENT
Intel(R) Platform Trust Technology - PRESENT/ENABLED
Re-key needed False
Platform is re-key capable True
TLS Disabled
Last ME reset reason Global system reset
Local FWUpdate Enabled
BIOS Config Lock Enabled
GbE Config Lock Enabled
Get flash master region access status...done
Host Read Access to ME Enabled
Host Write Access to ME Enabled
Get EC region access status...done
Host Read Access to EC Enabled
Host Write Access to EC Enabled
Protected Range Register Base #0 0x0
Protected Range Register Limit #0 0x0
Protected Range Register Base #1 0x0
Protected Range Register Limit #1 0x0
Protected Range Register Base #2 0x0
Protected Range Register Limit #2 0x0
Protected Range Register Base #3 0x0
Protected Range Register Limit #3 0x0
Protected Range Register Base #4 0x0
Protected Range Register Limit #4 0x0
SPI Flash ID 1 C84017
SPI Flash ID 2 Unknown
BIOS boot State Post Boot
OEM ID 00000000-0000-0000-0000-000000000000
Capability Licensing Service Enabled
OEM Tag 0x00000000
Slot 1 Board Manufacturer 0x00000000
Slot 2 System Assembler 0x00000000
Slot 3 Reserved 0x00000000
M3 Autotest Disabled
C-link Status Disabled
Independent Firmware Recovery Disabled
EPID Group ID 0xF9E
Retrieving Variable "LSPCON Port Configuration"
LSPCON Ports None
Retrieving Variable "eDP Port Configuration"
5K Ports None
OEM Public Key Hash FPF 0000000000000000000000000000000000000000000000000000000000000000
Retrieving Variable "OEM Public Key Hash"
OEM Public Key Hash ME 0000000000000000000000000000000000000000000000000000000000000000
GuC Encryption Key FPF 0000000000000000000000000000000000000000000000000000000000000000
Retrieving Variable "GuC Encryption Key"
GuC Encryption Key ME 0000000000000000000000000000000000000000000000000000000000000000
--- --
Force Boot Guard ACM Disabled
Retrieving Variable "Force Boot Guard ACM Enabled"
Protect BIOS Environment Disabled
Retrieving Variable "Protect BIOS Environment Enabled"
CPU Debugging Enabled
Retrieving Variable "CPU Debugging"
BSP Initialization Enabled
Retrieving Variable "BSP Initialization"
Measured Boot Disabled
Retrieving Variable "Measured Boot Enabled"
Verified Boot Disabled
Retrieving Variable "Verified Boot Enabled"
Key Manifest ID 0x0
Retrieving Variable "Key Manifest ID"
Enforcement Policy 0x0
Retrieving Variable "Error Enforcement Policy"
PTT Enabled
Retrieving Variable "Intel(R) PTT Supported"
PTT Lockout Override Counter 0x0
EK Revoke State Revoked
PTT RTC Clear Detection FPF Not set

Both Measured and Verified appear disabled.

Unfortunately, I do not understand how to identify padding problems which you mentioned before, like you do. However, if you do find out an issue, maybe you can share it with the UBU developer, so he can fix it, because this BIOS is the only BIOS UBU did not work on, so far.

How do you believe we should proceed?

EDIT: I just noticed a TPM option in the BIOS: https://imgur.com/O5pDSqi

I did not have this before, some kind of BIOS bug?

@Fabulist - I can’t be sure, are you?? About MEInfo verbose report and Measure/Verified Boot on Left/FPF side? I can’t tell in that text format, if you are not 100% sure, show me an image of the end of the report.

The ME Update/Cleanup thread is used to update and clean the ME, as well as transfer settings from your original ME FW to the new ME FW. You can’t simply insert some new stock ME FW without putting your system specific settings into it.
FW Update tool you can use bare stock ME FW, it will retain and use the current ME FW settings as it updates the new ME FW, that is only time you can use stock un-configured ME FW
Yes 11.8 Consumer PCH-H D,A Firmware v11.8.70.3626 would be the latest to be used with ME FW Update tool (I can’t download the 11.8 r18 repo right now, so can’t comment on what is latest inside there you could use with the guide)

Yes, carry on with the write operation above, reboot and then see if all is OK. Hopefully plutomaniac will be back soon to comment about this “ME Disabled” message!
I’ve asked for you and or another user too, unsure, but I’ve seen this a few times lately and asked him to check, he will once he gets back from vacation.
Try, after this, if all is OK, update the ME FW via ME FW update too, reboot once done, make a new SPI dump, and then try to write it again and see if you get the same message still after ME FW is updated.

Intel RST, you have to pick from these threads, which is compatible with your system and which you want me to use.
Intel EFI “RaidDriver” and “GopDriver” BIOS Modules

vBIOS/GOP I would update to latest, same for ucodes, PXE Boot network roms too.

Yes, you can try UBU again, leave off the microcode edit and send me the file, this is often/usually where the issue happens (but not always)
If I check that and it’s OK, then I’ll update the microcodes for you and send the file back. You have programmer now, and a good backup, so you can test anything you want, but we know the outcome of this full UBU edit already, so be ready to recover
Use your dump, edit with UBU, then either do as I mentioned above and don’t update the ucodes/send to me to check, or do the full update and test while being ready to recover before you flash or program that BIOS in. You can put it in with programmer or FPT, outcome will be same.

I have mentioned this at length several times with SoniX, I am not sure he understands or doesn’t seem to think it’s an issue while I see people bricking BIOS often due to this, maybe not enough report or know how to identify the issue to realize what’s causing it.
I’ve showed him in detail with images too, and since not everyone knows this is issue, or reports this in his thread I think maybe it’s seen as a random fluke, not an issue etc. It does not happen to all BIOS that this is done on either (add or remove padding, either can cause brick), nor does it always brick when it does happen.
It’s also not always directly caused by UBU, it’s the tools that UBU uses in the background, which he can’t edit two of (MMTool), UEFIReplace I think he can edit/use older etc.
But this happens on a random basis and not all instances cause a brick, so there is no way he can test, try to fix, work around etc in an ideal way that would be helpful for all users.

TPM option, it’s either newly visible to you in this BIOS version (ie hidden previously), or was disabled thus hidden in previous due to some other issue such as ME FW corrupted, BIOS corrupted, etc. It’s not a BIOS Bug.

Well, I get this from MEInfo verbose in CMD:

Measured Boot Disabled
Retrieving Variable “Measured Boot Enabled”
Verified Boot Disabled
Retrieving Variable “Verified Boot Enabled”

Are these the one you are looking for?

The FPTw.exe -d SPI.BIN >> FPTw.exe -f SPI.BIN results on having constant black screen, no boot no nothing, only power :frowning: do I try to repair it again?

As for the RAID ROM, isn’t Intel RST RAID ROM/EFI v17.5.3.4203 the one I mentioned compatible? Today see the Intel RST RAID ROM v17.7.0.4404. However, I also noticed in the other thread that they are categorized by chipset, so I suppose that the i7 6700 CPU which runs on the HM170 Chipset on this laptop, if I am not mistaken, is a 100-series chipset, which according to the thread the correct module should be a v15.9.2.3386. I am not sure about this though…

I see, well if you retrieve some other valuable information then from all of this that could possible help UBU it would be great!

The TPM option was not available when I first purchased this computer, although on some sellers on Google they do mention that TPM is included. This is very weird!

Should I proceed to reflash your BIOS with the CH341A to restore the system? What should I try after that?

Thanks again!

@Fabulist - Yes that is what I’m wanting to see, show me image of that from bottom of report, it’s still not clear to me in text format

Thanks for test report back on FPT flash, seems something is still locked or whatever is causing the ME Disabled message is causing this as well. Were you given any error once it was done writing?
Before you recover, one more test, if you don’t mind, try this and see if outcome is same >> FPTw.exe -rewrite -f SPI.BIN

Once Plutomaniac gets back in hopefully he will see what’s causing that, I’m helping another user with same message on his BIOS too, unsure if this is some ME message to be ignored, or some compatibility issue with FPT version or what

To recover, yes, program back in last known working BIOS. To avoid this issue, since ME FW will already be updated, and so you can put system back together, any further BIOS mods can be flashed via FPTw.exe -bios anyway, since that has been tested and confirmed OK

On RAID RST, I don’t know what is compatible, this is not my area, you must read all the info on both threads I linked you to and decide and then let me know (For both EFI and orom).
If you want same version for both, and that is available for both, let me know both = same/same version

Nothing I can do to help with UBU, I’ve made him aware of this issue for a year or so, a few different times we’ve discussed it.

As I mentioned, probably TPM wasn’t visible to you before due to either older BIOS version and it was hidden in that version, or due to the ME FW was messed up before, causing it to be hidden due to non-functionality and now ME FW is correct so it’s visible again.

Do nothing after you recover, wait for plutomaniac to check the ME FW on the other thread once he gets back and then we’ll see if we can get to the bottom of the cause of this.

I could not run the test you wanted me to, I had to recover because I could not boot. No I received no errors, otherwise I would have let you know.

OK, so I run a test since I had to open the laptop again, I updated all modules possible via UBU on your BIOS, including microcodes, but not the vBIOS (it gives an option about it?), and flashed it. I also figured out the RAID RST ROM/EFI I should use.

It actually worked, so it seems there is a problem with Intel’s Flash Programming Tool instead of UBU? The only problem I have had, maybe because of the D4 microcode, I lost control of MSI’s power/OC settings in the Dragon Center (reinstalling it did not change anything). There are options such as “Sport” that OC the CPU to about 3,3GHz for example, but in order for it to work, Intel Speedstep and the C states need to be enabled into BIOS.

The CPU was stuck at around 2,6Ghz, and the “Sport” option was not selectable, as if I had Intel Speedstep disabled into BIOS. I do not know what the problem is.

I will wait for the ME, however, I did update it in the past and it was working properly as far as I can tell, the TPM was not avaialble from when I purchased the computer (and even after multiple MSI BIOS), long before I updated ME.


Yes, sorry, I didn’t think of that, you’d have to recover first no matter what to then test the -rewrite method.

Did you use the same older version of UBU this time, that you used before? If not, then it’s not a valid test. I doubt it’s anything to do with FPT, and same FPT version should have been used both times anyway (If you meant you flashed via FPT)
Send me this mod BIOS You made and I will check it, then we’ll know if this padding this is an issue for your BIOS or not, or if it was only done with previous UBU edit but not this latest one you just made.

On ME, as mentioned, go ahead and update it via FW Update tool, then reboot and see if you still get same ME Disabled messages on FPT flash attempts.

TPM must have been hidden previous BIOS then,

Ah, you are right, my test is not comparable as the UBU version is not identical.

OK so, two things:

1) ME firmware was updated and is reported in the BIOS as such, everything in the system seems OK. I used v11.8.70.3626 as it seems, according to plutomaniac’s thread to be the maximum version compatible with the system.

2) I created a second modded BIOS via UBU (uploaded here), on which I updated the Network and RAID modules, but not the microcodes. MSI’s power\OC settings were restored and I can set the CPU to “Sport” mode again. This means that for some reason when updating the microcode, via UBU at least, I lose OC control and the CPU runs on minimum speed (it never clocks up at all).

The FPTw.exe -d SPI.BIN >> FPTw.exe -f SPI.BIN says “Unable to detect ME disabled”, I did not accept the operation.

EDIT: Also, really cool I can use TPM now!


Upload both of those current UBU mods so I can see if this padding is removed in either, if it is then we know this is not a problem on this board/BIOS and some other thing I didn’t notice causes the brick.
Sounds like current/latest UBU edit you mention is removing this padding too, thus the issues you describe above with microcode edit, and loosing OC control. But at least its not bricking.
Check current microcode shown in HWInfo64 with this situation and see if microcode shown is version you expected (or none) - You can see it here, in either place


Or you can see current micocodes in any BIOS by drag/dropping it onto ME Extractor, or with UBU scan if you want to wait for that each time, downloads are in the “releases” tab at top/middle

Thanks, so ME FW update did not get rid of the message, we found the same in other thread where we’re seeing this, I updated his ME FW manually there too.
Maybe some bug in FPT version or something, causing this message, we know it’s not disabled so the message is false, but we’ll have to wait and see what’s causing it.