AccessViolationException error when trying to interface with third party dll

voltzart

Member
Joined
Dec 28, 2011
Messages
11
Programming Experience
1-3
The error message that I've been getting for the past few months when trying to access functions of a specific third-party .dll using vb.net is this: "An unhandled exception of type 'System.AccessViolationException' occurred in test.exe Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

I've been researching this error message, and I have come to know that it is likely due to either attempting to access memory that isn't available or due to "enhanced" security features.

I am trying to access a third party .dll. The functions in that .dll all deal in one way or another with Handle types (either returning them or accepting them as parameters). I understand that handle's can be essentially pointers to pointers (pointing to an entry in a memory table, which is itself a pointer), and I also understand that handle's don't, strictly speaking, exist in the .NET framework, but I do understand that through some combination of IntPtr's and possibly the Marshal class, they can be dealt with.

I don't believe vb.net's lack of a Handle type is the problem, because the dll function that I am calling, which on success returns a handle, returns a number <= 0 if the ip address it is searching for is not found, and the ip I specified doesn't exist. Also, the error really only occurs when executing the code from within the the Visual Studio environment. I compiled the executable and ran it 77 times(literally), and I only got the error on the 77th try.

I'm trying to find out all I can about this error. I would like to completely eliminate it. Could the error come as a result of something happening within the dll itself? The function asks for an ip address, and the ip address I have specified doesn't currently exist on the network, but as far as I know, the function handles that by returning a number less than or equal to zero. I am very confused as to what the problem could be. I have successfully interfaced with .dll's before. I've read about the hotfix for .NET 2.0 regarding this error message, but I'm a little skeptical. I've tried everything else I can think of, though, so I may give that a shot.

I'm 100% certain that:
-I am calling the correct function within the .dll
-I am using a signature that matches the signature of the function
-The error has nothing to do with User Account Control.


The code is very simple to try to isolate the issue:

VB.NET:
Imports System.Runtime.InteropServices

Module test
    <DllImport("3rdparty.dll", EntryPoint:="#12")> _
    Function OpenSession(ByVal ip As String, ByVal port As Integer,  ByVal username As String, ByVal password As String) As Integer

    End Function

    Sub Main()
        Try
            Console.WriteLine(OpenSession("127.0.0.1", 19800, "player", "player"))
        Catch ex As Exception
            Console.WriteLine(ex.Message)
        End Try
        Console.ReadLine()
    End Sub
End Module
 
VB.NET:
HANDLE netagentopen(const char *szHost,int nPort,const char *szUser,const char *szPass);

The function call seems to work most of the time when I run the release executable, but it has never worked when trying to debug the code within Visual Studio. I'll have to do more testing to see what the extent of its functionality is when running the executable. On failure it is supposed to return empty, according to the notes, which I assume means NULL (or Nothing in VB).
 
IntPtr said:
A platform-specific type that is used to represent a pointer or a handle.
The IntPtr type is designed to be an integer whose size is platform-specific. That is, an instance of this type is expected to be 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit hardware and operating systems.
So return type should be IntPtr to be safe and future proof, it is only guaranteed to be Integer on 32bit platform, on 64bit a handle address may or may not fit integer range.
Apart from that AccessViolationException could also mean any other problem with memory handling in unmanaged code, which could happen only when certain conditions are met.
 
Yes I do. Quick clarification: The program runs when in the VS environment when I Start Without Debugging(CTRL + F5). Does this mean anything?
 
So return type should be IntPtr to be safe and future proof, it is only guaranteed to be Integer on 32bit platform, on 64bit a handle address may or may not fit integer range.
Apart from that AccessViolationException could also mean any other problem with memory handling in unmanaged code, which could happen only when certain conditions are met.

I had been changing that return type to and from various things, including IntPtr, to see if it had any effect. It didn't. It is back to IntPtr now, with the same results. Could you elaborate on the second part, the any other problem with memory handling in unmanaged code, which could only happen when certain conditions are met part? Is it possible that the problem could lie within the dll itself? That's what I was thinking, but a third party "test program" type of thing was provided with the .dll, and it works just fine. I deleted the .dll from the test program directory just to see what would happen, and it will not work without that .dll. So I'm pretty sure the test program is successfully using the .dll.
 
Is it possible that the problem could lie within the dll itself?
Of course, if it does something wrong memory wise you get AccessViolationException. AccessViolationException is not possible in managed code alone, but can happen within the unmanaged code or by the marshaling (for example wrong platform invoke signatures), this is described in its help page, see AccessViolationException Class.
 
Update: I have learned that the .dll in the directory for the third party program is does not have the same function list as the one I was meant to use, and that I must have at some point replaced the one I was supposed to use with the one that the third party program was using, assuming that they were one and the same. At the same time I was viewing the exported functions for the .dll I was supposed to be using, so I was accessing the wrong function. I am now using the correct .dll.


That said, I have a new error:



An unhandled exception of type 'System.DllNotFoundException' occurred in test.exe

Additional information: Unable to load DLL '3rdparty.dll': The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. (Exception from HRESULT: 0x800736B1)




I ran sxstrace.exe and got the following log file:

VB.NET:
=================
Begin Activation Context Generation.
Input Parameter:
    Flags = 0
    ProcessorArchitecture = Wow32
    CultureFallBacks = en-US;en
    ManifestPath = C:\testpath\bin\Debug\3rdparty.dll
    AssemblyDirectory = C:\testpath\bin\Debug\
    Application Config File = 
-----------------
INFO: Parsing Manifest File C:\testpath\bin\Debug\3rdparty.dll.
    INFO: Manifest Definition Identity is (null).
    INFO: Reference: Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
INFO: Resolving reference Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
    INFO: Resolving reference for ProcessorArchitecture WOW64.
        INFO: Resolving reference for culture Neutral.
            INFO: Applying Binding Policy.
                INFO: No publisher policy found.
                INFO: No binding policy redirect found.
            INFO: Begin assembly probing.
                INFO: Did not find the assembly in WinSxS.
                INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
                INFO: Did not find manifest for culture Neutral.
            INFO: End assembly probing.
    INFO: Resolving reference for ProcessorArchitecture x86.
        INFO: Resolving reference for culture Neutral.
            INFO: Applying Binding Policy.
                INFO: No publisher policy found.
                INFO: No binding policy redirect found.
            INFO: Begin assembly probing.
                INFO: Did not find the assembly in WinSxS.
                INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
                INFO: Attempt to probe manifest at C:\testpath\bin\Debug\Microsoft.VC90.DebugCRT.DLL.
                INFO: Attempt to probe manifest at C:\testpath\bin\Debug\Microsoft.VC90.DebugCRT.MANIFEST.
                INFO: Attempt to probe manifest at C:\testpath\bin\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.
                INFO: Attempt to probe manifest at C:\testpath\bin\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.
                INFO: Did not find manifest for culture Neutral.
            INFO: End assembly probing.
    ERROR: Cannot resolve reference Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.
End Activation Context Generation.




This is getting very complicated.
 
Back
Top