2010-01-21 5 views
0

Je travaille sur un projet écrit en C# et utilise une DLL C++ pour communiquer avec un robot. À l'origine, le logiciel a été écrit en C# VS 2003 et a été converti en VS 2008 (pas de changement au code) en utilisant .Net 2.0. Maintenant, j'ai commencé à voir le "Tentative de lire ou d'écrire de la mémoire protégée ..." sur certains ordinateurs. L'erreur de violation d'accès est toujours levée lorsque le code appelle une méthode particulière de la DLL, cependant, cette même méthode est appelée encore et encore tout au long de la tâche et s'exécute correctement, mais parfois elle renvoie l'erreur. De plus, le robot semble bien exécuter la commande qui me dit que les valeurs passées dans la DLL existent et sont donc accessibles.AccessViolationException thrown

Le logiciel avec le .Net 1.1 a été utilisé pendant des années et a fonctionné correctement sans jamais jeter des erreurs de mémoire. Maintenant qu'il utilise .Net 2.0, il ne génère des erreurs que sur certains ordinateurs.

Je ne suis pas sûr de ce qui cause le problème. J'ai exclu l'appel inapproprié (malformation marshalling ...) des méthodes dll car il a fonctionné très bien avec .Net 1.1 pendant des années et devrait donc bien fonctionner dans .Net 2.0 ainsi. J'ai vu quelques messages suggérant que cela pourrait être le GC, mais encore une fois pourquoi cela ne se produirait que sur cet ordinateur et seulement parfois. De plus, les valeurs passées sont toutes des variables globales dans le code C# et doivent donc exister jusqu'à ce que l'application soit fermée et que GC n'ait aucune activité pour déplacer ou supprimer les applications. Une autre observation, comme je l'ai mentionné plus haut, le robot exécute la commande normalement ce qui signifie qu'il obtient toutes ses valeurs nécessaires. Je ne suis pas sûr de ce que la méthode de la DLL de C++ ferait à la fin où le GC pourrait gâcher des choses. Il ne devrait pas essayer de supprimer les variables globales passées et la méthode ne les modifie pas non plus (je n'attends aucune valeur de retour à travers les valeurs passées, la seule valeur de retour est la méthode return qui ne devrait pas avoir quelque chose à voir avec GC.)

Une information importante que je devrais ajouter est que je n'ai pas accès au code C++ et que je ne peux y apporter aucune modification.

Le correctif doit provenir du code C# ou de certains paramètres de l'ordinateur ou de tout autre élément dont je suis responsable. Toute aide grandement appréciée. Merci.

extrait de code: appel de méthode originale en VS 2003

[DllImport("TOOLB32.dll",EntryPoint="TbxMoveWash")] 
public static extern int TbxMoveWash(int tArmId, string lpszCarrierRackId, 
           int eZSelect, int[] lpTipSet, int tVol, bool bFastW); 

que je modifié après avoir vu l'erreur à ce qui suit (mais l'erreur se produit encore):

[DllImport("TOOLB32.dll",EntryPoint="TbxMoveWash")] 
public static extern int TbxMoveWash(int tArmId, string lpszCarrierRackId, 
           int eZSelect, [MarshalAs(UnmanagedType.LPArray, SizeConst = 8)] int[] lpTipSet, int tVol, bool bFastW); 
+0

Il serait bon de voir ce que fait le code C++ avec ces paramètres. Même si nous ne pouvons pas les changer, il serait utile de savoir exactement ce qui ne va pas. –

+0

Vous ne savez pas exactement ce que vous demandez. Comme je l'ai dit, je n'ai pas le code C++. Un dll que je ne peux pas refactoriser non plus. – user255371

Répondre

0

Il est possible que la C++ DLL est en train de jeter une violation d'accès, donc le problème n'est pas du tout .NET. Pouvez-vous arrêter lorsque l'exception se produit, capturer l'entrée et essayer de reproduire le problème à partir du code non managé?

Si vous êtes sûr qu'il est dans le marshalling: les ints sont assez sûrs, donc il y a deux suspects - la chaîne et les paramètres de tableau. Si vous ne voulez pas recevoir de données, je marquerais les deux avec l'attribut [In], ainsi .NET n'essaye même pas de remonter les données. Le SizeConst devient alors non pertinent.

Si cela ne résout pas, essayez de spécifier [MarshalAs] pour la chaîne, une fois que vous (d'une manière ou d'une autre) découvrez le type de chaîne attendue par la DLL C++. Aussi, est-ce ANSI ou Unicode? Vous pouvez spécifier le CharSet dans le [DllImport].

Il est également possible que ce soit un bug dans le .NET CLR (qui a été introduit dans la version 2.0). Le problème se produit-il lorsque l'optimisation est désactivée (version de débogage)?

+0

Je ne peux rien faire avec le code C++ non géré. C'est une DLL à 3 parties que je n'ai pas accès à quoi que ce soit (pas d'accès à son code source). Aussi, je ne pense pas que ce soit le marais, comme le marais. devrait être indépendant de la version .Net et donc si cela a bien fonctionné dans 1.1 pendant des années cela fonctionnera bien dans 2.0. De plus, l'appel de méthode fonctionne la plupart du temps. Alors, marais. est hors de question, sauf que quelque chose de vraiment génial s'y passe. Je n'ai pas exécuté de build de débogage, mais j'ai décoché l'optimisation du code et construit le code sur une plate-forme cible spécifique avec les mêmes résultats (erreurs lancées.) Merci. – user255371

Questions connexes