0

When dynamically generated assemblies, we regularly get this exception:

Managed Debugging Assistant 'FatalExecutionEngineError' Message=Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0xa3851e22, on thread 0x25ac. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.'

which on loading the CLR symbols is always thrown with this call stack:

           ntdll.dll!NtWaitForSingleObject ()            Unknown
           KernelBase.dll!WaitForSingleObjectEx () Unknown
           ntdll.dll!RtlpCallVectoredHandlers()        Unknown
           ntdll.dll!RtlDispatchException() Unknown
           ntdll.dll!KiUserExceptionDispatch ()        Unknown
           kernel32.dll!BaseThreadInitThunk ()       Unknown
           ntdll.dll!RtlUserThreadStart ()    Unknown

This problem does not occur when AssemblyBuilderAccess is set to RunAndSave, but it reliably occurs when setting it to RunAndCollect. It always is thrown at this call stack. Is there a CLR bug with RunAndCollect? As far as we can tell, we hold references to the Assembly and Module reflection objects for these dynamic assemblies, which should mean they are not being collected ever. This should mean there is no difference in behaviour between RunAndSave and RunAndCollect.

Nick
  • 920
  • 1
  • 7
  • 21
  • The problem may not necessarily be that the assembly is unloaded unexpectedly; it could be that internal code fails to consider some corner case with a collectible assembly (proper support for them has become spotty since they were introduced precisely because all the restrictions are hard to keep track of). If you run the application under the debugger consistently, you should be able to observe DLL load/unload notifications, as well as verify if the assembly is actually unloaded at the time this exception happens. – Jeroen Mostert Jan 27 '20 at 15:30
  • Also, if you haven't already done so, you may want to review the [restrictions](https://learn.microsoft.com/dotnet/framework/reflection-and-codedom/collectible-assemblies#restrictions-on-collectible-assemblies) to ensure you're not actually violating one without knowing it (they may not all be consistently enforced by the runtime) and turning on [MDAs](https://learn.microsoft.com/dotnet/framework/debug-trace-profile/diagnosing-errors-with-managed-debugging-assistants) to see if problems can be observed before this access violation actually happens (which looks like the end stage). – Jeroen Mostert Jan 27 '20 at 15:58

0 Answers0