none
Managend Unmanged code with a pointer as Argument RRS feed

  • Question

  • Hello I've a C DLL that has this export for it's open function

    FT_STATUS  FT_Open(  int deviceNumber,    FT_HANDLE *pHandle  );

    Where FT_HANLDE is typedef PVOID FT_HANDLE;

    and FT_STATUS is typedef ULONG FT_STATUS;

    In C# I've got  the below code, but I get an access violation, so something is wrong.  

    Any ideas?  Thanks

            [DllImportAttribute(theDll, CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Auto, EntryPoint = "FT_Open")]
            public static extern UInt32 FT_Open(uint num, IntPtr ptr);
    
    
            static void Main(string[] args)
            {
                try
                {
                    System.IntPtr mypointer = new IntPtr();
                    UInt32 rtn = FT_Open(0, mypointer);
                }
                catch (Exception ex )
                {
    
                    string msg = ex.Message;
                }

    Friday, March 3, 2017 8:13 PM

Answers

  • I think that the handle is an "out" parameter.  It's accepting a pointer to the handle, whereas you just passed in a brand new null pointer by value.

    You want:

    FT_Open(uint num, out IntPtr handle);

    And just in case...are you sure about that Cdecl calling convention?  stdcall is more common in my experience.


    Friday, March 3, 2017 8:49 PM
  • Accces violation exceptions are usually one of the following issues:

    - you are using unmanaged code and somebody of course messed up the pointer arythmetic.

    - damage to RAM or the binary data on the disk

    - trying to run native x32 code from a x64 application or vice versa. A Binarity missmatch.

    - 3rd party intereference. Two years ago we had issues with a version of AVG disrupting every other programm using WinForms.dll.

    Personally I would guess for a binarity missmatch. The same compiled MSIL can run as either x32 or x64 application. And even x16 and x128, if we ever get a runtime for that.
    Native code runs exactly in one binarity. if binarity of caller and dll do not match, you get issues.
    Your options are:
    Fix the binary your MSIL runs at to match the native DLL (propably x32 only).
    Use a x32 helper process to host the dll and use Inter Process Communication.
    Make a x32 wrapper that makes it COM visible.


    Remember to mark helpfull answers as helpfull and close threads by marking answers.

    Saturday, March 4, 2017 7:17 PM

All replies

  • I think that the handle is an "out" parameter.  It's accepting a pointer to the handle, whereas you just passed in a brand new null pointer by value.

    You want:

    FT_Open(uint num, out IntPtr handle);

    And just in case...are you sure about that Cdecl calling convention?  stdcall is more common in my experience.


    Friday, March 3, 2017 8:49 PM
  • Accces violation exceptions are usually one of the following issues:

    - you are using unmanaged code and somebody of course messed up the pointer arythmetic.

    - damage to RAM or the binary data on the disk

    - trying to run native x32 code from a x64 application or vice versa. A Binarity missmatch.

    - 3rd party intereference. Two years ago we had issues with a version of AVG disrupting every other programm using WinForms.dll.

    Personally I would guess for a binarity missmatch. The same compiled MSIL can run as either x32 or x64 application. And even x16 and x128, if we ever get a runtime for that.
    Native code runs exactly in one binarity. if binarity of caller and dll do not match, you get issues.
    Your options are:
    Fix the binary your MSIL runs at to match the native DLL (propably x32 only).
    Use a x32 helper process to host the dll and use Inter Process Communication.
    Make a x32 wrapper that makes it COM visible.


    Remember to mark helpfull answers as helpfull and close threads by marking answers.

    Saturday, March 4, 2017 7:17 PM