Fatal Execution Engine Error when you obtain the security descriptor of a generic class from a native image module in a .NET Framework environment
This article helps you resolve the Fatal Execution Engine Error that occurs when you obtain the security descriptor of a generic class from a native image module in a .NET Framework environment.
Original product version: Microsoft .NET Framework 3.5 Service Pack 1
Original KB number: 2468429
Symptoms
When you try to obtain the security descriptor of a generic class from a native image (Ngen.exe) module in a Microsoft .NET Framework environment, you receive a Fatal Execution Engine Error error message. This problem may occur if the following conditions are true:
- The application includes an assembly that is loaded domain-neutral (
LoaderOptimization.MultiDomain
orLoaderOptimization.MultiDomainHost
). - The assembly contains an instantiation of a generic class.
- The assembly has been compiled into a native image by using the Native Image Generator (Ngen.exe) tool.
- The application loads the native image into an application domain.
- The application tries to use the generic class from a second application domain without loading the native image into that application domain.
Cause
The common language runtime (CLR) could allow code in the domain-neutral native image to run in the second application domain even though the native image hasn't yet been loaded into that application domain. If the CLR tries to obtain a security descriptor before the native image is loaded (for example, when a delegate is created for a method of the instantiated generic type), a fatal execution engine error may occur.
This problem is difficult to reproduce. The CLR aggressively loads assemblies into application domains. For example, if a Type
object is passed into an application domain, this causes the CLR to load the assembly that defines the type. Therefore, it is not easy for the second application domain to obtain information about the instantiated generic class without causing the CLR to load the assembly. The code paths that contribute to this problem occur only in complex scenarios.
Workarounds
To work around this problem, use one of the following methods:
Explicitly load the assembly into each application domain that will use it. For example, load the assembly by calling the
Assembly.Load
method.Don't load the assembly as domain-neutral.
Note
This workaround might affect the size of the application's working set.
Don't use the Ngen.exe tool to create a native image for the assembly.
Note
This workaround might affect the application's performance.
Upgrade the application to the .NET Framework version 4. All issues that are known to contribute to this problem have been addressed in the .NET Framework 4.
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for