Why does Intel list the 9.5.15.1730 driver for Windows 8 only, but Station Drivers has it listed for 7 as well?

Fernando,
i use on my Z77 ASUS PC MEI driver V 10.0.0.1072, and MEI firmware 8.1.51.1471 Under W7 x64 SP1.
All is working fine except when coming back from hibernation.
This MEI driver stops.
the problem was the same with any MEI previous version driver.
When reboot all is working fine again..
Do you have the same 'bug' on your side (with W 8.1) ?

Fernando,
The problem I have detected is when I put the W7 x64 PC in "sleep mode" and then awake it up and running.
The MEI driver no longer works (error code displayed in Device Control Panel) and you have to reboot the PC to get a proper MEI driver functionnal.
How do you did you 'disabled' the sleep mode ? On my PC the 'sleep mode' entry menu is always present when clicking on 'Start' icon.
Is 'disabling' the 'sleep mode' a specific feature available only on W8.1 ?

Fernando,
Thanks for your help.
Done the hibernation 'off' command as you specified.
But this does not fix the described problem.
After clicking on 'sleep' option (mettre en veille) of the W7 Start logo / Stop option, then awaking up the PC few minutes later, I always got the Error Code 43 with the MEI driver.
Not a severe problem because we have to reboot to get MEI properly again, but there is a bug somewhere.

Some interesting news. A couple of weeks ago I decided to repair that broken ME Firmware on my brother's laptop. Neither MEInfo, nor MEManuf were able to communicate with it and the device appeared not connected in device manager. I thought that the best way was to simply flash the BIOS again, to overwrite the ME Firmware.

At first I did a backup of the current BIOS, using InsydeFlash with modded platform.ini and also a second backup with FPT. The first one was fully sized, but with the original+older ME, the second one was smaller in size because of the missing ME. Should I assume that the ME is not located in the BIOS?

Next I tried the flashing with the ME=1 flag in platform.ini. Of course it gave me a "region map not found" error, leaving me even more puzzled and worried than before. I was thinking that it really was completely broken. Luckily I tried one more time MEInfo and it actually showed the version, 7.1.60.1193. Then I decided to test MEManuf: again successful test. Apparently it needed a little kick. Not sure if it was InsydeFlash or FPT, but reading the chip solved the corruption.

Since the tools posted by VirtualFred here are not compatible with 6 series chipset, I have attached the ones I have found in an older pack, version 7.1.20.1119. Only MeManuf has some interest, since it is the only version compatible with 6 series (or at least HM65). The MEInfo it is useful if you don't want that first errors which shows up with MEInfo 8.xx or 9.xx on 6 series. The only drawback is that it shows less info, so users with 6 series should run them both and decide which suits them better. Use MEManufwin -h for help, MEManufwin -verbose for full details.

Fernando, I think MEManuf would be a useful addition to this thread, for testing ME Firmware state.

Zitat

---

Should I assume that the ME is not located in the BIOS?

---

Yes. SPI chip organisation on Intel platforms is described in chipset datasheet and looks like this:

PDR region is absent on UEFI-based boards, AFAIK, but all other regions are there.

CodeRush, that was the reason of my question. Already saw your posts here, but google translate is not the best way to read such documents. Since I delayed reading this or the UEFI specs, I don't feel that comfortable coming with my lessons not learned. But since you are a truly generous fellow, here are some details.

The BIOS had 7.0.4.1197 firmware (HM65) and I upgraded to 7.1.52.1176 without problems, but the 7.1.60.1193 somehow got corrupted. Before flashing the BIOS again to revert ME, I used two methods of backup, FPT and InsydeFLash, just to preserve the unique IDs.

Intel FPT produced only a 2.5MB file, but I think that either I have used -bios flag to avoid saving the corrupted ME, or I used a 8.xx version of FPT that only worked with that flag. Not sure what was the reason and not really important since it produced the needed backup and possibly revived the corrupted ME.

But InsydeFlash produced an intriguing 4MB file. It had the original 7.0.4.1197 firmware, even though it should have been overwritten by upgrading to 7.1.52.1176 in the past and now to 7.1.60.1193. Is another chip involved or something else? I read that some motherboards have independent ME recovery.
I also used FPT with -d and -me flags after (or maybe before?) it was revived and it produced the same 7.1.60.1193 firmware that was flashed.

How can those tools produce such different results? And should the ME backup through FPT produce an exact copy of the flashed ME, even though some settings are stored dynamically in ME area?

I don't think it's another chip or something like that. Try look at descriptor region (dump it with fpt -desc -d disc.bin) at 0x60 offset, if there are something like 00 00 FF FF 00 00 FF FF 18 01 FF FF, you have read/write access to all regions, including ME, and dumping it with FPT should not be a problem, but as far as I know, laptops have locked access to ME in 99,99% of cases, so it's no wonder that FPT couldn't dump ME contents.
As far as I know, that descriptor locks are stronger then any other lock BIOS vendor can implement, so I think that InsydeFlash has a copy of ME code (stored in executable file resources as compressed section, for example) for inserting to backups it makes, because it has no access to actual data from ME region, and a backup must have some ME anyway, but it's only my thoughts. Probably, IF doesn't even tries to access ME region (because it's locked in near to all cases), and uses it's stored reference copy.
If you have done fpt -me -d me.bin and it worked, then you either have unlocked descriptor settings, or your system was somehow booted in flash override mode. In both cases, FPT will dump actual contents of all regions, with all settings and stuff.

Sadly, it's not my laptop and I don't have access to it right now, maybe in a few weeks. I think I can test your assumption by using an older BIOS package that had an earlier ME firmware, meaning that InsydeFlash too should have that older version. Just comparing the content of the packages I see they have the same CRC for all files, except the bios *.fd files. So it could really be something else.

I will also test for region locks, but doesn't MEInfo already provides this info or is it not reliable?

Thinking again, I know I dumped the ME after I revived it, for comparison, but I could have used FWUpdLcl instead of FPT. All I know for sure is that InsydeFlash saved an older ME and that FPT/FWUpdLcl dumped the new ME untouched, same checksum as the bin used for flashing, same smaller size as it is used for updating, not the full production 1,5MB ME.

Will test and report when I get the chance, if no one is complaining about adding such info to the thread.

Hi everybody,

I can successfully flash the firmware 8.1.51.1471 but after restarting my PC it automatically flashs back the original firmware 8.1.40.xxxx. Does somebody have an idea how I can prevent this?

Regards hanson

You might find th ME Firmware is backed up in the BIOS firmware in which case you may need to update that instead.