2012-01-26 7 views
2

Je rencontre un problème sérieux. J'ai un code C# qui charge une DLL codée en C qui appelle une DLL codée en C++. Tout va bien jusqu'à ce que je voudrais passer un pointeur d'un tableau du niveau C au niveau C++.Passer un pointeur sur une fonction dans une DLL

Le code d'appel en C est le suivant:

#include <windows.h> 
#include <winbase.h> 
#include <windef.h> 

int sendDLL(int* , int); 

typedef int (*SendFunc)(int*); 

int sendDLL(int* msg , int msgLength) 
{ 
    int status = 0; 
    SendFunc _SendFunc; 

    HINSTANCE serialLibrary = LoadLibrary("sender.dll"); 

    if (serialLibrary) 
    { 
     _SendFunc = (SendFunc)GetProcAddress(serialLibrary, "UssSend"); 
     if (_SendFunc) 
     { 
      status = _SendFunc(msg); 
     } 

     FreeLibrary(serialLibrary); 
    } 

    return status; 
} 

Maintenant, la torsion réelle est que le passage du pointeur ne suffit pas: le message qui est transmis sera écrasé dans la DLL et nous avons besoin de le lire à nouveau une fois jusqu'à ce que le _SendFunc(...) retourne.

Si je commence le programme à partir de Visual Studio (le plus haut niveau - C#), je reçois le texte suivant à droite lorsque le status = _SendFunc=(msg); est appelé (c'est sûr, si elle est commentée, aucune erreur ne se produit.)

Une exception non gérée de type 'System.AccessViolationException' s'est produite dans TestRS232.exe

Informations supplémentaires: Vous avez tenté de lire ou d'écrire une mémoire protégée. C'est souvent une indication que l'autre mémoire est corrompue.

Est-ce que cela peut être résolu?

+2

Comment 'UssSend()' connaît-il la taille du tableau pointé par 'msg'? 'serialDLL()' prend un paramètre 'msgLength' qui est (vraisemblablement) le nombre d'éléments pointés par' msg'. – hmjd

+0

Vous pouvez également être intéressé par [cet article relatif à NXCOMPAT et à DEP] (http://blogs.msdn.com/b/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx). – hmjd

+0

Probablement vous devriez nous montrer la méthode buggy plutôt que celle qui l'appelle ... – Nuffin

Répondre

0

OK, le problème est résolu, l'erreur était beaucoup plus évident que j'ai jamais pensé: la valeur de retour de la _SendFunc(...) n'a pas été int mais long, et cela a causé le message ci-dessus.

Désolé pour la question et aussi merci pour l'aide de tout le monde.

+1

Etes-vous sûr que c'était la seule raison? AFAIK à la fois int et long sont 32 bits, même sur Win64, et les deux types sont retournés dans le même registre de processeur, donc int confuse et long devrait en fait être une "erreur, vous pouvez sortir avec" sur Windows. – wolfgang

+0

Oui, je suis sûr, en corrigeant le int "status" var à long résolu, bien que je pensais le même que vous. – petermolnar

+0

Je seconde l'opinion de Wolfgang ... Passer de 'int' à' long' sous Windows ne peut pas être le solveur. Faites attention à l'inadéquation des conventions d'appel: quel est le prototype de 'UssSend'? Est-ce '__cdecl' ou' __stdcall'? –

Questions connexes