System.AccessViolationException du code non managé?

Question

Je vous écris cette bibliothèque qui implémente un certain lecteur audio de base figure dans C ++ / CLI via le framework Foundation Media qui sera consommée par le code managé. Je peux jouer audio, arrêt, pause, etc très bien. Pour tous ceux qui ne sont pas familiers avec Media Foundation, les messages de session média événements que vous pouvez gérer pour les notifications. Cela se fait en appelant BeginGetEvent sur l'objet de la session avec un objet IMFAsyncCallback. Le IMFAsyncCallback définit la méthode Invoke (IMFAsyncResult) que vous devez mettre en œuvre pour gérer les événements. Lorsqu'un événement se produit, la méthode Invoke est appelée par l'objet de la session sur un thread de travail avec un objet IMFAsyncResult que vous pouvez interroger pour l'information d'événement. Cet objet de résultat est créé et possédé par le fil des événements.

Dans ma mise en œuvre de Invoke, chaque fois que j'essaie de faire quoi que ce soit (qui comprend simplement appeler QueryInterface ou quelque chose) avec l'objet IMFAsyncResult que je suis passé, je reçois un System.AccessViolationException. L'objet que je l'ai mise en œuvre IMFAsyncCallback est une classe (non géré) C ++ de base alloué sur le tas CRT et les événements sont affichés sur un fil appartenant à l'objet de session a également alloué sur le tas CRT.

1. Qu'est-ce qui pourrait causer cette exception?

2. Pourquoi suis-je recevoir une exception gérée .NET lancée à partir du code qui est mis en œuvre dans la plaine ancienne C ++? Est-ce que ce qui se passe lorsque vous avez un assemblage en mode mixte?

Answer 1

Capturer un accident vider , 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 la plus compliquée que je vais élaborer sur ce (choisir les versions 32 bits ou 64 bits de la fonction de votre plate-forme cible suivante):

• Téléchargez et installez outils de débogage pour Windows

• Configurer les symboles de débogage pour le serveur de symboles Microsoft

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

• Charger le fichier de vidage sur incident dans WinDbg (Fichier-> Ouvrir vidage mémoire ...)

• Configurer les symboles de débogage pour vos modules

  .sympath+ <PrivatePdbDir>

• Charger extensions SOS dans WinDbg

  .loadby sos mscorwks; * fw 2-3.5

  ou

  .loadby sos clr; * fw 4

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

  .load <Sosex32or64Dir>\sosex

• Soit 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

Ce sera très probablement répondre à vos questions.

Answer 2

On dirait que vous avez un repro facile de cela - vous devriez être en mesure de déboguer le problème en attachant le débogueur alors que le programme est en cours d'exécution et permettant la violation d'accès à être pris au piège au moment où il se produit. Souvent, les bibliothèques et enveloppent cette surface comme un autre type, et le site d'origine de l'exception n'est pas apparente.

Pour joindre à votre processus de Visual Studio voir . Lorsque vous connectez à votre processus de voyous, assurez-vous de sélectionner les options de débogage du code natif et géré. Assurez-vous que pour vos symboles DLLs et assemblies sont disponibles dans la section chemin Symbole, aussi loin que vous pouvez (certains peuvent ne pas être disponibles si elles sont du code tiers).

Pour modifier config d'exception afin que la violation d'accès est débogable à la source, voir .