Schwerwiegender Ausführungsmodulfehler, wenn Sie den Sicherheitsdeskriptor einer generischen Klasse aus einem systemeigenen Imagemodul in einer .NET Framework Umgebung abrufen

  • Artikel
  • 2 Minuten Lesedauer

Dieser Artikel hilft Ihnen bei der Behebung des Schwerwiegenden Ausführungsmodulfehlers, der auftritt, wenn Sie den Sicherheitsdeskriptor einer generischen Klasse aus einem systemeigenen Imagemodul in einer .NET Framework Umgebung abrufen.

Ursprüngliche Produktversion:   Microsoft .NET Framework 3.5 Service Pack 1
Ursprüngliche KB-Nummer:   2468429

Problembeschreibung

Wenn Sie versuchen, den Sicherheitsdeskriptor einer generischen Klasse aus einem systemeigenen Imagemodul (Ngen.exe) in einer Microsoft .NET Framework-Umgebung abzurufen, wird eine Fehlermeldung vom Typ "Schwerwiegende Ausführungsmodul" angezeigt. Dieses Problem kann auftreten, wenn die folgenden Bedingungen erfüllt sind:

  • Die Anwendung enthält eine Assembly, die domänenneutral ( oder ) geladen LoaderOptimization.MultiDomain LoaderOptimization.MultiDomainHost wird.
  • Die Assembly enthält eine Instanziierung einer generischen Klasse.
  • Die Assembly wurde mithilfe des Tools für den nativen Image-Generator (Ngen.exe) in ein systemeigenes Bild kompiliert.
  • Die Anwendung lädt das systemeigene Image in eine Anwendungsdomäne.
  • Die Anwendung versucht, die generische Klasse aus einer zweiten Anwendungsdomäne zu verwenden, ohne das systemeigene Image in diese Anwendungsdomäne zu laden.

Ursache

Mit der Common Language Runtime (CLR) kann Code im domänenneutralen nativen Image in der zweiten Anwendungsdomäne ausgeführt werden, obwohl das systemeigene Image noch nicht in diese Anwendungsdomäne geladen wurde. Wenn die CLR versucht, eine Sicherheitsbeschreibung abzurufen, bevor das systemeigene Image geladen wird (z. B. wenn ein Delegat für eine Methode des instanziierten generischen Typs erstellt wird), kann ein schwerwiegender Ausführungsmodulfehler auftreten.

Dieses Problem kann nur schwer reproduziert werden. Die CLR lädt Assemblys aggressiv in Anwendungsdomänen. Wenn z. B. ein Type Objekt an eine Anwendungsdomäne übergeben wird, führt dies dazu, dass die CLR die Assembly lädt, die den Typ definiert. Daher ist es für die zweite Anwendungsdomäne nicht einfach, Informationen über die instanziierte generische Klasse abzurufen, ohne dass die CLR die Assembly laden muss. Die Codepfade, die zu diesem Problem beitragen, treten nur in komplexen Szenarien auf.

Problemumgehungen

Um dieses Problem zu umgehen, verwenden Sie eine der folgenden Methoden:

  • Laden Sie die Assembly explizit in jede Anwendungsdomäne, die sie verwenden wird. Laden Sie beispielsweise die Assembly, indem Sie die Assembly.Load Methode aufrufen.

  • Laden Sie die Assembly nicht als domänenneutral.

    Hinweis

    Diese Problemumgehung kann sich auf die Größe des Arbeitssatzes der Anwendung auswirken.

  • Verwenden Sie das tool Ngen.exe nicht, um ein systemeigenes Image für die Assembly zu erstellen.

    Hinweis

    Diese Problemumgehung kann sich auf die Leistung der Anwendung auswirken.

  • Aktualisieren Sie die Anwendung auf die .NET Framework Version 4. Alle Probleme, die bekanntermaßen zu diesem Problem beitragen, wurden im .NET Framework 4 behoben.