Microsoft MVP성태의 닷넷 이야기
오류 유형: 798. WinDbg - Failed to load data access module, 0x80004002 [링크 복사], [링크+제목 복사],
조회: 15122
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 6개 있습니다.)
오류 유형: 412. windbg - SOS does not support the current target architecture.
; https://www.sysnet.pe.kr/2/0/11262

오류 유형: 798. WinDbg - Failed to load data access module, 0x80004002
; https://www.sysnet.pe.kr/2/0/12994

디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
; https://www.sysnet.pe.kr/2/0/13216

디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
; https://www.sysnet.pe.kr/2/0/13217

디버깅 기술: 201. WinDbg - sos threads 명령어 실행 시 "Failed to request ThreadStore"
; https://www.sysnet.pe.kr/2/0/13725

오류 유형: 950. Process Explorer - 64비트 윈도우에서 32비트 프로세스의 덤프를 뜰 때 "Error writing dump file: Access is denied." 오류
; https://www.sysnet.pe.kr/2/0/13913




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'




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 3/8/2022]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  [10]  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13693정성태7/24/20247229개발 환경 구성: 717. Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법파일 다운로드1
13692정성태7/24/20248004디버깅 기술: 199. Windbg - 리눅스에서 뜬 닷넷 응용 프로그램 덤프 파일에 포함된 DLL의 Export Directory 탐색
13691정성태7/23/20247364디버깅 기술: 198. Windbg - 스레드의 Win32 Message Queue 정보 조회
13690정성태7/23/20246996오류 유형: 919. Visual C++ 리눅스 프로젝트 - error : ‘u8’ was not declared in this scope
13689정성태7/22/20248490디버깅 기술: 197. Windbg - PE 포맷의 Export Directory 탐색
13688정성태7/21/20247606닷넷: 2281. C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리파일 다운로드1
13687정성태7/19/20248040닷넷: 2280. C# - PostThreadMessage로 보낸 메시지를 Windows Forms에서 수신하는 방법파일 다운로드1
13686정성태7/19/20247832오류 유형: 918. Visual Studio - ATL Simple Object 추가 시 error C2065: 'IDR_...': undeclared identifier
13685정성태7/19/20247985스크립트: 66. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법 - 두 번째 이야기
13684정성태7/19/20248148닷넷: 2279. C# - 문자열 보간식 사례 (예: 조건 연산자 사용)
13683정성태7/18/20247634오류 유형: 917. ClrMD - Linux 환경의 .NET 5 덤프 분석 시 hang 현상
13682정성태7/18/20247844닷넷: 2278. WPF - 스레드에 종속되는 DependencyObject파일 다운로드1
13681정성태7/17/20247455닷넷: 2277. C# 13 - (2) 메서드 그룹의 자연 타입 개선 (메서드 추론 개선)파일 다운로드1
13680정성태7/16/20247813닷넷: 2276. C# - Method Group, Natural Type, function_type파일 다운로드1
13679정성태7/16/20246920Linux: 76. Linux - C++ (getaddrinfo 등을 담고 있는) libnss 정적 링크
13678정성태7/15/20247048VS.NET IDE: 191. Visual Studio 2022 - .NET 5 프로젝트를 Docker Support로 실행했을 때 오류
13677정성태7/15/20247119오류 유형: 916. MSBuild - CheckEolTargetFramework (warning NETSDK1138)
13676정성태7/14/20247309Linux: 75. gdb에서 glibc의 함수에 Breakpoint 걸기
13675정성태7/13/20249088C/C++: 166. C/C++ - DLL에서 template 함수를 export하는 방법 [1]파일 다운로드1
13674정성태7/13/20247974오류 유형: 915. Unhandled Exception: Microsoft.Diagnostics.NETCore.Client.ServerNotAvailableException: Unable to connect to Process
13673정성태7/11/20248417닷넷: 2275. C# 13 - (1) 신규 이스케이프 시퀀스 '\e'파일 다운로드1
13672정성태7/10/20247141닷넷: 2274. IIS - (프로세스 종료 없는) AppDomain Recycle
13671정성태7/10/20247247오류 유형: 914. Package ca-certificates is not installed.
13669정성태7/9/20247360오류 유형: 913. C# - AOT StaticExecutable 정적 링킹 시 빌드 오류
13668정성태7/8/20247380개발 환경 구성: 716. Hyper-V - Ubuntu 22.04 Generation 2 유형의 VM 설치
13667정성태7/7/20246603닷넷: 2273. C# - 리눅스 환경에서의 Hyper-V Socket 연동 (AF_VSOCK)파일 다운로드1
1  2  3  4  5  6  7  8  9  [10]  11  12  13  14  15  ...