Debug Diag 사용하기

https://docs.microsoft.com/en-us/biztalk/core/how-to-use-debug-diagnostics-to-analyze-a-memory-dump

How to Use Debug Diagnostics to Analyze a Memory Dump - BizTalk Server

디버그 다이어그는 나름 마소의 디버깅 최종 병기 중에 하나이다.

힙, 메모리, cpu 등의 이상 현상을 추적하며

이전에 application verifier가 수행했던 전역을 현역으로 이어받아 수행 중인

그나마 최근까지 릴리즈 중인 녀석이라고 볼 수 있다.

 

3가지 단계로 나뉜다.

1) Debug Diag 설정을 통해 

메모리, CPU, 행 상황 등에 대한 탐지 스코프를 꽂는다. (프로세스)

- 이는 gflag와 비슷한 행위를 하며 umdh나 application verifier로 대신할 수 있다.

마찬가지로 gflag와 applictaion verifier로 스코핑을 했던 덤프나 프로세스, 

출력물을 분석하는 도구로서도 사용된다.

 

2) 프로세스에 탐지자를 꽂은 채로 2가지 모드를 사용해서 덤핑을 수행한다.

 1- 특정 룰, 몇 cpu가 오를 때, 몇 메모리가 올랐을 때, 시간 등을

사용하여 덤프를 스냅샷 형식으로 여러개를 수집하게 하거나

 

 2- 직접 프로세스 탭을 사용하여 프로세스를 고른 후에 룰과 비슷한 형식으로

  동적인 명령어 컨텍스트 메뉴에 의한 동적 모니터링을 수행하고

   (ex : 메모리릭 탐지)

   

3) 마지막으로 직접적으로 덤프를 뜨거나, 잘 되지 않으면 taskmgr, process explorer,

process hacker, procdump, windbg, 그 뭐든지 뜬 후에

 

4) Debug Diag Anlyzer를 통해 여러 개의 덤프를 올리고

동적 덤프 분석 리포트를 받는다.

 

mhn인가 확장자로 떨어지는데

분석해보면, 안에 증가한 메모리, cpu 등 자신이 설정한 스코프대로

'의심' 및 차이를 볼 수 있는 결과를 추론 가능하게 보여준다.

 

분석은 자신이 스스로 한다.

 

이것으로도 부족하면 직접 덤프를 분석하거나

gflag, umdh등으로 다시 뜨거나 vmmap 등 

할 수 있는 여러가지 툴을 다 사용해본다.

 

그런데 어차피 나중에는 귀찮으니 스코프만 꽂고

windbg로 분석하게 되어있다.

 

아니면 자동화 툴을 만들어도 된다.

 

예제는 다음 번에 다루기로 한다.