Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법

이전 글에서는,

windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/12062

Visual Studio를 이용해 RtlReportCriticalFailure와 관련한 "parameters"를 쉽게 구해 heap 관련 정보를 얻을 수 있었는데요. 그렇다면 windbg로는 어떻게 처리할 수 있을지 설명해 보겠습니다. ^^




우선, windbg에서 RtlReportCriticalFailure 예외가 발생한 덤프를 열면 곧바로 이런 메시지가 나옵니다.

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(11e4.8e0): Unknown exception - code c0000374 (first/second chance not available)
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)

메시지에서 보이는 것처럼 ".ecxr" 명령어를 수행해도 되지만 어차피 지금 문제가 발생한 스레드의 문맥에 있으므로 그냥 "r" 명령어로 봐도 무방합니다.

0:016> .ecxr
rax=0000000000000000 rbx=0000002cab7fe470 rcx=0000002cab7fea18
rdx=0000000000000008 rsi=0000002cab7fdf80 rdi=0000002cab7fdf80
rip=00007ffd05d882d3 rsp=0000002cab7fed40 rbp=0000000000000000
 r8=fffffff800000021  r9=0000000000000000 r10=0000000000000000
r11=0000002cab7feaa0 r12=0000000000000000 r13=0000002cab7ff2e0
r14=0000014e8cba0000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000204
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)

0:016> r
Last set context:
rax=0000000000000000 rbx=0000002cab7fe470 rcx=0000002cab7fea18
rdx=0000000000000008 rsi=0000002cab7fdf80 rdi=0000002cab7fdf80
rip=00007ffd05d882d3 rsp=0000002cab7fed40 rbp=0000000000000000
 r8=fffffff800000021  r9=0000000000000000 r10=0000000000000000
r11=0000002cab7feaa0 r12=0000000000000000 r13=0000002cab7ff2e0
r14=0000014e8cba0000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000204
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)

자, 그럼 우리가 여기서 궁금한 것은 Visual Studio에서 보여준 "parameters"에 해당하는 정보입니다. 이를 위해 우선 k 명령어로 callstack을 보고,

0:016> k
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr           Call Site
00 0000002c`ab7fed40 00007ffd`05d88c2a ntdll!RtlReportCriticalFailure+0x97
01 0000002c`ab7fee50 00007ffd`05d35b7a ntdll!RtlpHeapHandleError+0x12
02 0000002c`ab7fee80 00007ffd`05cccc33 ntdll!RtlpLogHeapFailure+0x96
03 0000002c`ab7feeb0 00007ffc`f061fbaf ntdll!RtlFreeHeap+0x823
04 0000002c`ab7fef60 00007ffc`f0628a29 OraOps19!ssmem_free+0xf
05 0000002c`ab7fef90 00007ffc`99b372fe OraOps19!OpsMetFreeValCtx+0x89
06 0000002c`ab7fefc0 00007ffc`99b7d635 0x00007ffc`99b372fe
07 0000002c`ab7ff070 00007ffc`f85757c6 0x00007ffc`99b7d635
08 0000002c`ab7ff0b0 00007ffc`f8606a91 clr!FastCallFinalizeWorker+0x6
09 0000002c`ab7ff0e0 00007ffc`f8606a19 clr!FastCallFinalize+0x55
...[생략]...
1c 0000002c`ab7ffad0 00007ffd`03228364 clr!Thread::intermediateThreadProc+0x86
1d 0000002c`ab7ffb90 00007ffd`05cf7091 kernel32!BaseThreadInitThunk+0x14
1e 0000002c`ab7ffbc0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

ntdll!RtlReportCriticalFailure의 코드를 살펴보면,

0:016> uf ntdll!RtlReportCriticalFailure
ntdll!RtlReportCriticalFailure:
00007ffd`05d8823c 48895c2418      mov     qword ptr [rsp+18h],rbx
...[생략]...
00007ffd`05d88278 7427            je      ntdll!RtlReportCriticalFailure+0x65 (00007ffd`05d882a1)  Branch

...[생략]...

ntdll!RtlReportCriticalFailure+0x65:
00007ffd`05d882a1 895c2450        mov     dword ptr [rsp+50h],ebx
00007ffd`05d882a5 b901000000      mov     ecx,1
00007ffd`05d882aa 894c2454        mov     dword ptr [rsp+54h],ecx
00007ffd`05d882ae 488364245800    and     qword ptr [rsp+58h],0
00007ffd`05d882b4 488d05452df5ff  lea     rax,[ntdll!RtlRaiseException (00007ffd`05cdb000)]
00007ffd`05d882bb 4889442460      mov     qword ptr [rsp+60h],rax
00007ffd`05d882c0 894c2468        mov     dword ptr [rsp+68h],ecx
00007ffd`05d882c4 48897c2470      mov     qword ptr [rsp+70h],rdi
00007ffd`05d882c9 488d4c2450      lea     rcx,[rsp+50h]
00007ffd`05d882ce e82d2df5ff      call    ntdll!RtlRaiseException (00007ffd`05cdb000)
00007ffd`05d882d3 eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)  Branch

ntdll!RtlReportCriticalFailure+0x99:
00007ffd`05d882d5 488b8c24f0000000 mov     rcx,qword ptr [rsp+0F0h]
00007ffd`05d882dd 4833cc          xor     rcx,rsp
00007ffd`05d882e0 e8cbe5f9ff      call    ntdll!_security_check_cookie (00007ffd`05d268b0)
00007ffd`05d882e5 4c8d9c2400010000 lea     r11,[rsp+100h]
00007ffd`05d882ed 498b5b20        mov     rbx,qword ptr [r11+20h]
00007ffd`05d882f1 498b7328        mov     rsi,qword ptr [r11+28h]
00007ffd`05d882f5 498be3          mov     rsp,r11
00007ffd`05d882f8 5f              pop     rdi
00007ffd`05d882f9 c3              ret

k 명령어로 본 "RtlReportCriticalFailure+0x97"의 0x97 위치에 해당하는 기계어 코드를 확인할 수 있습니다. 그리고 그것은 RtlRaiseException이고,

RtlRaiseException function
; https://docs.microsoft.com/en-us/windows/win32/api/rtlsupportapi/nf-rtlsupportapi-rtlraiseexception

NTSYSAPI __analysis_noreturn VOID RtlRaiseException(PEXCEPTION_RECORD ExceptionRecord);

전달받는 인자가 EXCEPTION_RECORD에 대한 포인터 하나입니다. 간단해서 좋군요. ^^ 그렇다면 "call ntdll!RtlRaiseException"을 호출하기 전 수행한 "lea rcx, [rsp+50h]"의 "rcx" 레지스터에 담긴 값이 바로 EXCEPTION_RECORD 포인터 인자로 예상할 수 있습니다. 여기서 문제는, 비록 k 명령어의 결과에는 없지만 어쨌든 "RtlRaiseException" 함수가 수행 중이므로 현재 "r" 명령어로 출력한 "rcx" 값은 이미 RtlRaiseException 함수의 내부 코드에 의해서 변조되었을 가능성이 높다는 점입니다.

대신 frame 문맥 자체는 RtlReportCriticalFailure 함수 실행 시로 바뀐 상태이므로 "rsp" 레지스터의 값은 유효하므로 "lea rcx, [rsp+50h]"의 결과를 "r" 명령어에 출력된 rsp == 0000002cab7fed40 값에 +50h를 해 "2CAB7FED90"로 쉽게(?) EXCEPTION_RECORD의 포인터를 구할 수 있습니다.




이쯤에서 잠시 EXCEPTION_RECORD를 한번 살펴볼까요? ^^

EXCEPTION_RECORD structure
; https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-exception_record

typedef struct _EXCEPTION_RECORD {
  DWORD                    ExceptionCode;
  DWORD                    ExceptionFlags;
  struct _EXCEPTION_RECORD *ExceptionRecord;
  PVOID                    ExceptionAddress;
  DWORD                    NumberParameters;
  ULONG_PTR                ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;

오호~~~ 우리에게 익숙한 필드명 NumberParameters가 보이는군요. ^^ 아마도 저 값이 Visual Studio에서 보여줬던 바로 그 "parameters"일 것입니다. 이러한 레코드 정보에 기반을 둬 ntdll!RtlReportCriticalFailure+0x65 위치의 코드를 다시 보면,

ntdll!RtlReportCriticalFailure+0x65:
00007ffd`05d882a1 895c2450        mov     dword ptr [rsp+50h],ebx
00007ffd`05d882a5 b901000000      mov     ecx,1
00007ffd`05d882aa 894c2454        mov     dword ptr [rsp+54h],ecx
00007ffd`05d882ae 488364245800    and     qword ptr [rsp+58h],0
00007ffd`05d882b4 488d05452df5ff  lea     rax,[ntdll!RtlRaiseException (00007ffd`05cdb000)]
00007ffd`05d882bb 4889442460      mov     qword ptr [rsp+60h],rax
00007ffd`05d882c0 894c2468        mov     dword ptr [rsp+68h],ecx
00007ffd`05d882c4 48897c2470      mov     qword ptr [rsp+70h],rdi
00007ffd`05d882c9 488d4c2450      lea     rcx,[rsp+50h]
00007ffd`05d882ce e82d2df5ff      call    ntdll!RtlRaiseException (00007ffd`05cdb000)
00007ffd`05d882d3 eb00            jmp     ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)  Branch

결국, EXCEPTION_RECORD의 구조체 위치가 "rsp+50h"이고 그곳에 다음과 같이 필드를 채운 것과 같습니다.

typedef struct _EXCEPTION_RECORD {
  DWORD                    ExceptionCode;  // mov     dword ptr [rsp+50h],ebx
                                           // mov     dword ptr [rsp+54h],ecx
  DWORD                    ExceptionFlags;  // and     qword ptr [rsp+58h],0   // [rsp+58h] == 0
  struct _EXCEPTION_RECORD *ExceptionRecord;  // mov     qword ptr [rsp+60h],rax // rax == 00007ffd`05cdb000
  PVOID                    ExceptionAddress;  // mov     dword ptr [rsp+68h],ecx // (int)[rsp+68h] == 1
  DWORD                    NumberParameters;  // mov     qword ptr [rsp+70h],rdi // (int)[rsp+70h] == 전달된 두 번째 인자
  ULONG_PTR                ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;

따라서 이전에 구했던 rsp+50h 주솟값인 2CAB7FED90 위치를 덤프해 보면,

0:016> dq rsp+50h
0000002c`ab7fed90  00000001`c0000374 00000000`00000000
0000002c`ab7feda0  00007ffd`05d882d3 00007ffc`00000001
0000002c`ab7fedb0  00007ffd`05ddf6b0 00007ffc`f8575191
0000002c`ab7fedc0  00000ec4`00000000 0000014e`8dc53610
0000002c`ab7fedd0  00000000`00000000 00007ffd`05d042e3
0000002c`ab7fede0  00007a66`762bbd2a 0000002c`ab7fef30
0000002c`ab7fedf0  00000000`00000000 0000014e`8cba0000
0000002c`ab7fee00  00000000`00000000 00000000`00000000

NumberParameters의 위치(rsp+70h)에 해당하는 값을 구할 수 있고, 실제로 Visual Studio가 출력했던 parameters 값과 일치합니다. 게임 끝났군요. ^^ 이 값을 메모리 창에 보면 HeapFree에 전달되었던 hHandle과 해제하려는 메모리 주소를 알아낼 수 있습니다.

// [00007ffd05ddf6b0]
00007ffd`05ddf6b0 000006e000000002
00007ffd`05ddf6b8 0000000000000004
00007ffd`05ddf6c0 00000286f28f0000 // hHandle
00007ffd`05ddf6c8 0000028b412d3be0 // pVoid - 0x10
00007ffd`05ddf6d0 0000000000000000




여기까지 읽으신 분은 다소 허무하겠지만 ^^ windbg에는 EXCEPTION_RECORD에 대한 정보를 출력할 수 있는 명령어가 이미 있어서 ^^ 위와 같이 복잡하게 작업하지 마시고 RtlReportCriticalFailure가 발생한 경우 처음부터 ".exr -1" 명령어를 수행하면 됩니다.

0:016> .exr -1
ExceptionAddress: 00007ffd05d882d3 (ntdll!RtlReportCriticalFailure+0x0000000000000097)
   ExceptionCode: c0000374
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 00007ffd05ddf6b0

보는 바와 같이 Visual Studio가 출력했던 예외 메시지의,

Unhandled exception at 0x00007FFD05D882D3 (ntdll.dll) in dump4580.dmp: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFD05DDF6B0)


바로 그 정보들을 동일하게 구할 수 있습니다.




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 11/22/2019 ]

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

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  7  8  9  10  11  [12]  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
11989정성태7/18/2019733Windows: 162. Windows Server 2019 빌드 17763부터 Alt + F4 입력시 곧바로 로그아웃하는 현상
11988정성태7/18/20191339개발 환경 구성: 453. 마이크로소프트가 지정한 모든 Root 인증서를 설치하는 방법
11987정성태7/17/20193480오류 유형: 558. 윈도우 - KMODE_EXCEPTION_NOT_HANDLED 블루스크린(BSOD) 문제
11986정성태7/18/2019860오류 유형: 557. 드라이브 문자를 할당하지 않은 파티션을 탐색기에서 드라이브 문자와 함께 보여주는 문제
11985정성태7/17/2019860개발 환경 구성: 452. msbuild - csproj에 환경 변수 조건 사용
11984정성태7/9/20191450개발 환경 구성: 451. Microsoft Edge (Chromium)을 대상으로 한 Selenium WebDriver 사용법
11983정성태7/8/2019902오류 유형: 556. nodemon - 'mocha' is not recognized as an internal or external command, operable program or batch file.
11982정성태7/8/2019919오류 유형: 555. Visual Studio 빌드 오류 - result: unexpected exception occured (-1002 - 0xfffffc16)
11981정성태7/7/20191121Math: 64. C# - 3층 구조의 신경망(분류)파일 다운로드1
11980정성태7/7/20194569개발 환경 구성: 450. Visual Studio Code의 Java 확장을 이용한 간단한 프로젝트 구축파일 다운로드1
11979정성태7/8/20191288개발 환경 구성: 449. TFS에서 gitlab/github등의 git 서버로 마이그레이션하는 방법
11978정성태7/6/20191211Windows: 161. 계정 정보가 동일하지 않은 PC 간의 인증을 수행하는 방법 [1]
11977정성태7/6/20191917오류 유형: 554. git push - error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
11976정성태7/4/20191209오류 유형: 553. (잘못 인증 한 후) 원격 git repo 재인증 시 "remote: HTTP Basic: Access denied" 오류 발생
11975정성태7/4/20192898개발 환경 구성: 448. Visual Studio Code에서 콘솔 응용 프로그램 개발 시 "입력"받는 방법
11974정성태7/4/20191784Linux: 22. "Visual Studio Code + Remote Development"로 윈도우 환경에서 리눅스(CentOS 7) C/C++ 개발
11973정성태7/4/20191268Linux: 21. 리눅스에서 공유 라이브러리가 로드되지 않는다면?
11972정성태7/3/20191434.NET Framework: 847. JAVA와 .NET 간의 AES 암호화 연동파일 다운로드1
11971정성태7/3/20191321개발 환경 구성: 447. Visual Studio Code에서 OpenCvSharp 개발 환경 구성
11970정성태7/2/20191150오류 유형: 552. 웹 브라우저에서 파일 다운로드 후 "Running security scan"이 끝나지 않는 문제
11969정성태7/7/20191103Math: 63. C# - 3층 구조의 신경망파일 다운로드1
11968정성태7/1/20192679오류 유형: 551. Visual Studio Code에서 Remote-SSH 연결 시 "Opening Remote..." 단계에서 진행되지 않는 문제 [1]
11967정성태7/1/20191102개발 환경 구성: 446. Synology NAS를 Windows 10에서 iSCSI로 연결하는 방법
11966정성태6/30/20191110Math: 62. 활성화 함수에 따른 뉴런의 출력을 그리드 맵으로 시각화파일 다운로드1
11965정성태6/30/20191175.NET Framework: 846. C# - 2차원 배열을 1차원 배열로 나열하는 확장 메서드파일 다운로드1
11964정성태6/30/20191482Linux: 20. C# - Linux에서의 Named Pipe를 이용한 통신
1  2  3  4  5  6  7  8  9  10  11  [12]  13  14  15  ...