5 replies to this topic

[Abystus]

Not sure if there is some way to prevent this in code on my end.  I get a "The handle is not valid" error from the DLL when not being logged into a character, or entering (and remaining in) an instance (World of Warcraft), which I did not get using my old ReadProcessMemory/WriteProcessMemory functions.  Some pics:

 

 

 

I have yet to identify where in code it is occurring as I do not receive any sort of break in code, but only the error that shows is from the dll.  Do you happen to know the cause, and possibly how it can be prevented?

 

Edit:

 

I found the origin of the error in my code (durp forgot to click "Break when this exception type is thrown"), and basically boils down to an invalid address being passed (seems this should be handled in the dll for invalid addresses on all reads/writes)?

 

Error in code is on this write:

 

 

This forces me to check each address as a precaution like the following to resolve the issue (if it occurs):

 

Could you make it just return defaults for each type of invalid read (this could be an optional flag, something like bool IgnoreErrors), and possibly just move on with no error if a write failed (invalid address) within the dll (maybe make your write methods return a boolean for success and suppress the error, again flag based)?  I would have to create a wrapper around your code for Read/Write that first checks the address (to prevent having to check it everywhere), and returns defaults for each type otherwise (I know, I know.. I should find out why the address is taking a dump to begin with, but it would be a nice feature to add on your end imo).  Any help is appreciated.

Edited by Abystus, 21 October 2013 - 09:13 AM.

[ZenLulz]

Hi Abystus,

 

This exception usually occurs when the address passed to MemorySharp is invalid. If you don't want to write all these checks, you can remove all your conditions and the exception will be caught by the try...catch statement. Else you can write your own extension methods that return the default value of the type. For example:

 

public static class MemorySharpExtensions

{

    public static T SafeRead<T>(this MemorySharp memory, IntPtr address, bool isRelative = true)

    {

        if (address == IntPtr.Zero || address.ToInt64() < memory.Modules.MainModule.BaseAddress.ToInt64())

        {

            return default(T);

        }

        return memory.Read<T>(address, isRelative);

    }

}

 

I did not provide a way to bypass the exceptions because it can be misleading if functions have different behaviors. I also chose to return void when writing data in order to standardize how the library works.

 

Cheers,

ZenLulz

[Abystus]

Hi Abystus,

 

This exception usually occurs when the address passed to MemorySharp is invalid. If you don't want to write all these checks, you can remove all your conditions and the exception will be caught by the try...catch statement. Else you can write your own extension methods that return the default value of the type. For example:

 

public static class MemorySharpExtensions

{

    public static T SafeRead<T>(this MemorySharp memory, IntPtr address, bool isRelative = true)

    {

        if (address == IntPtr.Zero || address.ToInt64() < memory.Modules.MainModule.BaseAddress.ToInt64())

        {

            return default(T);

        }

        return memory.Read<T>(address, isRelative);

    }

}

 

I did not provide a way to bypass the exceptions because it can be misleading if functions have different behaviors. I also chose to return void when writing data in order to standardize how the library works.

 

Cheers,

ZenLulz

 

Thanks for the quick reply ZenLulz.  Your "SafeRead" example seem to be the best solution (similar to what I considered creating) to this issue, and it will also allow me to do some logging on invalid addresses when they occur so I can address them.  The code up there has so many checks as I was under the impression that the dll threw an error that was not handled by the Try/Catch setup, but it may have been due to me telling Visual Studio to always break on the "ArguementException" (even when in a Try/Catch setup) initially when I posted this error.  I appreciate the example, and look forward to implementing something similar when I arrive home.  Thanks for your time, and the helpful support of your library.

Edited by Abystus, 21 October 2013 - 07:36 PM.

[Abystus]

I wanted to let you know that I was successful in implementing safe type read/write wrappers around your methods.  While testing them I noticed this line was causing a severe delay in my application's ability to read/write memory:

address.ToInt64() < memory.Modules.MainModule.BaseAddress.ToInt64()

Apparently referencing the BaseAddress through MemorySharp, or the act of converting it to Int64 causes a huge delay.  If I create my own IntPtr to house the BaseAddress when I reference the process initially before passing it to MemorySharp (already had this setup before your library), and reference it instead like the following method has then everything is speedy once again:

 

        public static T Read<T>(IntPtr address, bool isRelative = true)
        {
            try
            {
                if (address == IntPtr.Zero || address.ToInt64() < BaseAddress.ToInt64())
                    return default(T);

                return MemSharp.Read<T>(address, isRelative);
            }
            catch (Exception ex) { return default(T); }
        }

Is there some intense operation going on when your resolving the base address, or when it is converted?  I believe I remember someone saying there was a delay on retrieving the relative address (which has to reference the base address), and this may be part of that issue.  Link here:

 

http://www.ownedcore...tml#post2867864

 

You have a very nice library here.  I hope to see some optimizations here and there, but so far it's a blast to work with.  Thanks again for the tips and code examples.

Edited by Abystus, 22 October 2013 - 07:37 AM.

[ZenLulz]

Thanks for your report. You are right, RivalFr reported the issue you are encountering.

 

I'm taking at heart the optimisation of the performance of my libraries. This is why I'm currently developing BenchShark, a library to benchmark functions in .NET applications. I firstly chose to make it to improve MemorySharp speed, but it can be used with any other applications.

 

I will publish an official news when the library will be ready. 

 

Cheers,

ZenLulz

[Abystus]

Thanks for your report. You are right, RivalFr reported the issue you are encountering.

 

I'm taking at heart the optimisation of the performance of my libraries. This is why I'm currently developing BenchShark, a library to benchmark functions in .NET applications. I firstly chose to make it to improve MemorySharp speed, but it can be used with any other applications.

 

I will publish an official news when the library will be ready. 

 

Cheers,

ZenLulz

 

ZenLulz,

 

Very nice.  Hopefully that will be able to pinpoint the issues we are experiencing.   I'll have to try that app out on some of my other code to see if things can be optimized.  Thanks for sharing, and can't wait to see the updated library.

Edited by Abystus, 23 October 2013 - 08:47 PM.