That makes no sense, not possible. The full SPI image dump and the ME region dump taken from the same system without any reflashes in between should have the same ME region as far as settings are concerned. You must have confused some file with another.
No need to tag me with @username, I follow replies regardless.
sorry for the tagging.
Well, thats what I tought it should be.
if you open them, are those settings I mentioned different for you?
Because at first I was thinking I might need some glasses 
I hope I’m doing it the right way.
full spi: fptw64.exe -d full.bin
me: fptw64.exe -d me.bin -ME
that’s all I did. I ran 2 instances of fitc next to eachother and compared both the me.bin and the full.bin
unless I’m doing something wrong, I’m puzzled.
So I started over:
dumping:
the files:
opened in fitc:
full.bin to the left, me.bin to the right:
To compare settings properly, you should use the “Save” xml option in FITC as exlained at step 11 of the cleanup guide. If you typed those two commands consecutively, then there is no way to see such drastic differences. The “me.bin” file has completely different ME DATA configuration from all the other files. Restart the system and try again with “fptw -d spi.bin” and “fptw -d me.bin -me” and you should see the same values at the two xml files created by FITC.
Well, I started over and did exactly what you said. I’ve edited my previous post with clickable images.
it realy beats me.
Now I’ve did the same but with a bootable usb stuck and the dos tools. Same result 
Well this is utterly strange and first time seeing it. The system has only one SPI chip, right? First, try a "fptw -greset" and check if you see the same weirdness after the ME reset. If you do get the same strange result, dump the full SPI and then flash it back with "fptw -f full.bin" followed by a "fptw -greset". After the reset, check again.
the -greset had no effect.
I’ll try the full flash again followed by a -greset.
is there a way to check if there are multiple spi chips?
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
C:\Users\jo\Downloads\Intel ME System Tools v8 r1\Flash Programming Tool\Windows64>fptw64.exe -spibar
Intel (R) Flash Programming Tool. Version: 8.1.60.1561
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
Platform: Intel(R) Patsburg Chipset - Reserved DID 0x1D41
Reading HSFSTS register... Flash Descriptor: Valid
--- Flash Devices Found ---
EN25F64 ID:0x1C3117 Size: 8192KB (65536Kb)
SPI BAR: FED1F800
ok, so I reflashed the full dump.
I couldn’t do a -greset after. it gave an error that the me was in bring up state. So I powered the machine down.
After booting again, I get exactly the same results. so I’m realy puzzled now 
Check physically if it has two chips, although I doubt it. Even if it did, such behavior is not justified either. A manual greset can be performed by removing all power from the board for 1 minute or so. I don’t understand why that happens. It makes no sense to me.
I noticed something else as well.
If I open the original bios. Or every full spi dump in fitc, I close fitc.
I reopen fitc and open the ME Region.bin in the Decomp folder, then the ME Region.bin shows other values as the full dump as well.
wtf?
From hash checks, the ME region from the FITC folder is identical to the one I extracted manually from the original SPI image, which of course makes sense. So, the problem (if any) lies with FITC. The me region you dump with “FPT -d me.bin -me” is definitely the same as the full.bin image. Just that, for some reason, FITC interprets the “full SPI image” vs “me region only” settings in a wrong way. Might be a bug. I’ll need to do a similar test on my own Z77 system tomorrow and let you know if I see the same behavior and if yes, I’ll check if this is reproducible at older FITC. It might be C600 PCH FITC settings related only or something. Mmm, more tests are needed to pinpoint. But I believe it’s FITC. That would make sense compared to different data being dumped.
Ah, ok. I’ll wait for your result.
I was allready thinking, I was loosing my mind 
Yes, it seems like a FITC bug or FITC incompatibility. I don’t see any problem with the Z77 SKU and the me region has the same settings as the full dump at FITC. It seems to affect the Patsburg SKUs only like X79.
Intel changed the SKUs at FITC v8 multiple times which is apparent just by running older versions (even 8.1) which show slightly less or different C600 entries at FITC. Every version before the one we have (8.1.40.1456 - was part of 8.1.65.1586 firmware package) shows a missing/unknown SKU error when your PBG ME is loaded. It seems to me that 8.1.40.1456 does not show the error but is bugged and cannot actually understand the SKU which makes it restore everything to default without warning the user. You can even tell it doesn’t understand the SKU because the ME region (me.bin) image shows an empty field at FITC SKU whereas the full dump (full.bin) does not. Personally, I would trust the FITC “view” (case scenario) which has yellow entries at ICC and other places. Ironically, that case scenario is the one after loading me.bin and not full.bin. So, I believe that your actual ME settings can be seen when loading the single me region (me.bin) and not full dump (full.bin) even though FITC seems to understand the SKU at the full dump and not single me region.
Either way, FITC v8.1.40 which we currently have, is either bugged or incompatible. Incompatible would mean that there is a newer FITC version which we don’t have (for example the one that comes with packages after 8.1.65 and before 8.1.70 which seems to be the last). The image would be incompatible only if it was built with a newer than 8.1.40 FITC. From MEA, I can see that is was built with FITC v8.1.56 (newer) so maybe that’s the problem in your case.
Regarding the FITC version shown at MEA: If you used the cleanup guide at some point with FITC 8.1.40 and ME 8.1.56 from the repository, then the FITC value will be equal to the firmware your chose as a clean basis (8.1.56 in such case) and not the actual FITC tool version. It’s a small (harmless) visual side-effect of the cleanup guide. In such case, your image was not built with 8.1.56 FITC and it might not be incompatibility but just a FITC bug at the current version we have. However, I don’t think that’s the case because you shouldn’t have used the cleanup guide with firmware 8.1.56 found at the repo since it’s dirty (EXTR). Thus, I assume that the OEM actually build the firmware with FITC 8.1.56 and that version shown at MEA is not the side-effect product of the cleanup guide used wrongfully. Let me know if my assumption is wrong and you made such a mistake.
I only flashed the cleaned image you provided me, when we tought the me was not functioning anymore. We didn’t knew that the oem had disabled it in the bios.
After that I only flashed the me once. I changed 2 min and max clock values and flashed that me. ( me only)
I build that one with the latest 8.1 tools we have on the forum.
So we should be looking for a newer 8.1 toolkit?
P.s. do you have a x79 bringup guide as well?
Because the 7 series bringup guide we use, only seem to have documentation for all 7-series chipset except the x79 series.
Ok, so indeed the SPI image you have was built with a newer FITC and because 8.1.40 is bugged, we need to find a new toolkit.
I checked the PBG 8.1.40 release notes I had found and check this bug out:
So I was right. It was a bug. Problem is, I don’t think they solved it properly at 8.1.40. Removed the error but FITC still resets to default under certain circumstances.
Is there any newer version of fitc for this me, that you are aware of?
Unfortunately I don’t have a newer FITC, otherwise it would have been available at the first post. But from your own SPI image and some other samples I’ve seen, there should be at least one newer FITC version, 7.1.56.1541 which probably got released at a package later than 8.1.65 which is the one I have and the source FITC 8.1.40. Unfortunately, with the current version we have, you can’t really change settings on the C600 SKUs.
However, as I said above, the problem is at the BIOS either way. So, have you had any luck contacting the OEM and getting a solid answer and hopefully a fixed BIOS with ME enabled?
I’ve got a fixed bios now.
But next week they will modify that one to enable the me again.
However,
I wanted to fool around, to get the bclk unlocked in the intel xtu.
So I hope we can get a newer leaked fitc.
You mean fixed as far as the fan control is concerned but not ME. Do upload the one with fixed ME when they share it for anyone else with such a problem or to maybe check what’s different.
Unfortunately I wouldn’t expect much when it comes to finding a newer FITC. For the other stuff, maybe you should first try using the latest ME 8.1.65 RGN firmware and to manually transfer all settings as seen when loading the me region only at FITC 8.1.40. Should be mostly ICC values but check and transfer everything. Then reload that output image to FITC and check if the changed values are shown.
I indeed didn’t use the cleanup guide. So probably the chinese oem used the newer version.
However, I don’t get any answers from them lately. I still can’t get a hold of that version either.
Did you get any luck in the meanwhile?
No I haven’t found a newer fixed FITC v8. The CleanUp Guide has a note though which instructs PBG users to use the bare ME region and not full SPI image.
If you can contact them and possibly get a newer version out of them then great, but I highly doubt such a thing will happen even if they reply back.