1

J'écris cette bibliothèque qui implémente certaines fonctionnalités de base du lecteur audio en C++/CLI via le framework Media Foundation qui sera consommé par le code managé. Je peux jouer de l'audio, arrêter, mettre en pause, etc. Pour tous ceux qui ne connaissent pas Media Foundation, la session média publie des événements que vous pouvez gérer pour les notifications. Cela est effectué en appelant BeginGetEvent sur l'objet de session avec un objet IMFAsyncCallback. Le IMFAsyncCallback définit la méthode Invoke (IMFAsyncResult) que vous devez implémenter pour gérer les événements. Lorsqu'un événement se produit, la méthode invoke est appelée par l'objet session sur un thread de travail avec un objet IMFAsyncResult que vous pouvez interroger pour les informations sur l'événement. Cet objet résultat est créé et appartenant au thread d'événement.System.AccessViolationException du code non managé?

Dans mon implémentation de Invoke, chaque fois que j'essaie de faire quoi que ce soit (y compris l'appel de QueryInterface ou quelque chose) avec l'objet IMFAsyncResult que je suis passé, j'obtiens une System.AccessViolationException. L'objet que j'implémente IMFAsyncCallback est une classe C++ de base (non gérée) allouée sur le tas CRT et les événements sont postés sur un thread appartenant à l'objet session également affecté au tas CRT.

  1. Quelle pourrait être la cause de cette exception? Pourquoi est-ce que j'obtiens une exception gérée .NET à partir du code qui est implémenté dans le vieux C++? Est-ce exactement ce qui se passe quand vous avez un assemblage en mode mixte?

Répondre

6

Capture a crash dump, puis le charger dans VS 2010 ou WinDbg pour l'analyse, et tout sera révélé. VS 2010 sera plus facile, mais WinDbg pourrait être plus efficace.

Depuis l'utilisation WinDbg est l'option plus compliquée que je vais élaborer sur ce (choisir les versions 32 bits ou 64 bits des éléments suivants en fonction de votre plate-forme cible):

  • Téléchargez et installez Debugging Tools for Windows
  • Configurer les symboles de débogage pour le Microsoft Symbol Server

    .sympath srv*<SymbolCacheDir>*http://msdl.microsoft.com/download/symbols

  • charge t il crash fichier de vidage dans WinDbg (Fichier-> Ouvrir Crash Dump ...)

  • symboles de débogage Configurer pour vos modules

    .sympath+ <PrivatePdbDir>

  • charge SOS extensions dans WinDbg

    .loadby sos mscorwks; * fw 2-3.5

    ou

    .loadby sos clr; * fw 4

  • Téléchargez, extrait et charge SOSEX extensions dans WinDbg

    .load <Sosex32or64Dir>\sosex

  • Let WinDBg faire l'analyse

    !analyze -v

  • Utilisez SOSEX pour afficher la pile de thread courant (y compris les cadres gérés et non gérés)

    !mk

Cela répondra probablement à vos questions.

1

Cela ressemble à un repro facile de ceci - vous devriez pouvoir déboguer le problème en attachant le débogueur pendant que le programme fonctionne et en permettant à la violation d'accès d'être piégée à l'endroit où elle se produit. Souvent, les bibliothèques l'enveloppent et le font apparaître comme un autre type, et le site d'origine de l'exception n'est pas apparent.

Pour vous connecter à votre processus à partir de Visual Studio, voir here. Lorsque vous vous connectez à votre processus malveillant, veillez à sélectionner les options permettant de déboguer le code natif et géré. Assurez-vous que les symboles de vos assemblys et DLL sont disponibles dans le Symbol path, dans la mesure du possible (certains peuvent ne pas être disponibles s'il s'agit d'un code tiers).

Pour modifier la configuration d'exception afin que la violation d'accès soit déboguable à la source, voir here.