1.2.15 works perfectly, 1.2.16 Unrecognized configuration section, 1.2.17 no error but all values 0 about memory.dll HOT 7 CLOSED

I see the same error when run in x64. Try to run probject on any CPU will fix my problem.

from memory.dll.

Did you adjust the target framework?

from memory.dll.

This version add Aob Signature scan. It have to run on 4.7.1 NET Framework or higher (4.7.2)

from memory.dll.

Thanks for your replies. Yes running "Any CPU" already and .NET framework version is targeted correctly (I used 4.5 with 1.2.15 but am forced to bump up to 4.7.1 or 4.7.2 when using the new version). I tested using an older version of Memory.dll with the latest .NET framework version and it worked great.

I managed to solve it:

I created a whole new project with the latest .NET version just to test and same issue. I notice however in the debugger that when it isn't working the mLib library has 0 modules and no pHandle so it's not even able to hook into the exe.

I've gone through the commits binary search styles and compiled each and tested and found the issue starts occurring with this commit: bc9a557

The refactoring of this method screwed up how I hook into the process using this code

  int gameProcId = mLib.getProcIDFromName("myexe.exe");

  if (gameProcId != 0)
  {
         mLib.OpenProcess(gameProcId.ToString());
  }

The tooltip for OpenProcess for both 1.2.15 and 1.2.17 says it accepts either a process name or a process ID and that worked in 1.2.15 but if you look at the source for 1.2.17 it's clear it only is checking process names so with the process ID it fails to open.

Why I go about loading in that odd way you may wonder and which also leads to a second bug is because I recall it's due to the fact OpenProcess would return false for me despite the hook working so I had to first check for ProcessID instead. I delved deeper and it seems the error I got with 1.2.16 is infact related to this. After debugging I found what was happening is that the first time Debug.WriteLine was called (these are scattered around in Memory.dll) it would cause that nasty "Unrecongized configuration section" exception, but the subsequent times Debug.WriteLine is called it works fine. You can see with 1.2.16 the exception is uncaught when hitting Debug.WriteLine for the first time:

In 1.2.16 that happened in the code above where the exception was unhandled so I saw it but with 1.2.17 it was caught so everything looked okay apart from the 0 values. In OpenProcess the very last call is a Debug.WriteLine method to say it successfully hooked, that would cause that exception and the method would return false even though it loaded properly and therefore the need for the round about code I shared above.

I tried messing around with app.config and that exception managed to morph into "Configuration system failed to initialize" but I couldn't get rid of it. Again it's only the first Debug.WriteLine that causes this, and if that's caught after that it works fine. The issue also occurs when using Debug.WriteLine in my own application so it's not to do with Memory.dll I assume it's just some strange thing with how .NET is installed on this machine or something.

So to sum up fixing GetProcess to actually allow loading from processId would be great as that was the main cause of the issue. Thanks for your time.

from memory.dll.

If you would use the process ID as an integer rather than string yes it would open it

Yes it looks like the XML comments do not match the defined behavior the string overload should only take process name not process ID anymore.

Change your code to either use the process name or get rid of the .ToString() on the integer.
mLib.OpenProcess("myexe.exe");
or
mLib.OpenProcess(gameProcId);

The string overload for OpenProcess takes the name and gets the process ID from the name then calls the overload that just takes an integer (the process ID)

That Exception your getting in regards to Debug.WriteLine I would check your applications app.config for the section its asking Also make sure your running the application as Administrator.

from memory.dll.

This code part work for me:

using Memory;
Mem MemLib = new Mem();

MemLib.OpenProcess(MyGameProcess.Id);
MemLib.readFloat("0x123456");

"0x123456" is in STRING

from memory.dll.

If you have questions on how a function works, ask in our Discord.

from memory.dll.