Violation d'accès lors de l'exécution d'une application C++ native utilisant une DLL intégrée/clr

Question

Je réorganise une ancienne application mixte (DLL managée et non managée) de sorte que le segment d'application principal soit un MFC non managé et appelle une DLL C++ compilée avec/drapeau clr qui établira un pont entre la communication entre les DLL managées (C# DLL) et le code non managé. Malheureusement, mes modifications ont entraîné une violation d'accès qui se produit avant que l'application InitInstance() soit appelée. Cela rend très difficile le débogage. La seule information que je reçois est la trace de pile suivante.

> 64006108() 
ntdll.dll!_ZwCreateMutant@16() + 0xc bytes 
kernel32.dll!_CreateMutexW@12() + 0x7a bytes 

Donc, voici quelques sceanrios que j'ai essayés.
- Actif sur Exceptions-> Exceptions Win32-> Violation d'accès c0000005 à casser lors de levée. Encore le plus de détails que je reçois est de la trace de la pile ci-dessus. J'ai essayé l'application avec F10, mais elle échoue avant que tous les points d'arrêt soient touchés et échoue avec la trace de pile ci-dessus. - J'ai écrasé la DLL du pont de sorte qu'elle n'a qu'une seule méthode qui renvoie un booléen et que cette méthode est codée pour renvoyer juste faux (aucun code C# appelé).

bool DllPassthrough::IsFailed() { return false; } 

Si la DLL stubbed est compilée avec l'indicateur/clr, l'application échoue. Si elle est compilée sans l'indicateur/clr, l'application s'exécute.

- J'ai créé une application MFC stub à l'aide de l'Assistant Visual Studio pour les applications multidocument et appelez DllPassthrough :: IsFailed(). Cela réussit même avec l'indicateur/clr utilisé pour compiler la DLL.

- J'ai essayé de faire une LoadLibrary manuelle sur winmm.lib comme indiqué dans la note suivante Access violation when using c++/cli. L'application échoue toujours. Donc, mes questions sont comment résoudre le problème? Des conseils, des stratégies ou des incidents antérieurs. Et, à défaut, comment puis-je obtenir plus d'informations sur quel segment de code ou quelle bibliothèque provoque l'exception d'accès? Si j'essaie des solutions de contournement plus complexes, comme les appels LoadLibrary, j'aimerais les restreindre aux bibliothèques défaillantes.

Merci. BTW, nous utilisons Visual Studio 2008 et le projet est en cours de construction contre l'infrastructure .NET 2.0 pour les sections gérées.

Answer 1

Je crois que je résous mon problème. En supprimant systématiquement chaque référence de bibliothèque et en commentant les appels à cette bibliothèque particulière dans le code de l'application (non géré), j'ai éventuellement supprimé la bibliothèque de problèmes et j'ai exécuté le programme. C'est une façon brute de diagnostiquer le problème, et heureusement je n'ai pas eu à supprimer trop de bibliothèques pour le résoudre. Je serais toujours curieux si quelqu'un a un commentaire si la bibliothèque aurait pu être identifiée par le biais du débogueur.
Ainsi, l'étape suivante consiste à déplacer ces appels de bibliothèque au code managé et à transmettre les informations au côté non géré via ma DLL de pont. BTW, j'ai réintégré winmm.lib dans le projet et cela fonctionne toujours.