프로세스 실행 중 작성된 덤프 파일에서 문제의 원인 분석

크래시로 발생된 덤프 파일은 일단 열어보면 크래시가 발생된 위치를 알 수 있으므로 해당 위치의 정보가 문제의 실마리가 될 수 있다.

그런데 프로세스가 실행되는 도중에 작성한 덤프 파일을 열면 그냥 실행 중인 코드의 어딘가에서 멈춰있을 뿐이다. 이 경우에는 스레드 창을 열어서 모든 스레드의 콜 스택을 확인해보면 기반 라이브러리의 함수라던가 직접 만든 함수라던가 dll 파일의 함수라던가 다양한 함수가 호출되고 있을 것이다.

만약 어떤 스레드의 콜 스택에서 기반 라이브러리의 함수 등 직접 만들지 않은 함수만 호출되고 있다면 아마도 직접 손을 댄 부분은 아닐 것이므로 문제의 원인은 아닐 것이라고 추측해 볼 수 있다. 어쩌면 기반 라이브러리가 직접 만든 코드를 호출하는 구조인데 우연히 기반 라이브러리의 코드로 돌아왔을때 덤프가 만들어진 것일 수도 있지만, 이런 경우에는 덤프를 한 번 이상 더 만들어보면 직접 만든 코드가 호출되고 있을지도 모른다. 될지 안될지는 알 수 없지만 정말 그런 경우가 있다면 해보는 수밖에 없다.

만약 어떤 스레드의 콜 스택에서 직접 만든 코드가 호출되고 있다면, 해당 함수의 코드를 확인해보면, 이 스레드가 지금 겪고있는 문제와 관련이 있는지 없는지 짐작정도는 해볼 수 있을 것이다. 보통은 이렇게 문제의 원인이 되는 부분이 어딘가의 스레드에서 호출이 되고 있을 것이다. 모든 스레드의 콜 스택을 확인해서 문제의 원인으로 짐작되는 코드를 찾아내서 변수의 상태 등을 확인해보면 된다. 만약 모든 스레드의 콜 스택의 모든 함수를 더블 클릭해서 모든 변수를 확인했는데도 잘 모르겠으면, 조사식 창에서 전역 변수나 싱글턴 객체등의 이름을 입력해서 해당 변수의 상태를 확인해보면 좋을 것이다. 문제의 원인이 될법한 유저 등의 ID 정보 등을 알고있다면 해당 정보를 기반으로 메모리 상의 변수의 상태를 확인해 볼 수 있을 것이다.