Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 3개 있습니다.)
(시리즈 글이 3개 있습니다.)
디버깅 기술: 39. DebugDiag 1.1을 사용한 덤프 분석
; https://www.sysnet.pe.kr/2/0/1026

디버깅 기술: 65. 프로세스 비정상 종료 시 "Debug Diagnostic Tool"를 이용해 덤프를 남기는 방법
; https://www.sysnet.pe.kr/2/0/1786

디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명
; https://www.sysnet.pe.kr/2/0/12067




프로세스 비정상 종료 시 "Debug Diagnostic Tool"를 이용해 덤프를 남기는 방법

일례로, w3wp.exe 프로세스가 원인도 모르게 죽는(crash) 경우가 있다면 어떻게 분석해야 할까요? 제가 생각할 수 있는 가장 좋은 방법은 풀 덤프를 뜨는 것입니다.

비정상 종료되는 경우가 일정한 규칙이 있고 해당 예외 타입을 알 수 있다면 procdump.exe를 이용해 쉽게 덤프를 뜰 수 있습니다. 이에 대해서는 저번에 한번 설명드렸죠? ^^

닷넷 응용 프로그램에서 특정 예외가 발생했을 때 풀 덤프받는 방법
; https://www.sysnet.pe.kr/2/0/1376

그런데, 말 그대로 비정상 종료를 해버리는 경우는 어떻게 덤프를 남겨야 할까요? 이를 위해 가장 쉬운 방법은 마이크로소프트에서 제공하는 "Debug Diagnostic Tool"을 사용하는 것입니다.

예를 들면서 한번 설명해 볼까요? ^^

닷넷 환경은 그런 경우가 많지 않기 때문에 최대한 실제 상황에 가깝도록 C/C++ Win32 DLL에서 crash를 발생시키는 예제를 만들어 보겠습니다. 우선, C/C++ 코드는 이렇게 구성하고,

#include "stdafx.h"
#include "Win32Project1.h"

DWORD WINAPI crashThread(LPVOID lpParameter)
{
    while (true)
    {
        HANDLE hWait = ::OpenEvent(SYNCHRONIZE, FALSE, L"test.event");
        if (hWait == NULL)
        {
            Sleep(1000);
            continue;
        }

        ::WaitForSingleObject(hWait, INFINITE); // "test.event"가 시그널되면!

        *((int*)0) = 0; // 비정상 종료!
    }

    return 0;
}

WIN32PROJECT1_API int _stdcall fnWin32Project1(void)
{
    HANDLE hHandle = ::CreateThread(NULL, 0, crashThread, NULL, 0, NULL);
    if (hHandle != NULL)
    {
        CloseHandle(hHandle);
    }

    return 42;
}

닷넷에서 P/Invoke를 이용해 fnWin32Project1 함수를 호출하는 페이지를 default.aspx로,

using System;
using System.Runtime.InteropServices;
using System.Threading;
using System.Web.UI;

namespace WebApplication1
{
    public partial class _Default : Page
    {
        [DllImport("Win32Project1.dll")]
        static extern int fnWin32Project1();

        public static EventWaitHandle _event = new EventWaitHandle(false, EventResetMode.ManualReset, "test.event");
        protected void Page_Load(object sender, EventArgs e)
        {
            fnWin32Project1();    
        }
    }
}

"test.event" 이벤트를 시그널하는 페이지를 about.aspx로 두겠습니다.

using System;
using System.Web.UI;

namespace WebApplication1
{
    public partial class About : Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            _Default._event.Set();
        }
    }
}

이 웹 응용 프로그램을 IIS에서 호스팅하고 default.aspx를 방문한 다음 이어서 about.aspx를 방문하면 w3wp.exe가 비정상 종료되면서 사라집니다. 이때의 이벤트 로그를 보면 비정상 종료되었다는 항목은 남지만 막상 오류의 원인을 파악하려면 막막하기만 합니다.




웹 서버가 이런 상황이면 정말 난감한데요. 이때 필요한 것이 바로 "Debug Diagnostic Tool"입니다. 다음의 경로에서 최신 버전을 다운로드 받고,

Debug Diagnostic Tool v2 Update 3
; https://www.microsoft.com/en-us/download/details.aspx?id=58210

시작 메뉴를 통해 "DebugDiag 2 Collection"을 실행하면 다음과 같이 "Rule Type"을 선택할 수 있는 창과 함께 프로그램이 실행됩니다.

howto_debug_diag_1.png

당연히, "Crash" 유형을 선택하고 "Next" 버튼을 누르면 이제 덤프를 남길 응용 프로그램 대상의 종류를 선택하는 창으로 이동합니다.

howto_debug_diag_2.png

여기서는 w3wp.exe를 감시할 텐데요. 이 중에서 문제가 발생한 웹 애플리케이션을 알고 있으므로 좀 더 범위를 좁히기 위해 "A specific IIS web application pool"을 선택했습니다. (여러분들은 개별 상황에 맞게 다른 타입을 선택하시면 됩니다.)

제 경우 "AppPool"을 선택했으므로 이제 어떤 AppPool을 감시해야 할지를 선택하게 되는데요. 저는 테스트로 구성한 웹 사이트가 "TestSite" AppPool에 있기 때문에 아래와 같이 선택했습니다.

howto_debug_diag_3.png

그리고 나오는 세부 항목 설정에서는 기본값으로 두고 넘어갑니다.

howto_debug_diag_4.png

참고로, 위의 설정에서 "Unconfigured First Chance Exceptions"는 가능한 선택하지 않는 것이 좋습니다. "First Chance Exception"은 상황에 따라 얼마든지 발생할 수 있기 때문에 이것을 켜두면 너무나 잦은 로그(또는 덤프)가 남게 되는데 별다르게 도움이 되지 않습니다. 그것보다는 우측 하단의 "Exceptions..."를 눌러 나오는 예외 종류를 세분화시켜서 선택하는 것이 더 도움이 될 수 있습니다.

하지만, 비정상 종료되는 지금의 상황에서는 굳이 선택할 필요는 없습니다. 이제 다음 단계로 넘어가면 "규칙(Rule)"의 이름과 해당 규칙이 적용되어 덤프 및 로그를 남겨야 하는 폴더를 지정할 수 있는 창이 나오는데요.

howto_debug_diag_5.png

자신의 상황에 맞게 지정해 주시면 됩니다. 그 다음은 해당 규칙을 활성화 시킬지를 묻는데,

howto_debug_diag_6.png

당연히 "Activate the rule now"를 선택합니다. 이 창을 마지막으로 "Finish" 버튼을 누르면 "Debug Diagnostic Tool" 프로그램의 "Rules" 탭에 방금 생성한 규칙이 활성화 된 것을 확인할 수 있습니다.

howto_debug_diag_7.png

일단, 이렇게 활성화시켰으면 이제 서버에서 로그아웃을 해도 됩니다. 왜냐하면 DbgSvc.exe라는 NT 서비스가 덤프 모니터링을 책임지기 때문에 굳이 서버에 연결되어 있을 필요가 없습니다. (오~~~ 운영 서버에서 언제 발생할지 모르는 crash 덤프를 남길 때 정말 필요한 기능입니다. ^^)

재미있는 점은, 크래시 모니터링 대상이 되는 w3wp.exe 프로세스 하나 당 DbgHost.exe 프로세스가 하나씩 대응된다는 점입니다. 그래서 WebGarden을 설정해 AppPool 하나에 3개의 작업자 프로세스가 실행하도록 구성한 경우라면 DbgSvc.exe 프로세스와 함께 3개의 DbgHost.exe가 함께 떠 있게 됩니다.

"Debug Diagnostic Tool"에 대해 제가 가장 마음에 드는 부분이 있는데요. 똑똑하게도 iisreset이나 작업관리자를 통해 강제 종료하는 경우는 덤프를 남기지 않는다는 특징이 있습니다. 이것 역시 운영 서버에서 제대로 된 crash 덤프를 선택하는데 정말 필요한 기능입니다. ^^




이렇게 구성한 상태에서, 예제 웹 응용 프로그램의 default.aspx, about.aspx를 차례대로 방문하면 c:\temp 폴더에 덤프 파일이 남게 됩니다. 이 덤프 파일이 있으면 어느 정도까지 도움이 될지 감이 잘 안 오실 텐데요.

대개의 경우 '빌드 서버'를 통해 웹 응용 프로그램을 빌드할 것이므로, 바로 그 빌드 서버에 설치된 Visual Studio 2013에서 "File" / "Open" / "Crash Dump..." 메뉴를 이용해 덤프 파일을 열면?

다음과 같이 정확하게 문제를 발생시킨 소스 코드 위치까지 보여주면서 디버깅 상태로 진입합니다.

howto_debug_diag_8.png

그야말로, 놀라운 디버깅 능력입니다! ^^

(첨부한 파일은 이 글의 예제 프로젝트를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2017-11-01 09시45분
[guest] 증권회사에서 제공하는 API중 COM 버전을 이용해서 프로그램을 개발하고 있습니다.

http://res.sysnet.pe.kr/sysnetimages/howto_debug_diag_2.png

위 링크 이미지의 선택창에서 A specific COM+ application 를 선택하면 되나요?
[guest]
2017-11-01 10시15분
[guest] "Debug Diagnostic Tool"에 대해 제가 가장 마음에 드는 부분이 있는데요. 똑똑하게도 iisreset이나 작업관리자를 통해 강제 종료하는 경우는 덤프를 남기지 않는다는 특징이 있습니다. "

부분을 적어 놓으셨는데요.

프로그램 코드 내에서 application.exit 또는 application.restart 하는것도 잡히지 않나요?
[guest]
2017-11-02 12시32분
첫 번째 질문은, 거기서 말하는 COM+ 응용 프로그램은 서버 유형으로 뜨는 독립 .exe COM+를 의미합니다. 따라서 일반 프로세스라면 그냥 "A specific process"를 선택하세요.

두 번째 질문은, 직접 해보시고 답을 달아주시면 되지 않을까요? ^^
정성태

... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12211정성태4/27/202019278개발 환경 구성: 486. WSL에서 Makefile로 공개된 리눅스 환경의 C/C++ 소스 코드 빌드
12210정성태4/20/202020728.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/202017426오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202015996Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202015853스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202018449오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202015115스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202015132스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202017965오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202021215개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202018456오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202018544VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/202016183오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202019539오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202018847VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202015967오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202018285.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202021005오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202017954개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202019983개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202021066개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202015651오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/202021251개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202026039Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202015628오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202017412오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...