I have an Acer Veriton X4650G I’m trying to extend the life of. I’ve upgraded to 16 GB of memory and am currently using a PCI-E x4 to NVMe SSD adapter with a Samsung Evo – it’s working great, but of course I couldn’t leave well enough alone and tempted fates by updating the BIOS to the latest (which I’ve done many times previously without issue).
The BIOS updates successfully, however, the Management Engine will not. Whenever this portion is attempted, I’m greeted with the “error 8743 unknown or unsupported platform cannot locate hardware platform identification” – which led me here: Intel ME not responsive or showing in device manager
The command being called is “FWUpdLcl64.exe /f …\ROM\ME503460.bin -allowsv -FORCERESET” – I get the same results if I try older versions, play with the syntax, etc.
I’m not sure where to start – I’m guessing install Debian and run ME Analyzer?
Follow that post you linked, the 3rd post, the tools (According the ME version of the system) can be used in Windows environment or UEFI environment.
Besides the indications on post 3, some motherboards can have a so called ME service jumper, that unlocks the access to the spi regions, if not then post 3 is the guideline.
The Acer update has failed probably because the ME FW image on the system was already corrupted, no updates to the ME FW or bios update will correct his.
The NVMe mod or other mods, should always be done upon the last bios version of an old system, the bios was tampered and probably the oficial update from Acer didnt like it.
Looking under my PCI-E slot, of course, I am not lucky enough to have such a thing.
To the left I have a silk screened layout that says:
ME_TEST
1 PS_3VSB S3_L 2
3 3VSB S4_L 4
5 SA_L GND 6
Over to the right a bit, I have 6 pads with a title above labelled ME_TEST (and numbered 1-6). I tried taking a photo, but it didn’t do a very good job.
Is any of that helpful?
(I’m in the midst of reading through the articles – it’s a lot to take in)
I dont have the schematics/service manual of that (ECS b25h4-ad) motherboard, if the the FPT tool fail the read/write acess to the regions, its your choice to test those jumpers, that were present in older Veritons generations.
CLR_CMOS is has nothing to do with ME…
Dont need to report me anything, it works or not, from this point on, i cant repair remotely your system, simple as that, my contribution is done, the operations requires a jumper or the method in post 3 of the linked post. that’s it, good luck.
FWIW - I tried another X4650G, it was on A02. I tried upgrading it to A03 using a HDD install w/ fresh Windows 10 (nothing else installed) and got the exact same error.
I’m beginning to think the ME’s were corrupt long before I touched them…
If I just leave it as is, will a corrupt ME cause any issues?
But was this other X4650G also with an A02 NVMe mod bios or was it untouched?
If so this should be reported to Acer or did they make any specific instructions in the bios update A03 procedure? They also fail…its not just us users… but its a damm coincidence 2 machines with same behaviour.
The ME is an embedded “system” within your system, the common and more frustrating issue is a timed reboot of the system 10 to 30m, due to his control of Power Management and other features of an Intel chipset system motherboard, if you decide not to fix it, its your choice only as long as you notice that the system is stable enough for your needs.
Yes – PC #1 was also on A02. That one I jumped right to latest (B1) as I’ve done many times before (I never noticed Acer giving warnings saying “hey, this is not cumulative” so I would always just YOLO it and go to latest).
PC #2 I played it “safe” – I saw it was A02, the next logical release was A03 so tried that – exact same error code. I then went to B1 and same thing as PC #1 – BIOS upgrade is successful, ME is not.
Absolutely agree – it absolutely seems like my luck as well.
Hmm - I will keep an eye out on the uptime then – I have had PC #1 powered on for a couple hours without any rebooting – but, TBD.
Manual is a bit of an odd one. Acer certainly doesn’t go out of their way to publish any detailed information – rather, mainly salesy/warning documents. The diagram on the lid is more helpful than anything I’ve found online (and even that is fairly trivial).
Well, not too much information. Thats a stock update for the bios region and a stock ME (update-) firmware.
You’d need a complete firmware dump for cleaning the ME, but I can’t see that you did use ME tools for a dump or MEInfo?
In case you want to continue download MEtools V11 - the links were in the thread you linked in your first post.
Try to run MEInfo, maybe in DOS from an USB stick if Windows dosen’t work.
The try to dump the firmware by ftp(w(64)) -d spi.bin
Post the results.
Found some pics of these boards on ebay which indeed have a ‘ME disable’ jumper, but there might be different versions. Post pictures of the jumpers on your board if unsure, otherwise it’d be a CH341 programmer.
Will do in the AM – just heading out the door (off to daycare).
Yes, I did find that jumper after the fact, but unfortunately it just looks like a write-protect jumper rather than disable. It will just block BIOS/ME updates when triggered (I tried, out of pure desperation).
I have PC #3 here, which had A04 on it already – upgraded to the aforementioned and go the exact same error. Now I’m just curious as to what the heck is happening here. OCD kicking in.
I ended up grabbing the “CSME System Tools v11 r46.rar” file, extracted that to PC #3, and under the “Flash Programming Tool” directory, I found FPTW64.exe.
I ran “FPTW64.exe -d spi.bin” and succesfully created “spi.bin” – which I’ve uploaded to the aforementioned Google Drive.
I’m going to throw a bit more fuel into the fire here.
On PC #3, I’m having strange issues with network connectivity. Through a series of trial and error, I’ve identified the issue to be the Realtek “DASH” component conflicting with Windows.
Basically, “DASH” grabs the same IP address as Windows does and they both fight it out, leading to flaky responsiveness when using the PC. I have “DASH” disabled in the BIOS – but I suspect that’s not actually true.
An incredibly ugly workaround is to let “DASH” grab whatever IP address from DHCP, and hard code Windows to be something different… but I shouldn’t have to. Any thoughts on this? Could it be related?
Edit: Apparently kind of. On Boot, I pressed “CTRL + P” to enter the ME configuration – logged in using “admin” – set a new password. Went to “Intel Small Business Technology Configuration” and set it to disabled. Everything now works perfectly.
Edit #2: Yeah, things are flaky. If I reboot the computer, sometime it will work perfectly – others it won’t. It’s almost like there is a race condition between the ME and Windows…
OK, good. I don’t see any obvious signs of corruption in the output and the dump unpacks fine in MEAnalyzer.
You might run MEManufWin64.exe -verbose that’ll check the ME but the result ist a 100% accurate. Post the result
You mentioned a Bios_WP jumper- in which position was this jumper when you tried to update the ME firmware?
I don’t see any connection between DASH and Intel ME so far. This might be a setting in bios region NVRAM, or in the network adapter firmware.
Let’s look at this ME problem at first.
Thank-you for looking it over. Prior to your update message, I had been racking my brain with some trial and error. I found an Acer webpage using the Internet Archive where they released updated BIOS versions and whatnot due to Spectre/Meltdown/etc. – I was able to eventually able to find “ME_11.6.27.3264_20170517.zip” which contained DOS updating tools and “ME_11.6_Corporate_D0_H_Production.bin”. I made a FreeDOS USB bootable stick, copied the DOS tools, the aforementioned firmware, and the failed firmware from the official updating process.
The “ME_11.6_Corporate_D0_H_Production.bin” version was already older than what was installed, so I tried the “failed” firmware from the system BIOS update – and it took successfully. This is where weirdness started happening… but based on pure guess work, what has worked for me is…
Update the ME using the DOS boot USB
Reset the CMOS jumper
Reset BIOS to appropriate settings (ENABLE DASH)
CTRL+P to enter ME config – reset to defaults (unprovision) + disable network
Reboot
Once I do everything in this order – the weirdness I’ve been seeing would go away. I’ve now done this on PC’s 1-4 and regardless of what I try (to break it) it still continues to work.
I’m guessing this issue was a combination of things…
Flaky BIOS (DASH enable/disable might not speak to Intel ME correctly?)
ME Update not completed correctly
Lingering corruption within CMOS
Pure speculation on my part.
However – at this point I’ve done this to (4) X4650G’s and each of them functions normally.
At it’s worst – it seemed like both Windows and the NIC (DASH/ME/???) were fighting it out for control of the DHCP IP address issued by my DC. Windows would show I had connection, I could ping out, but the network was super slow and some pages would fail, some would work, etc.
I noticed if I set a static IP different than that of DHCP – both the “NIC” and Windows would both respond to pings.
I appreciate both of your help though – hopefully this comes up in someone elses Google search the way the aforementioned did for me!
Regarding ME- good to hear that you found out that either the update package was corrupt or the Windows ME driver installation but not your ME firmware.
I wonder anyway why you didn’t use the update tools provided in the same package where you found fptw64.exe? And in the same thread where you found the tools package here in the forum there’s a link to the latest ME 11.8 firmware, too:
For CSME Consumer H D,A v11.0 - v11.8
CSME 11.8 Corporate H D,A
For CSME Corporate H D,A v11.0 - v11.8
(File folder on MEGA)
=> CSME 11.8 COR H DA v11.8.93.4323.rar
Regarding the DASH problem- first time I’ve heard of this system, seems that DASH interfaces the Intel Small Business Advantage part of the ME to execute some basic functions without having an Intel NIC onboard. Normally a complete reset should be enough to fix things.
I’d recommend to make a backup of the fiemware as shown for all machines just in case- that way you have the OEM Windows codes, serials and a working state in case something get’s corrupt in the future.
In addition I’d update to the latest ME firmware as described. Good luck!
