DllMain calls LoadLibrary for dxil.dll, could cause deadlock or crash

We've gotten a few Chrome crash reports where the GPU process spuriously hangs while loading dxcompiler.dll via LoadLibrary. The top of our call stacks where the hang is happening looks like:

(ntdll.dll + 0x0009d924)	NtCreateSection
(ntdll.dll + 0x0005fcfd)	LdrpMapDllNtFileName
(ntdll.dll + 0x0005fa7f)	LdrpMapDllFullPath
(ntdll.dll + 0x0005ed1e)	LdrpProcessWork
(ntdll.dll + 0x0001fb52)	LdrpLoadDllInternal
(ntdll.dll + 0x000173e3)	LdrpLoadDll
(ntdll.dll + 0x00016af3)	LdrLoadDll

This isn't much to go on, so I did some searching for what could cause DLL loading to hang, and from the DllMain doc, I found this DLL best practices doc. In there, it mentions how when DllMain runs, it holds the "loader lock", and so must not perform any operation that does the same. In fact, at the top of the list of tasks you should never perform from within DllMain is:

• Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.

Unfortunately, dxcompiler's DllMain does exactly that when it loads "dxil.dll", as it does here. Putting a breakpoint on that LoadLibrary call, we get this callstack:

dxcompiler.dll!dxc::DxcDllSupport::InitializeInternal(const char * dllName=0x00007ffe87dc1c87, const char * fnName=0x00007ffe87d01f80) Line 34	C++
dxcompiler.dll!dxc::DxcDllSupport::InitializeForDll(const char * dll=0x00007ffe87dc1c87, const char * entryPoint=0x00007ffe87d01f80) Line 95	C++
dxcompiler.dll!DxilLibInitialize() Line 29	C++
dxcompiler.dll!InitMaybeFail() Line 68	C++
dxcompiler.dll!DllMain(HINSTANCE__ * hinstDLL=0x00007ffe85340000, unsigned long Reason=1, void * reserved=0x0000000000000000) Line 104	C++
dxcompiler.dll!dllmain_dispatch(HINSTANCE__ * const instance=0x00007ffe85340000, const unsigned long reason=1, void * const reserved=0x0000000000000000) Line 281	C++
dxcompiler.dll!_DllMainCRTStartup(HINSTANCE__ * const instance=0x00007ffe85340000, const unsigned long reason=1, void * const reserved=0x0000000000000000) Line 335	C++
ntdll.dll!LdrpCallInitRoutine()	Unknown
ntdll.dll!LdrpInitializeNode()	Unknown
ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
ntdll.dll!LdrpPrepareModuleForExecution()	Unknown
ntdll.dll!LdrpLoadDllInternal()	Unknown
ntdll.dll!LdrpLoadDll()	Unknown
ntdll.dll!LdrLoadDll()	Unknown
KernelBase.dll!LoadLibraryExW()	Unknown

Note that this callstack doesn't exactly match the one we're getting in our reports. Ours are hanging during LdrpMapDllFullPath -> LdrpMapDllNtFileName -> NtCreateSection, so we don't see DllMain here. However, it seems that DllMain is doing too much, including things it should not do, and I wonder if this is may still be the cause of our spurious hangs.

Any thoughts from Microsoft folks would be appreciated. Have you had reports or seen spurious hangs when dxcompiler.dll is loaded? I understand that most folks are probably using dxc.exe, so there's not much going on in there, but for applications that dynamically load dxcompiler.dll, I wonder if they've hit this before.

Start with include/dxc/Support/dxcapi.use.h at the referenced LoadLibrary call, then trace DxilLibInitialize, InitMaybeFail, and DllMain. Review the Windows DLL loader guidance and the reported call stacks to determine whether initialization can safely occur outside DllMain. Done should address the unsafe loading path and include a way to verify dxcompiler.dll loading no longer hangs or crashes.