ProcDump

ProcDump를 사용하는 목적

 

-------------------------------------------------------------------------------------

1. CPU나 메모리의 임계치가 초과될 때, (주 목적이다)

2. First Exception/Second Exception/Unknown Crash

- 주로 GUI를 가진 프로그램 같은 게 조용히 뻗어버리거나, 

- 셋업 설치 같은 게 그냥 조용히 뻗어버리거나,

- 쥐도새도 모르게 뻗어버리는 종류에는 프로세스 이름만 알면 되니 유용하다.

3. Performance Counter(성능 모니터) 의 임계치 측정

- 어떠한 특정 성능 사용률에 대해서 측정/모니터링할 수 있다.

4. Hang 현상 - 주) Application Hang

- Appliction Hang에 대해서 규정하려면 내부의 스레드가 단일 하거나 

명시적으로 Windows 창을 가진 메시지 펌프 스타일의 '응답-대기' 스타일을 가진

프로세스일 때 Hang임을 구분할 수 있다. 

 

멀티 스레드나 서비스 프로그램에 대해서는 유용하지 않다. 

그보다는 사용자가 직접 Hang 상태임을 인지할 수 있도록 측정 값을 

넣어주는 편이 좋다. 

-------------------------------------------------------------------------------------

 

사실 위의 측면에선 Application Verifier 도 사용할 수 있지만 

이는 개발자 측면에서 편리하고, 엔지니어가 사용하기엔 불편하다. 

Appliction Verifier는 나중에 알아보자. 

 

대체 가능 프로그램

 

--------------------------------------------------------------------------------------

 

1. 개발자고 디버거를 잘 안다면, Windbg

2. Application Verifier 

- WDK를 설치해야 된다. 귀찮다.

3. Xperf 

- 성능 관련 문제를 아주 자세히 보고 측정할 때에 쓴다.

4. 그냥 짬뽕해서 쓴다. 현업에서는 보통 짬뽕해서 쓴다. 

보통, 이런 식으로 본다

 

1) 프로세스 익스플로러로 봤는데 뭔가 리소스가 이상하다.

 

2) 성능 모니터로 본다. 대략 어디쯤인지, 어느 구간에 나는지 본다. 

 

3) Xperf로 자세히 본다. 

 

4) Xperf는 기록량이 너무 세부적이므로 재현 시간이 오래걸리면

2)에서 3)인 Xperf가 아닌 ProcDump로 몇몇 포인트로 덤프 떠본다.

몇 초 사이로 구분해본다. 

 

5) 실제 포인트 구간에서 Windbg로 실시간 디버깅 해본다.

등등으로 해본다. 

 

ProcDump를 사용하는 예제

 

docs.microsoft.com/en-us/sysinternals/downloads/procdump

ProcDump - Windows Sysinternals

를 찬찬히 읽어보면 기본적인 예제들이 나와 있다.

그럼에도 가장 많이 쓰는 내용을 살펴보면, 

(솔직히 자세한 거 다 알아봐야 쓰는 건 거의 정해져있다)... 

그래도 풀덤프 뜨는건 잊지 말자. 미니 덤프 떠봐야 번거롭다.

 

상황	명령어	파라메터 설명	부가 설명
프로세스를 실행시키면서 예외 확인하기	procdump -e 1 -f "" -x [덤프경로] 실행파일.exe		프로세스를 실행시키면서 예외를 보는 건데 보통, 조용히 죽어버리는 셋업본 같은 경우 원인을 찾을 수 있다
PID를 아는 경우에 뜨기	procdump -ma 프로세스ID	-ma : 풀덤프로 뜬다	PID를 안다는 건 자동화에 연동시킬 경우가 높습니다.
CPU 가 높이 오를 때 몇 초 단위로 스냅샷을 찍어 덤프 생성/혹은 행 측정	procdump -s 5 -n 3 프로세스 이름	-s 초 : 몇 초 동안  -n 갯수 : 몇 개의 덤프를 뜰 것인가 -ma는 붙여줍시다.	사용자가 정확한 cpu 측정치는 모르는데 어떠한 프로세스가 많이 오른다고 의심되거나 행이 걸려있는 것 같다고 의심될 때에 사용할 수 있습니다. * 시간 조절이나 갯수는 사용자의 경험에 의지
위의 내용과 비슷, 하지만 명확한 CPU 사용량을 알 때에 그 CPU 사용량에 대해 시간/덤프 갯수 대로 스냅샷을 찍습니다. 아주 유용합니다.	procdump -c 20 -s 5 -n 3 프로세스이름	-c cpu수치 : taskmgr(테스크매니져)에서 측정하는 프로세스의 전체 cpu(모든 cpu코어)의 일반적인 수치입니다.  -s 초 : 몇 초동안 측정할지 -n 갯수: 덤프 생성할 갯수 -ma로 풀덤프...	위와 동일, 다만 사용자가 cpu의 명확한 수치를 측정 원할 때 사용 가능, ex) 아 ~ taskmgr 에서 봤더니 어떤 프로세스가 20% 30% 쓰는거 같은데 20% 정도 잡아서 측정해보자! 요놈!
시스템에서 '행'으로 인식한 프로세스에 대해서 덤프를 뜹니다. 위에서 말한대로 주로 싱글 스레드나 사용자 메시지 펌프를 사용하는 gui 를 가진 윈도우 프로그램에서 유용합니다.	procdump -h 행.exe 덤프이름	행 걸린 것처럼  '응답없음'이 뜨는 프로세스에 대해서 hang으로 인식하고 떠준다.	'CPU 가 높이 오를 때 몇 초 단위로 스냅샷을 찍어 덤프 생성/혹은 행 측정' 로 수동으로 잡아낼 수도 있습니다.  덤프 까봐서 안에 스레드들 다 멈춰있는지 보면 되고,  덤프 내의 예외 원인이 applictaion hang으로 나오기도 합니다.
고급 모드, 성능 모니터에 나오는 성능 측정치 기준으로 모니터링할 수 있는 수준이 가능하면 수동으로 성능 측정치를 결정하여 수집합니다.	procdump 프로세스이름 -p "\Processor(_Total)\% Processor Time" 20	이 내용은, 실행파일이 프로세스화되었을 때  1. Processor(_Total) : 성능 모니터 임계치의 값 중  Processor(CPU Processor의 전체 Total)값이 20 이상, 10초 동안 진행될 시에 측정합니다.	고오급 모드  위의 내용들은 '성능 모니터'를 열어보면 각 값들을 알 수 있습니다.  그렇다면 보통,  성능모니터로 먼저 보고, 그 성능 모니터 기반에 의한 리포트를 활용하여 덤프 수집을 할 때 쓴다는 걸 알 수 있겠죠?
특정 핸들 갯수 넘을 때	procdump -ma 프로세스이름 -p "\Process(프로세스이름)\Handle Count" 핸들 갯수	특정 프로세스가 실행된 이후에 핸들 카운트가 지정된 숫자 만큼 이후 넘을 때	보통 메모리 릭이 생길 때 핸들에 의한 건 찾기가 좀 어려운데 이렇게 걸어놓고,  100개일 때 500개일 때 1000개일 때  하고 덤프 스냅샷들을 비교해보면 좋겠죠.
전 갑니다. 주인님, 핸들링 되지 않은 엑셉션이 발생했음에도 추적하고 싶을 때,  WER이 발생할 수도 있지만 사용자 프로세스는 그렇지 않을 수도 있어서 그럴 경우 겁니다.	procdump -mp -e 프로세스이름.exe	조용히 죽을 때 사용	windbg를 쓰면 exception list를 고를 수 있습니다.  이 경우에 걸리지 않을 때  windbg에서 '모든' 엑셉션을 걸어버리면 이것도 알아낼 수 있습니다. 대신 그럴 경우에 처리해놓은 엑셉션도 걸려버려서 귀찮음.