Reasons why it may not work

[glpnk]

Hi @ThePBone thanks for your work. If you interested in this findings - feel free to repost this to readme.

On some devices this program could not work.
This program use MSIWMIACPI2.dll which dumps EC content from ACPI via WMI. On some devices EC dump not exposed to WMI, so this library just return reading error in log. Changing versions of this dll does nothing. Original MSI tuning programs could use some other way of editing EC or direct WMI command for each feature.

In my case MSI-WMI not support commands Get_Data, Get_WMI, Get_EC, so it useless. It will be great to find another more universal method for reading. After testing other get methods, anyone is not return data.

Also I found how to make it work on AMD, it requires installed MSI NBFoundation Service\MSIAPService.exe and NamedPipeClientLib.dll

[greg-weber]

Interesting. I used RW everything and had to turn off Windows Security -> Device Security -> Core Isolation -> All options like Memory integrity and Microsoft Vulnerable Drivers Blocklist to have it function. It is a really crazy access everything on your system program. A bit overkill, but lets you directly modify the EC. It has a nice compare feature to see what changes. EC has lots of realtime data that changes a lot though. Realtime temps and fans.

Thanks for developers of MsiEdRamEditor. Another possible tool to look at EC.

[glpnk]

@greg-weber Basically you should never use Direct Memory Access (except test reasons) for security and system stability reasons, which Microsoft is enforcing with their antivirus. But some device drivers and apps can give you access to system memory while being totally legit. RW Everything loads kernel driver to read data from system. From userspace similar might be accomplished by using WMI calls on "WMI2"/"2 gen" MSI devices only. But on "WMI1"/"1 gen" devices not all EC addresses are mapped to WMI-ACPI space. For this reason, MSI used "backdoor" (https://www.reddit.com/r/MSILaptops/comments/n1pthe/question_what_is_checkbackdoor/) which use kernel level driver to access EC memory by address in System memory space. Then this memory is accessed by App through driver and Windows services. Address seems to be same on both generations.

[greg-weber]

@greg-weber Basically you should never use Direct Memory Access (except test reasons) for security and system stability reasons, which Microsoft is enforcing with their antivirus. But some device drivers and apps can give you access to system memory while being totally legit. RW Everything loads kernel driver to read data from system. From userspace similar might be accomplished by using WMI calls on "WMI2"/"2 gen" MSI devices only. But on "WMI1"/"1 gen" devices not all EC addresses are mapped to WMI-ACPI space. For this reason, MSI used "backdoor" (https://www.reddit.com/r/MSILaptops/comments/n1pthe/question_what_is_checkbackdoor/) which use kernel level driver to access EC memory by address in System memory space. Then this memory is accessed by App through driver and Windows services. Address seems to be same on both generations.

Thank you for your detailed response and warning. I agree DMA is best avoided. Certain things like test or perhaps debug are few times it can make sense to use.

[glpnk]

Main problem that not all things are mapped to WMI space (like battery limit on gen 1 devices), and on gen 2 devices they made "legit" DMA via WMI calls. But other manufacturers did more sketchy things in their drivers, which give you unlimited access to all system memory, so access limited to EC is not the worst solution.