none
C# Interop: Access violation with c++ long RRS feed

  • Question

  • Hi

    I am attempting to send data to an external DLL.  I have several entry points working but I am stuck on one.  The documentation for the DLL shows the following:

    int __stdcall __declspec(dllexport) StartHW(long freq)

    So, I define a dll import as follows

            [DllImport("externalDLL.dll", CallingConvention = CallingConvention.StdCall)]
            public  static extern int StartHW(int freq);

    The calling convention is correct.  Now I understand that a C++ long (as in the documentation) is an Int32 in C# so that is why I put an int.

    Now the code in the C# program does the following:

                    int result;
                    result = StartHW(7000000);

    and I get a unhandled exception: system access violation.

    Does anyone have any ideas what I am doing wrong?

    Thanks, Tom

    Monday, September 24, 2018 3:01 AM

All replies

  • You should make clear what's the bitness of client and server.

    Monday, September 24, 2018 4:27 AM
  • Hello tomb1818,

    1. The problem may not be connected with the bitness of the "freq" parameter.

    2. The system access violation exception may be due to problematic code inside the StartHW() code itself.

    3. To test that your StartHW() API is OK with the parameter type, you can try the following :

    - Create your own externalDLL.dll and define a StartHW() API.

    - Make the StartHW() function trivial and devoid of any possibility of error, e.g. :

    __declspec(dllexport) int __stdcall StartHW(long freq)
    {
    	return 0;
    }
     

    4. Work on from there. Maybe return the value of "freq" itself from StartHW() and see what happens.

    - Bio.


    Please visit my blog : http://limbioliong.wordpress.com/

    Monday, September 24, 2018 10:52 AM
  • My running theory is that there isn't anything inherently wrong with your call. Most likely you're just sending bad data to the function and it is failing the call. Do you have access to the StartHW code? 

    The list of reasons a native call can fail is long. I'd go back to the documentation to see what it says. You might also try just writing a simple C++ app to call the same function and see if it fails. If it does then the issue is with the call itself and not necessarily your C# interop to it. Perhaps it requires some init function be called first. Maybe the value itself is invalid for the library. Without more information about the library we're not really going to be able to help you too much.


    Michael Taylor http://www.michaeltaylorp3.net

    Monday, September 24, 2018 2:23 PM
    Moderator
  • Hi,

    I've tried numerous values.  I've tried Int64 etc.  All of them return the same with an access violation.

    Monday, September 24, 2018 3:29 PM
  • Hi,

    No, the dll works with other software from other developers. The function StartHW is necessary for the device to start working.

    Tom

    Monday, September 24, 2018 3:30 PM
  • Hi,

    I've tried numerous values.  I've tried Int64 etc.  All of them return the same with an access violation.

    You didn't answer my question; for me it's clear you have client and server that differ in bitness, probably, client/64 and server/32.

    Monday, September 24, 2018 8:45 PM
  • I'm running a 32 bit application, accessing a 32 bit DLL.
    Monday, September 24, 2018 8:52 PM
  • Hi,

    Based on your description, I create a simple C++ interop demo below, which works as expect.

    #MyDll.cpp

    // MyDll.cpp : Defines the exported functions for the DLL application.
    //
    
    #include "stdafx.h"
    
    
    extern "C" __declspec(dllexport)
    
    int StartHW(long freq)
    {
    	return 15;
    }

    #Related project property settings.

    1. 

    2. 

    #Usage:

    class Program
        {
            const string DLLPath = @"D:\Project\VCS\VCSSample\Debug\MyDll.dll";
            [DllImport(DLLPath, EntryPoint = "StartHW", CallingConvention = CallingConvention.Cdecl)]
            public static extern int StartHW(int afreq);
    
            static void Main(string[] args)
            {
                int result;
                result = StartHW(7000000);
    
                Console.WriteLine("result:" + result);
    
                Console.ReadKey();
            }
        }

    #Result.

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, September 25, 2018 7:42 AM
    Moderator
  • Hi,

    Yes this works.  I've come to the conclusion that I am doing everything right however, the creator of the DLL is doing something unknown to me.

    A bit of background:  The DLL is called an EXTIO dll which is provided by creators of Software Defined Radios (SDR).  There are several software products out there that can connect to these DLL's.

    My software can connect and consume data from two other SDR's but not the one abover.  It fails on the above code.  However, and this is weird, these other products can connect and work.  So I have no idea what I am doing wrong but this is the first time I have tried to interface with these DLL's.
    Best regards, Tom

    Wednesday, September 26, 2018 8:29 PM
  • Hi tomb1818,

    I am not sure why other application can works, what language the other application using and how to call the dll. 

    In addition, Maybe you could consider a C++ Com component, which could support multiple language. here is a sample for your reference.

    https://www.codeproject.com/Articles/338268/COM-in-C 

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Friday, September 28, 2018 1:44 AM
    Moderator