Thank you for the quick response … ill try to get a programmer , i thought about it before, but just went for a new chip instead and save me the hassle of figuring out how and what to flash.
What does "removing its 0x800 sized AMI Capsule Header" mean ? i just zero over it, or delete it from the file alltogether.
Where do i get the latest full ASUS BIOS? on the support website its just 3503 beta bios with downloads a ".CAP" file for flashing with theyr EZ flash tool. (as i understand it its just the actual BIOS region, without FD, ME, GBE), how do i get the full BIN
Could the problem be CPU related since i changed the bios chip with a new one and it broke again on the second boot ? its an old sistem (2015) never repasted it untill now, changing paste / cooler didnt have any impact on behaviour.
edit : allready tried flashing the bios from the EZ flash utility and using the onboard flashback button and usb stick, downgraded it to 3003 and back to 3503 , no change in 30 min death behaviour (didi it with both the original board bios chip and the new one)
As long as the ME FW is as IT IS, no matter what bios version flashed it will behave like that.
U still have to fixit as i said or as Plutomaniac posted
CAPSULE is removed with UEFITool
The ME operates independent from bios.
The bios update file 3503 on the Asus website is full with ME 9.1.25.1005
ok i got UEFITool, im still not sure how to remove the capsule, but i’m trying to get it unlocked first
i searched to the reflash setting :
0x127695 Grayout If: {19 82}
0x127697 Variable 0x3A9 equals 0x1 {12 06 A9 03 01 00}
0x12769D Setting: Me FW Image Re-Flash, Variable: 0x40D {05 A6 FC 07 FD 07 2D 03 01 00 0D 04 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x1276C3 Option: Disabled, Value: 0x0 {09 0E 05 00 30 00 00 00 00 00 00 00 00 00}
0x1276D1 Option: Enabled, Value: 0x1 {09 0E 04 00 00 00 01 00 00 00 00 00 00 00}
0x1276DF End of Options {29 02}
0x1276E1 End If {29 02}
from that i take it i need to change the 0x40D setting from 0 to 1 => setup_var 0x40D 0x01
but i can’t get into efi shell to run the command (big red screen atached).
i made a GRUB bootable disk, but GRUB is just a bootloader, what should i do in it?
later edit : the red screen was caused by not clearing secure boot keys, even thought i disabled secure boot still needed to clear keys
booted to GRUB shell => setup_var 0x40D 0x01 - completed succesfully rebooted to shell again and checked it remained at 1, but still locked in windows, cannot dump or write the ME region
The ASUS SPI/BIOS images have .cap extension to indicate they are encapsulated, meaning protected. The first 0x800 bytes are the Capsule data in your system’s SPI/BIOS image and the capsule must be removed before using the programmer as it’s not part of the SPI/BIOS chip firmware. You can open the .cap file in a hex editor (i.e. HxD) and simply select the first 0x800 bytes and delete them. Then flash the result with the programmer. If you want to use UEFITool to remove the capsule, just select “Intel image” and “Extract as is…”. It will remove the first 0x800 for you. As for grub, it seems the BIOS can detect unauthorized NVRAM changes (some sort of checksum probably) so that “ME Re-Flash” option won’t work.
i finally received my ordered CH341A, i dumped the full chip and cleaned ME with the tutorial “https://www.win-raid.com/t1658f39-Guide-Clean-Dumped-Intel-Engine-CS-ME-CS-TXE-Regions-with-Data-Initialization.html”, didn’t work, pc boots up but in bios ME version is still N/A (i couldnt find the exact version (9.1.25.1005) so i used the closest one 9.1.40.1000_1.5MB_PRD_EXTR.bin)
i flashed the oficial bios from ASUS, i decapsulated it with uefi tools, cap => rom (renamed to bin), same rezult
i also got another brand new bios chip dumped that one and flashed it over on the original chip, nothing seems to work … can’t i just disable the 30 min timer ? is there anywhere i can edit that in hex? at least change it from 30 min to 99?
also my motherboard is ASUS Maximus Ranger VII not the Hero, got confused earlyer - but i cought it before flashing i did flash the corect BIOS
ROG MAXIMUS VII RANGER beta bios 3503 has the ME 9.1.25.1005 and in the ME repository u have the same FW version, so use it.
Not the 9.1.40.1000.
ok, finally found the right file : “9.1.25.1005_1.5MB_PRD_RGN.bin” and the fitc i used is from “Intel ME System Tools v9.1 r7”, followed the steps again, still same behaviour
i take out the chip, i flash it on another device while i let the main PC drain out with no wall plug or bios battery , i put the bios chip back in and boot up, the boot up take a while longer as it initializez the bios if i go into bios at first boot it shows ME version 0.0.0.0 , after a normal restart it goes to N/A, it always shuts me out after 30 min
i did use the oficial ASUS bios file previously as i said which did have the corect ME version = 9.1.25.1005 and that still didint solve it - (after failing with the guide, i also tryd changing some other settings in fitc but i don’t really know what im doing)
i have 3 bios chips right now :
1. the original motherboard chip . which i flashed multiple times with the cleaned bios as specified in "https://www.win-raid.com/t1658f39-Guide-Clean-Dumped-Intel-Engine-CS-ME-CS-TXE-Regions-with-Data-Initialization.html"
2. a brand new bios factory flashed (that i think got broken in the initialization phase) booted once and got past the 30 min windows , then i restarted PC ad went back to turning off at 30 min (i used the CH341A to reprogram this with the oficial ASUS bios decapsulated using UEFITool - extract as is)
3. a brand new chip factory flashed that i never pluged in the motherboard but i used it to dump a clean bin file with the CH341A programmer (later compared it to the oficial ASUS bios and it is identical), i did the clean guide with the original bios dump and this fresh clean one
this is getting so frustrating … i do not know what to check or how to debug the problem any further … i ruled out any other PC components , booted with just CPU and 1 stick of ram , so im thinking i need to buy either new CPU or new motherboard, any way to make the decision safer ? i cant afford both just to test things out.
Even if changing the timer from 30 to 90 min would be a great help… 30 min is just to low to do any usefeull work on it
Firmware wise, the most you can do is make sure (verify before/after) that the downloaded ASUS SPI/BIOS image w/o AMI Capsule (8MB, 0x800000) is actually/properly flashed into the SPI chip. Then remove all power (AC, batteries) for 1 minute and swap memory modules. If that doesn’t solve the problem, it must be hardware related (motherboard probably but do check DRAM as well).
I did verify after every flash, i did erase → blank → load the bin file → program → verify every single time i tried, also removed power plug no bios battery and hold down the power button for 30 sec without power plug to drain all capacitors
So i take it there is no way even to increase the time limit ?
I tried the python script (https://github.com/corna/me_cleaner) thats guts out most ME firmware on the oficial asus bios, flashed that, it stabilized the ME version at 0.0.0.0 even between reboots, didn’t go to N/A and the device apeared in device manager again (where previously it was in hidden devices with status = “Currently, this hardware device is not connected to the computer.”) now it apears as STATUS_DEVICE_POWER_FAILURE and i can reinstall the driver, shows up as working properly while the driver instalation is in progress, but power failure after a few moments, it has no impact whatsoever on the 30 min timer which starts as soon as i press the start button (was hoping to at least reset it starting with the driver reinstall, but no).
Must be a hardware problem so the board phisicaly can’t comunicate with the firmware properly … ill get a new motherboard, and hope its not the CPU, i checked the RAM in memTest and mostly showed no errors, it didn’t get to finish a full test in under 30 min.
OK thanx for all the help and support 
learned a lot.
The CPU should be unrelated, my guess is either mobo (bad PCH) or RAM (ME cannot reserve small amount). The 30 minute timer is hardcoded when the ME enters Recovery Mode for whatever reason and it is supposed to give enough time for a firmware repair/reflash. By the way, what does "MEInfo -fwsts" show?
MEInfo -fwsts givies out :
+ verbose :
Intel(R) MEInfo Version: 9.1.45.3000
Copyright(C) 2005 - 2017, Intel Corporation. All rights reserved.
FW Status Register1: 0x00003406
FW Status Register2: 0x00080000
FW Status Register3: 0x00000000
FW Status Register4: 0x00000000
FW Status Register5: 0x00000000
FW Status Register6: 0x00000000
CurrentState: Disabled and waiting to timeout
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: Transitioning
InitComplete: Initializing
BUPLoadState: Failure
ErrorCode: Image Failure
ModeOfOperation: Normal
Phase: ROM/Preboot
ICC: No valid OEM data, ICC not programmed
ME File System Corrupted: No
PhaseStatus: FIND_IMAGE
HECI device is found to be disabled.
Error 9256: Communication error between application and Intel(R) ME module (FW Update client)
Error 0099: Unknown error code
Error 9256: Communication error between application and Intel(R) ME module (FW Update client)
Error 0099: Unknown error code
Error 9256: Communication error between application and Intel(R) ME module (FW Update client)
Error 0099: Unknown error code
Windows OS Version : 6.2.9200 ""
OS BIOS Support : Legacy
SMBIOS Table Data
SM BIOS Spec Version : 2.8
Starting address: 0x ECF30
Table Size in Bytes: 3729 ( 0xE91 )
Number of Table Entries: the 87 ( 0x57 )
Virtual mapping of complete Table: 2 4kB Pages
Table Type 0 ( 0x 00 ) found, size of 24 (0x 18 ) bytes
Windows OS Version : 6.2.9200 ""
OS BIOS Support : Legacy
SMBIOS Table Data
SM BIOS Spec Version : 2.8
Starting address: 0x ECF30
Table Size in Bytes: 3729 ( 0xE91 )
Number of Table Entries: the 87 ( 0x57 )
Virtual mapping of complete Table: 2 4kB Pages
Table Type 0 ( 0x 00 ) found, size of 24 (0x 18 ) bytes
Table Type 1 ( 0x 01 ) found, size of 27 (0x 1B ) bytes
Table Type 2 ( 0x 02 ) found, size of 15 (0x 0F ) bytes
Table Type 3 ( 0x 03 ) found, size of 25 (0x 19 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 10 ( 0x 0A ) found, size of 6 (0x 06 ) bytes
Table Type 11 ( 0x 0B ) found, size of 5 (0x 05 ) bytes
Table Type 12 ( 0x 0C ) found, size of 5 (0x 05 ) bytes
Table Type 24 ( 0x 18 ) found, size of 5 (0x 05 ) bytes
Table Type 32 ( 0x 20 ) found, size of 20 (0x 14 ) bytes
Table Type 34 ( 0x 22 ) found, size of 11 (0x 0B ) bytes
Table Type 26 ( 0x 1A ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 28 ( 0x 1C ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 29 ( 0x 1D ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 26 ( 0x 1A ) found, size of 22 (0x 16 ) bytes
Table Type 28 ( 0x 1C ) found, size of 22 (0x 16 ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 29 ( 0x 1D ) found, size of 22 (0x 16 ) bytes
Table Type 39 ( 0x 27 ) found, size of 22 (0x 16 ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 139 ( 0x 8B ) found, size of 54 (0x 36 ) bytes
Table Type 16 ( 0x 10 ) found, size of 23 (0x 17 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 19 ( 0x 13 ) found, size of 31 (0x 1F ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 4 ( 0x 04 ) found, size of 42 (0x 2A ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 136 ( 0x 88 ) found, size of 6 (0x 06 ) bytes
Table Type 13 ( 0x 0D ) found, size of 22 (0x 16 ) bytes
Table Type 221 ( 0x DD ) found, size of 12 (0x 0C ) bytes
Table Type 221 ( 0x DD ) found, size of 26 (0x 1A ) bytes
Table Type 221 ( 0x DD ) found, size of 68 (0x 44 ) bytes
Table Type 221 ( 0x DD ) found, size of 54 (0x 36 ) bytes
Table Type 221 ( 0x DD ) found, size of 12 (0x 0C ) bytes
Table Type 14 ( 0x 0E ) found, size of 20 (0x 14 ) bytes
Table Type 127 ( 0x 7F ) found, size of 4 (0x 04 ) bytes
Error 9256: Communication error between application and Intel(R) ME module (FW Update client)
Error 0099: Unknown error code
Error 9459: Internal error (Could not determine FW features information)
Did you flash the proper/stock/healthy ASUS SPI image with the programmer before running MEInfo -fwsts? It shows firmware corruption.
yes, i just redid it again to be sure it was the clean unmodified image from asus site, extracted with uefi tools from "MAXIMUS-VII-RANGER-ASUS-3503.CAP"
same output on meinfo -fwsts or -verbose
How did you check that your flash was succesfull?
with the CH341A Programmer , after clicking program and writing the file i clicked Verify and it said chip and buffer are the same.
Well MEInfo indicates that the firmware is corrupted, it cannot be read properly. Dump the SPI chip with the programmer, compress and attach/link to the result here to double check. Maybe the SPI chip has gone bad?
had to leave for work, i wont have access to the system for couple of days, will dump it as soon as i get back, i think something else on the motherboard is faulty, since i got 2 extra SPI chips and they behave the same,
brand new ordered from bios-chip24.com, came pre-flashed with the oficial asus bios, 1 of them i kept in original state for comparison , the other i tried to flash with diferent combos of edited bios in fitc,
i also tried fully unlocked FD and flashed the chip in the actual system, without the programmer … all same rezults
Ah yes, if other SPI chips behave the same then the problem is hardware-related and elsewhere. Probably motherboard, meaning Chipset/PCH, where the ME co-processor is located. If it was memory it should have gone away when you swapped the DIMMs because it’s unlikely that both are bad. No need to upload a dump anymore.
ok, problem solved, got a new motherboard, tested ram and cpu all ok