.NET 10 RC1 ModuleLoadStarted callback triggered multiple times in parallel for the same assembly and module

[georgschausberger]

Are there any intended changes starting with .NET 10 to load the same module with different ModuleIDs?

ICorProfiler ModuleLoadStarted callback is triggered multiple times if two threads are using the same not yet initialized type in an external module.

This possibly may lead profilers to apply changes during module load multiple times and cause overhead or failures.

Is this connected the LoaderOptimizations present in the old .NET Framework runtimes?

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[d-schneider]

Could this be related to #107224 (@elinor-fung @jkotas)?

That PR moves the Assembly::Create call to the constructor of DomainAssembly. Apparently the DomainAssembly can be created before the FileLoadLock is acquired in AppDomain::LoadAssemblyInternal:
https://github.com/dotnet/runtime/blob/release/10.0-rc1/src/coreclr/vm/appdomain.cpp#L2438

This leads to a race condition where the ModuleLoadStarted callback is called twice. The ModuleLoadFinished call is only called once after the lock is acquired.

This violates the behavior documented here and can potentially break profiler implementations relying on this: https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/profiling.md#loader-callbacks

coreclr.dll!EEToProfInterfaceImpl::ModuleLoadStarted(unsigned __int64 moduleId) Line 363
coreclr.dll!ProfControlBlock::DoProfilerCallbackHelper<int (__cdecl*)(ProfilerInfo *),long (__cdecl*)(EEToProfInterfaceImpl *,_EventPipeProvider *),_EventPipeProvider *>(ProfilerInfo * pProfilerInfo, int(*)(ProfilerInfo *) condition, HRESULT(*)(EEToProfInterfaceImpl *, _EventPipeProvider *) callback, HRESULT * pHR, _EventPipeProvider * <args_0>) Line 287
coreclr.dll!Module::DoInit(AllocMemTracker * pamTracker, const wchar_t * szName) Line 150
coreclr.dll!Module::Create(Assembly * pAssembly, PEAssembly * pPEAssembly, AllocMemTracker * pamTracker) Line 599
coreclr.dll!Assembly::Init(AllocMemTracker * pamTracker) Line 185
coreclr.dll!Assembly::Create(PEAssembly * pPEAssembly, AllocMemTracker * pamTracker, LoaderAllocator * pLoaderAllocator) Line 348
coreclr.dll!DomainAssembly::DomainAssembly(PEAssembly * pPEAssembly, LoaderAllocator * pLoaderAllocator, AllocMemTracker * memTracker) Line 35
coreclr.dll!AppDomain::LoadAssemblyInternal(AssemblySpec * pIdentity, PEAssembly * pPEAssembly, FileLoadLevel targetLevel) Line 2438

[jkotas]

I agree with your analysis. @elinor-fung Could you please take a look?