Freigeben über

Schwerwiegender Ausführungsmodulfehler beim Abrufen der Sicherheitsbeschreibung einer generischen Klasse aus einem systemeigenen Imagemodul in einer .NET Framework-Umgebung

Dieser Artikel hilft Ihnen, den Schwerwiegenden Ausführungsmodulfehler zu beheben, der auftritt, wenn Sie den Sicherheitsdeskriptor einer generischen Klasse aus einem systemeigenen Imagemodul in einer .NET Framework-Umgebung abrufen.

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

Symptome

Wenn Sie versuchen, den Sicherheitsdeskriptor einer generischen Klasse aus einem systemeigenen Imagemodul (Ngen.exe) in einer Microsoft .NET Framework-Umgebung abzurufen, erhalten Sie eine Fehlermeldung des Schwerwiegenden Ausführungsmodulfehlers . Dieses Problem kann auftreten, wenn die folgenden Bedingungen erfüllt sind:

  • Die Anwendung enthält eine Assembly, die domänenneutral (LoaderOptimization.MultiDomain oder LoaderOptimization.MultiDomainHost) geladen wird.
  • Die Assembly enthält eine Instanziierung einer generischen Klasse.
  • Die Assembly wurde mithilfe des Tools native Image Generator (Ngen.exe) in ein systemeigenes Image 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

Die Common Language Runtime (CLR) könnte 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, einen Sicherheitsdeskriptor zu erhalten, 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 ist schwer zu reproduzieren. Die CLR lädt Assemblys aggressiv in Anwendungsdomänen. Wenn z. B. ein Type Objekt in eine Anwendungsdomäne übergeben wird, wird dadurch die CLR die Assembly laden, 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 lädt. Die Codepfade, die zu diesem Problem beitragen, treten nur in komplexen Szenarien auf.

Problemumgehungen

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu umgehen:

  • Laden Sie die Assembly explizit in jede Anwendungsdomäne, die sie verwendet. 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 Ngen.exe Tool 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 .NET Framework, Version 4. Alle Probleme, die bekanntermaßen zu diesem Problem beitragen, wurden im .NET Framework 4 behoben.