WinDbg - Failed to load data access module, 0x80004002
x86 프로세스를 x64 운영체제에서 작업관리자를 이용해 덤프를 뜨면 windbg에서 분석이 안 된다고 설명한 적이 있습니다.
windbg - SOS does not support the current target architecture.
; https://www.sysnet.pe.kr/2/0/11262
.NET Core로 오니 오류 메시지가 바뀌어서 기록을 남깁니다. ^^
그때와 마찬가지로 덤프를 열었을 때 자동으로 sos.dll을 받아오긴 하는데,
0:000> .chain
Extension DLL search Path:
...[생략]...
Extension DLL chain:
sos: image 6.0.257301+27172ce4d05e8a3b0ffdefd65f073d40a1b1fe54, API 2.0.0, built Wed Nov 24 07:21:39 2021
[path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2202.7001.0_neutral__8wekyb3d8bbwe\amd64\winext\sos\sos.dll]
...[생략]...
이 상태에서 clrstack 명령을 내리면 다음과 같은 오류가 발생합니다.
0:000> !clrstack
Failed to load data access module, 0x80004002
Verify that 1) you have a recent build of the debugger (10.0.18317.1001 or newer)
2) the file mscordaccore.dll that matches your version of coreclr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordaccore_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on a platform and architecture that supports this
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can run the command '!setclrpath <directory>' to control the load path of mscordaccore.dll.
Or you can also run the debugger command .cordll to control the debugger's
load of mscordaccore.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to coreclr.dll as well.
For more information see https://go.microsoft.com/fwlink/?linkid=2135652
0:000> .cordll -ve -u -l
CLR DLL status: No load attempts
0:000> .cordll -lp "C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\3.1.9"
CLR DLL status: No load attempts
오류 메시지가 바뀌어서, 그냥 아무 생각 없이 보면 왜 이런 상황이 발생했는지 이해가 안 됩니다. 왜냐하면 이전에 설명한 대로,
WinDbg Preview 버전부터 닷넷 코어 3.0 이후의 메모리 덤프에 대해 sos.dll 자동 로드
; https://www.sysnet.pe.kr/2/0/12316
닷넷 코어 3.0 이후로는 sos.dll뿐만 아니라 mscordaccore까지 자동으로 다운로드하기 때문입니다.
저 오류가 x86으로 인한 것인지는 lm 명령어로 대충 짐작할 수 있습니다.
0:000> lm
start end module name
00000000`00ce0000 00000000`00d1b000 iisres (no symbols)
00000000`00db0000 00000000`00ddd000 iisexpress (no symbols)
00000000`2ee90000 00000000`2ee98000 WebApplication1 (deferred)
00000000`2ff60000 00000000`2ff70000 Microsoft_AspNetCore_Watch_BrowserRefresh (deferred)
00000000`31120000 00000000`3113a000 Microsoft_WebTools_BrowserLink_Net (deferred)
00000000`31250000 00000000`31260000 WebApplication1_Views (deferred)
00000000`50390000 00000000`50394000 System_Diagnostics_Tracing (deferred)
00000000`503f0000 00000000`503fc000 Microsoft_Extensions_Logging_EventSource (deferred)
00000000`50400000 00000000`50406000 Microsoft_Extensions_Logging_Debug (deferred)
...[생략]...
프로세스의 모듈들이 모두 저런 식으로 로딩 주소가 상위 8바이트에 대해 0으로 채워져 있으면 x86 프로세스임을 짐작게 합니다. 혹은, Program Files에 있을 법한 모듈을 확인해 보면,
0:000> lmDvmclrjit
Browse full module list
start end module name
00000000`6a4d0000 00000000`6a5e4000 clrjit (deferred)
Image path: C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\3.1.9\clrjit.dll
...[생략]...
저렇게 "Program Files (x86)"이 들어간 것에서 짐작할 수 있습니다. 따라서, 이런 x86 프로세스에 대해서는 반드시
Process Explorer를 이용해 덤프를 떠야 합니다.
그나저나
setclrpath 명령어가 좀 별나군요. ^^;
Windbg preview 버전의 경우 이렇게 오류가 발생하고,
0:000> !setclrpath "C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\3.1.9"
Unrecognized command or argument 'Files'
Unrecognized command or argument '(x86)dotnetsharedMicrosoft.NETCore.App3.1.9'
Windbg에서는 이렇게 됩니다.
0:000> !setclrpath "C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\3.1.9"
Incorrect argument: Files (x86)dotnetsharedMicrosoft.NETCore.App3.1.9
어쩔 수 없습니다. 그냥 저 디렉터리의 내용을 공백이 없는 곳으로 복사해 다시 로드를 하면 됩니다.
[Windbg]
0:000> !setclrpath f:\ts\core
Runtime module path: f:\ts\core
[Windbg preview]
0:000> !setclrpath F:\ts\core
Set load path for DAC/DBI to 'F:\ts\core'
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]