C# ne pas attraper les exceptions non gérées à partir de C++ dll

J'ai une C++ dll qui est appelée à partir d'une application en C#, je vais essayer d'obtenir l'application en C# pour intercepter toutes les exceptions, de sorte que dans le cas de la dll échec dû à une non géré exception ensuite, l'utilisateur recevra un demi-décent message d'erreur (l'application en C# est un service web de mise en œuvre de son propre gestionnaire http).

Le problème que j'ai est que tous les types sont capturés. Donc, si je créer et d'exécuter l'application en C# alors la dll renvoie une erreur et l'ensemble de l'application se termine. Des idées?

C'est en cours de création dans VS2005 et de l'aide .Net framework v2

C++ - Test.h

#ifndef INC_TEST_H
#define INC_TEST_H

extern "C" __declspec(dllexport) void ProcessBadCall();

#endif

C++ - Test.cpp

#include <iostream>
#include <vector>

using namespace std;

void ProcessBadCall()
{
  vector<int> myValues;
  int a = myValues[1];
  cout << a << endl;
}

C# - Programme.cs

class Program
{
  [DllImport("Test.dll", EntryPoint="ProcessBadCall")]
  static extern void ProcessBadCall();

  static void Main(string[] args)
  {
    try
    {
      ProcessBadCall();
    }
    catch (SEHException ex)
    {
      Console.WriteLine("SEH Exception: {0}", ex.Message);
    }
    catch (Exception ex)
    {
      Console.WriteLine("Exception: {0}", ex.Message);
    }
  }
}

La dll est en cours d'élaboration en vertu de la libération de configuration suivantes avec les drapeaux du compilateur.

/O2 /GL /D "WIN32" /D "NDEBUG" /D
"_CRT_SECURE_NO_WARNINGS" /D
"_UNICODE" /D "UNICODE" /D "_WINDLL"
/FD /EHa /MD /Fo"Release\"
/Fd"Release\vc80.apb" /W4 /WX /nologo
/c /Wp64 /Zi /TP /errorReport:invite

lorsque la dll est compilé en mode debug, cette habitude de soulever une Exception SEH, mais va provoquer une assertation échec.
Désolé, manqué qu'un peu, la dll est compilé en mode release
Avez-vous essayé le "catch { Console.WriteLine("blablabla"); }"?
Juste essayé, toujours pas de chance. Ce qui semble se passer, c'est que la DLL est en train de lancer une exception non gérée, qui met fin à la fois lui-même et de l'application en c# immédiatement
Vous devez attraper l'exception dans le même runtime qui l'a lancé. D'autre pile de les dérouler et les appels de destructeur peut ne pas fonctionner comme prévu. Et vous typicall ne pouvez pas récupérer à partir d'une violation d'accès, de sorte que vous devriez mettre fin à l'application après l'affichage de l'erreur.

OriginalL'auteur daz-fuller | 2010-11-19

  1. 5

    Essayer d'attraper à l'aide de la ExternalException classe:

    http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.externalexception%28v=VS.100%29.aspx

    Et, essayez de compiler votre C++ DLL avec asynchrone gestion des exceptions (/EHa).
    On dirait que vous êtes l'obtention d'une Violation d'Accès en Lecture dans votre fichier DLL qui est un type de async exception.

    Autant que je sache, seulement .NET v4 et au-dessus désactive la livraison de async des exceptions par défaut. Même alors, vous pouvez ajouter legacyCorruptedStateExceptionsPolicy=true à l'application.config pour l'activer. Avant cela, il est automatiquement activé (vérifiez que vous avez obtenu la valeur false dans l'app.config).

    Noter que c'est ma façon personnelle de croire que les AVs dans votre non géré DLL est intrinsèquement mauvais (et dangereux) de toute façon et c'est probablement le bon comportement .NET tout simplement de mettre fin à l'application. Essayez de lancer std::exception à la place. Si vous insiste sur la capture async exceptions, le meilleur moyen serait d'avoir un médiateur DLL qui enveloppe essayez-fourre-tout autour de l'appel à potentiellement buggy appels de fonction. Encore une fois, très /pas/recommandé (bien que je ne peux voir comment cela pourrait être utile pour déboguer le comportement anormal de DLL).

    Toujours pas de chance, j'en ai peur
    Mis à jour avec des commentaires sur la recompilation de la DLL avec /EHa option du compilateur. S'il vous plaît obtenir qu'un autre aller.
    Même une fois de plus, j'ai ajouté les drapeaux du compilateur à la question d'origine. Cheers
    Si non, vous pouvez introduire une DLL non managée que les thunks dans la DLL que les exportations ProcessBadCall(). Le médiateur de la DLL serait alors de placer l'appel autour de try { } catch (...) { return code d'erreur; }. De cette façon, seul le médiateur de la DLL serait avoir besoin d'être compilé avec /EHa.
    lire cet article, il y a un [HandleProcessCorruptedStateExceptions] attribut qui permet d'intercepter ces exceptions dans certaines méthodes, laisser la valeur par défaut .NET 4 comportement partout ailleurs.

    OriginalL'auteur Zach Saw