warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock
/clr 옵션을 추가한 프로젝트를 만들고 이전 오류를 해결했더니,
error C7681: two-phase name lookup is not supported for C++/CLI or C++/CX; use /Zc:twoPhase-
; https://www.sysnet.pe.kr/2/0/13193
그래도 여전히 빌드하면 이런 경고가 발생합니다.
warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock, including the DLL entrypoint and calls reached from the DLL entrypoint
말이 경고지, 실제 이 상태로 빌드한 DLL을 .NET Framework C# 프로젝트에서 참조해 실행하면 Visual Studio의 디버깅 화면에서는 다음과 같은 MDA 예외를 보게 됩니다.
Message=Managed Debugging Assistant 'LoaderLock' : 'DLL 'C:\temp\ConsoleApplication1\ConsoleApp1\bin\x64\Debug\Dll1.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.'
그러니까, DllMain 내에서 (/clr 옵션을 추가했으니) 혹시나 관리 코드를 실행한다면 응용 프로그램이 먹통이 될 수 있다는 내용입니다. 하지만, 우리가 만든 예제 코드는 DllMain에 아무런 코드도 추가하지 않았기 때문에 문제가 없는데요, 따라서 경고로 알고 지나갈 수 있게 해야 하는데 아예 저렇게 MDA 예외를 발생해 버리는 것입니다.
원래, MDA는 권고 수준의 예외라서 무시하고 지나갈 수 있는 경우가 있긴 한데요, 하지만 LoaderLock 종류의 예외는 그럴 수 없습니다. 만약 (무시하려고 위의 창에서) "Break when this exception type is thrown"을 해제하거나, 그냥 Visual Studio 디버그 환경이 아닌 상태로 직접 실행하면 다음과 같이 비정상 종료가 발생합니다.
C:\temp\ConsoleApplication1\ConsoleApp1\bin\x64\Debug> ConsoleApp1.exe
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Dll1.dll' or one of its dependencies. A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)
at ConsoleApp1.Program.Main(String[] args)
이에 대한 해결책은 문서에서 언급하고 있는데요,
Compiler Warning (level 1) C4747
; https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4747?view=msvc-170
managed and unmanaged pragma
; https://learn.microsoft.com/en-us/cpp/preprocessor/managed-unmanaged
따라서 그냥 DllMain에 다음과 같이 "#pragma unmanaged"를 적용하면 됩니다.
// dllmain.cpp : Defines the entry point for the DLL application.
#include "pch.h"
#pragma unmanaged
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
이렇게 해주면, 해당 DLL을 Native 환경에서 로드했을 때는 DllMain을 호출하지만, Managed 환경에서 로드하는 경우에는 DllMain을 무시합니다.
참고로, MDA LoaderLock은 "Debug" / "Windows" / "Exception Settings... (Ctrl + Alt + E)"을 열어,
"Managed Debugging Assistant" 범주의 "LoaderLock"으로 예외 처리 여부를 조정할 수 있습니다. 닷넷 프로젝트인 경우, 이 옵션을 끄고, "Enable native code debugging" 옵션을 켠 상태에서 디버깅을 시작하면 다음과 같이 상세한 에러 정보를 얻을 수 있는데요,
Unhandled exception at 0x00007FFBBF5703EC (KernelBase.dll) in ConsoleApp1.exe: 0xE0434352 (parameters: 0xFFFFFFFF80131016, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00007FFBA7920000).
해당 파일의 경로는 이렇고,
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.34.31933\crt\src\vcruntime\dll_dllmain.cpp
DllMain 라인에 BP를 걸고 다시 디버깅을 시도하면 (다른 DLL 로드에 의해 몇 번의 BP가 지난 후, 우리가 만든 dll이 로드될 때) 아래의 호출 스택 상태에서 BP가 멈춥니다.
static BOOL __cdecl dllmain_dispatch(
HINSTANCE const instance,
DWORD const reason,
LPVOID const reserved
)
{
...[생략]...
if (reason == DLL_PROCESS_ATTACH || reason == DLL_THREAD_ATTACH)
{
result = dllmain_raw(instance, reason, reserved);
if (!result)
__leave;
result = dllmain_crt_dispatch(instance, reason, reserved);
if (!result)
__leave;
}
// 여기에 BP를 설정
result = DllMain(instance, reason, reserved);
...[생략]...
return result;
}
> Dll1.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 281 C++ Symbols loaded.
Dll1.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 335 C++ Symbols loaded.
mscoreei.dll!_CorDllMain () Unknown Symbols loaded.
mscoree.dll!ShellShim__CorDllMain () Unknown Symbols loaded.
mscoree.dll!_CorDllMain_Exported () Unknown Symbols loaded.
ntdll.dll!LdrpCallInitRoutine() Unknown Symbols loaded.
ntdll.dll!LdrpInitializeNode() Unknown Symbols loaded.
ntdll.dll!LdrpInitializeGraphRecurse() Unknown Symbols loaded.
ntdll.dll!LdrpPrepareModuleForExecution() Unknown Symbols loaded.
ntdll.dll!LdrpLoadDllInternal() Unknown Symbols loaded.
ntdll.dll!LdrpLoadDll () Unknown Symbols loaded.
ntdll.dll!LdrLoadDll() Unknown Symbols loaded.
KernelBase.dll!LoadLibraryExW() Unknown Symbols loaded.
clrjit.dll!Compiler::lvaInitTypeRef() Line 262 C++ Symbols loaded.
clrjit.dll!Compiler::compCompileHelper(CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags, CorInfoInstantiationVerification) Line 6161 C++ Symbols loaded.
clrjit.dll!Compiler::compCompile(CORINFO_METHOD_STRUCT_ * methodHnd, CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags) Line 5644 C++ Symbols loaded.
clrjit.dll!jitNativeCode(CORINFO_METHOD_STRUCT_ * methodHnd, CORINFO_MODULE_STRUCT_ * classPtr, ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, void * * methodCodePtr, unsigned long * methodCodeSize, JitFlags * compileFlags, void * inlineInfoPtr) Line 6953 C++ Symbols loaded.
clrjit.dll!CILJit::compileMethod(ICorJitInfo * compHnd, CORINFO_METHOD_INFO * methodInfo, unsigned int flags, unsigned char * * entryAddress, unsigned long * nativeSizeOfCode) Line 312 C++ Symbols loaded.
mscoreei.dll!_CorExeMain () Unknown Symbols loaded.
mscoree.dll!_CorExeMain_Exported () Unknown Symbols loaded.
kernel32.dll!BaseThreadInitThunk() Unknown Symbols loaded.
ntdll.dll!RtlUserThreadStart () Unknown Symbols loaded.
재미있는 건, 이 상태에서 DllMain 진입점에 BP를 걸고 F10/F11로 진행하려고 시도하면 진입도 안 하고 예외가 발생한다는 점입니다. 사실 _DllMainCRTStartup, dllmain_dispatch이 Native 함수이고 DllMain도 Native이기 때문에 저 호출 과정에서 예외가 발생한다는 것이 이해가 안 됩니다.
하지만, 이때의 DllMain 호출 주소를 자세하게 확인해 보면,
나온 주소(0x00007ffa8d3c5000)에는 jmp 문이 있고 연이어 jmp로 이어집니다.
00007FFA8D3C5000 jmp DllMain+0Ah (07FFA8D3C500Ah)
...
00007FFA8D3C500A jmp qword ptr [__mep@?DllMain@@$$HYAHPEAUHINSTANCE__@@KPEAX@Z (07FFA8D3D2008h)]
...
/* undname으로 풀어보면,
c:\temp> undname ?DllMain@@$$HYAHPEAUHINSTANCE__@@KPEAX@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.
Undecoration of :- "?DllMain@@$$HYAHPEAUHINSTANCE__@@KPEAX@Z"
is :- "int __cdecl DllMain(struct HINSTANCE__ * __ptr64,unsigned long,void * __ptr64)"
*/
이름에서 느낌이 오겠지만 일반적인 Native DllMain이 아니고, /clr 옵션에 의해 관리 모듈 처리가 된 코드를 우선 경유하도록 처리가 된 듯합니다. 실제로 disassembly 창을 이용해 디버깅을 진행하면,
00007FFBA906EE60 48 83 EC 68 sub rsp,68h
00007FFBA906EE64 66 0F 7F 44 24 20 movdqa xmmword ptr [rsp+20h],xmm0
00007FFBA906EE6A 66 0F 7F 4C 24 30 movdqa xmmword ptr [rsp+30h],xmm1
00007FFBA906EE70 66 0F 7F 54 24 40 movdqa xmmword ptr [rsp+40h],xmm2
00007FFBA906EE76 66 0F 7F 5C 24 50 movdqa xmmword ptr [rsp+50h],xmm3
00007FFBA906EE7C 48 89 4C 24 70 mov qword ptr [rsp+70h],rcx
00007FFBA906EE81 48 89 54 24 78 mov qword ptr [rsp+78h],rdx
00007FFBA906EE86 4C 89 84 24 80 00 00 00 mov qword ptr [rsp+80h],r8
00007FFBA906EE8E 4C 89 8C 24 88 00 00 00 mov qword ptr [rsp+88h],r9
00007FFBA906EE96 49 8B CA mov rcx,r10
00007FFBA906EE99 E8 A2 78 FE FF call VTableBootstrapThunkInitHelper (07FFBA9056740h)
VTableBootstrapThunkInitHelper 호출로 이어지고 아마도 이것은 예전에 살펴본 VTableFixups 관련한 managed 측의 전처리 단계로 보입니다.
C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석
; https://www.sysnet.pe.kr/2/0/12126
그러니까, 우리가 만든 DllMain에는 관리 코드가 없지만, /clr 옵션에 의해 강제로 바뀐 진입점으로 인해 말 그대로 "Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang."의 MDA 경고를 어긴 상황이 된 것입니다.
따라서 C4747 경고는 차라리 오류라고 여기는 것이 속편할 것입니다. ^^
(
첨부 파일은 이 글의 예제 환경을 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]