What could cause a NativeAot DLL to throw a FAST_FAIL when loaded manually? (without LoadLibrary)

[SparkyTD]

I am trying to manually load a NativeAot-compiled DLL from memory, just to explore the possibilities of this new tech. The point is to avoid using LoadLibrary, and manually parse the PE, allocate the sections, etc... . I've tried multiple ready-made approaches (MemoryModule, mmLoader, memory-module-loader, DLLFromMemory-net), but all of them produced the same result: The application crashing with error code 0xc0000602 (STATUS_FAIL_FAST_EXCEPTION). This leads me to believe that the problem isn't in the loaders, but rather in the compiled AOT binary.

When investigating the runtime's source code, I've seen multiple references to helper functions that throw this exception (e.g. src/coreclr/nativeaot/Test.CoreLib/src/System/RuntimeExceptionHelpers.cs), but I can't figure out a way to identify the exact cause, or even just a way to debug it when it happens.

All of the mentioned loader libraries have been pretty well-tested, and they all work with regular native DLLs compiled from C/C++. What is it in NativeAot that causes an incompatibility with manual memory loading? My guess would be that the native runtime might try to call GetModuleFileName at some point on the "current" module, which would probably fail for obvious reasons.

Is there a way to make NativeAot libraries compatible with manual in-memory loading? Any pointers in the right direction are appreciated!

[jkotas]

These loaders have number of compatibility issues. It is not surprising that you are seeing crashes when trying to use them to load native AOT compiled binaries.

[SparkyTD]

Thank you for your reply. I was hoping to generate a single executable that can inject .NET code into other processes by memory-loading a NativeAot DLL stored as a resource. I've also tried exporting functions from a NativeAot-linked exe, and calling them with regular LoadLibrary/GetProcAddress, but that's also impossible. I assume there is just no way to do DLL fileless code injection with the current state of this feature.

[jkotas]

The fixes to make your scenario work would need to be in the from-memory loaders. I do not expect we would be open to PRs to restrict what native AOT runtime is allowed to do to make it compatible with these from-memory loaders.

[SparkyTD]

Could you give me any hints/keywords about what changes would need to be done to a memory loader, so I can do further research on it?

[jkotas]

I do not know. You would need to debug the crashes using windbg.

[SparkyTD]

Alright, thank you! I'll mark your original comment as solution.