Discussion :

[Damzz]

Bonjour,

J'ai créé une dll en C# (.NET 2.0 et 3.5) qui fait appel à des méthodes venant d'une librairie développée en C/C++.

Cette dernière est utilisée pour échanger des données à travers le web.

J'ai rendu la dll visible pour pouvoir l'instancier en VB6.

Lors de l'utilisation d'une des méthodes de la librairie, j'ai le message suivant:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Le problème se produit sous Vista

J'ai testé toute une série de choses:

• Ajout de la balise [SecurityPermission(SecurityAction.Assert, Unrestricted = true)]
• Supprimé toutes les optimisations de compilation
• Passé d'une version .NET 2 à 3.5

Voilà le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
/// <summary>
        /// Retourne le nom du fichier réponse
        /// </summary>
        /// <param name="hdleConnection"></param>
        /// <returns></returns>
        [DllImport("Module.dll", EntryPoint = "getResponse")]
        [SecurityPermission(SecurityAction.Assert, Unrestricted = true)]
        private static extern string getResponse(IntPtr hdleConnection);

Existerait-il une bonne âme qui a déjà eu le même problème et qui aurait trouvé une solution, ou qui aurait un tuyau (ou plusieurs), une direction à me donner?

Merci pour votre aide.


Damzz

[tomlev]

C'est un Vista 32 ou 64 bits ?

Si c'est 64, peut-être que ta DLL est compilée en 32 bits, et que ton programme tourne en 64. Pour forcer ton programme à s'exécuter en 32 bits : dans l'onglet "Générer" des propriétés du projet, mets l'option "Plate-forme cible" à "x86"

[Damzz]

C'est un Vista 32 ou 64 bits ?

Si c'est 64, peut-être que ta DLL est compilée en 32 bits, et que ton programme tourne en 64. Pour forcer ton programme à s'exécuter en 32 bits : dans l'onglet "Générer" des propriétés du projet, mets l'option "Plate-forme cible" à "x86"

Bonjour,

Il s'agit bien d'un Vista 32 bits, mais le projet était compilé en "Any configuration". J'ai recompilé en créant une plateforme x86, mais le souci est toujours là.

[tomlev]

OK...

Tu es sûr que la signature de la méthode correspond bien au prototype C++ ?
Comment initialises-tu le pointeur que tu passes en paramètre à la méthode ?

[Damzz]

OK...

Tu es sûr que la signature de la méthode correspond bien au prototype C++ ?
Comment initialises-tu le pointeur que tu passes en paramètre à la méthode ?

Oui, je sous XP cela fonctionne.

Voilà la ligne qui exécute la méthode extraite avec les déclarations:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Private IntPtr _ConnectionHandle;
(...)
_ConnectionHandle = BeginSession();
(...)
 
String response = getResponse(_ConnectionHandle);
(...)

[tomlev]

et en debug, tu as vérifié que le _ConnectionHandle récupéré n'est pas null (IntPtr.Zero) ?

[Damzz]

et en debug, tu as vérifié que le _ConnectionHandle récupéré n'est pas null (IntPtr.Zero) ?

Le test est déjà fait préalablement pour voir si la connexion est bien établie. J'ai quand même fait le test et... c'est le même message.

[smyley]

Si c'est 64, peut-être que ta DLL est compilée en 32 bits, et que ton programme tourne en 64. Pour forcer ton programme à s'exécuter en 32 bits : dans l'onglet "Générer" des propriétés du projet, mets l'option "Plate-forme cible" à "x86"

Quand c'est un problème du genre il me semble que ça génère un crash avec une histoire d'image invalide ...

Ceci dit le "String response = cis_getResponseDocument(_ConnectionHandle);" me fait bizarre (une fonction en C++ qui retourne un pointeur vers une chaine et qui marche ? ).
Si tu essayes de faire les mêmes opérations directement en C++ ça fait quoi ?
Tu as accès aux sources de la dll ?

[tomlev]

Quand c'est un problème du genre il me semble que ça génère un crash avec une histoire d'image invalide ...

Ah oui, exact...

Ceci dit le "String response = cis_getResponseDocument(_ConnectionHandle);" me fait bizarre (une fonction en C++ qui retourne un pointeur vers une chaine et qui marche ? ).

Il me semble que c'est géré par le marshalling... d'ailleurs le programme Damzz fonctionne sous XP apparemment

[Damzz]

Ah oui, exact...


Il me semble que c'est géré par le marshalling... d'ailleurs le programme Damzz fonctionne sous XP apparemment

Tout à fait, c'est uniquement sous Vista.

[smyley]

Tout à fait, c'est uniquement sous Vista.

Si tu essayes de faire les mêmes opérations directement en C++ ça fait quoi ?
Tu as accès aux sources de la dll ?

[Damzz]

Pour info, j'ai contacté les concepteurs de la méthode,... ils ont constatés le problème et ils recherchent une solution.

Solution -ou explication- que je vous ferai parvenir...

[Damzz]

Pour ceux que cela intéresse.

J'ai finalement trouvé un workaround.
La dll était écrite en C pour être utilisée dans des applications en C. Et renvoyer une chaine, est un peu limite.

Dès lors, j'ai modifié l'import pour que le retour soit utilisé avec le type IntPtr, (qui représente un pointeur) et le Marshal pour en faire ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
/// <summary>
        /// Retourne le nom du fichier réponse
        /// </summary>
        /// <param name="hdleConnection"></param>
        /// <returns></returns>
        [DllImport("Module.dll", EntryPoint = "getResponse")]
        [SecurityPermission(SecurityAction.Assert, Unrestricted = true)]
        private static extern IntPtr getResponse(IntPtr hdleConnection);
 
(...)
 
IntPtr hRespo = getResponse(_connectionHandle)
string sRespo = Marshal.PtrToStringAnsi(hRespo);

Et voilà