집 › 인터넷 › 메모리 덤프 분석을 위해 WinDBG를 설치하고 구성합니다. Windows 디버깅 도구: Windows용 BSOD 디버깅 도구 진단 및 수정

메모리 덤프 분석을 위해 WinDBG를 설치하고 구성합니다. Windows 디버깅 도구: Windows용 BSOD 디버깅 도구 진단 및 수정

심각한 오류가 발생하면 Windows 운영 체제가 충돌하고 BSOD(Blue Screen of Death)가 표시됩니다. 콘텐츠 랜덤 액세스 메모리발생한 오류에 대한 모든 정보는 스왑 파일에 기록됩니다. 다음번 윈도우 부팅 중크래시 덤프가 생성되었습니다. 디버깅 정보저장된 데이터를 기반으로 합니다. 시스템 이벤트 로그에 심각한 오류 항목이 생성됩니다.

주목! Windows 부팅 초기 단계에서 디스크 하위 시스템에 오류가 발생하거나 심각한 오류가 발생하면 크래시 덤프가 생성되지 않습니다.

Windows 크래시 덤프 유형

현재 운영 체제인 Windows 10을 예로 사용합니다( 윈도우 서버 2016) 시스템이 생성할 수 있는 주요 메모리 덤프 유형을 고려하세요.

미니 메모리 덤프(256KB). 이 파일 형식에는 최소한의 정보가 포함되어 있습니다. 여기에는 BSOD 오류 메시지, 드라이버에 대한 정보, 충돌 당시 활성 상태였던 프로세스, 충돌을 일으킨 프로세스 또는 커널 스레드만 포함됩니다.
커널 메모리 덤프. 일반적으로 크기가 작습니다(물리적 메모리 크기의 1/3). 커널 메모리 덤프는 미니 덤프보다 더 자세합니다. 여기에는 드라이버 및 커널 모드 프로그램에 대한 정보가 포함되어 있으며, Windows 커널 및 HAL(하드웨어 추상화 계층)에 할당된 메모리, 드라이버 및 기타 커널 모드 프로그램에 할당된 메모리가 포함됩니다.
메모리 덤프 완료. 가장 큰 크기이며 이 파일을 생성하는 데 Windows에서 필요한 1MB를 더한 시스템 RAM과 동일한 메모리가 필요합니다.
자동 메모리 덤프. 정보 측면에서는 커널 메모리 덤프에 해당합니다. 유일한 차이점은 덤프 파일을 만드는 데 사용되는 공간의 양입니다. 이 파일 형식은 Windows 7에는 존재하지 않았습니다. Windows 8에 추가되었습니다.
활성 메모리 덤프. 이 유형은 시스템 장애의 원인을 파악할 수 없는 요소를 제거합니다. 이는 Windows 10에 추가되었으며 가상 머신을 사용하거나 시스템이 Hyper-V 호스트인 경우 특히 유용합니다.

Windows에서 메모리 덤프를 활성화하는 방법은 무엇입니까?

Win+Pause를 사용하여 시스템 설정 창을 열고 " 추가 옵션시스템"(고급 시스템 설정). "에서 추가적으로"(고급), 섹션 ""(시작 및 복구) 버튼을 클릭하세요. " 옵션"(설정). 열리는 창에서 시스템 오류가 발생할 경우 수행할 작업을 구성합니다. 을 체크 해봐 " 시스템 로그에 이벤트 기록" (시스템 로그에 이벤트 기록) 시스템 충돌 시 생성되어야 하는 덤프 유형을 선택합니다. 확인란에 " 기존 덤프 파일 바꾸기"(기존 파일 덮어쓰기) 확인란을 선택하면 오류가 발생할 때마다 파일을 덮어씁니다. 이 상자를 선택 취소하는 것이 좋습니다. 그러면 분석을 위한 더 많은 정보를 얻을 수 있습니다. 자동으로 다시 시작도 비활성화합니다.

대부분의 경우 작은 메모리 덤프만으로도 BSOD의 원인을 분석할 수 있습니다.

이제 BSOD가 발생하면 덤프 파일을 분석하여 장애 원인을 찾을 수 있습니다. 미니 덤프는 기본적으로 %systemroot%\minidump 폴더에 저장됩니다. 덤프 파일을 분석하려면 프로그램을 사용하는 것이 좋습니다 WinDBG(마이크로소프트 커널 디버거).

Windows에 WinDBG 설치

공익사업 WinDBG포함 된 " 윈도우 10 SDK"(윈도우 10 SDK). .

파일 이름은 다음과 같습니다. Winsdksetup.exe, 크기 1.3MB.

설치를 실행하고 정확히 원하는 작업을 선택하세요. 이 컴퓨터에 패키지를 설치하거나 다른 컴퓨터에 설치하기 위해 다운로드하세요. 로컬 컴퓨터에 패키지를 설치해 보겠습니다.

전체 패키지를 설치할 수 있지만 디버깅 도구만 설치하려면 Windows용 디버깅 도구.

설치 후 시작 메뉴에서 WinDBG 바로가기를 찾을 수 있습니다.

.dmp 파일과 WinDBG의 연결 설정

덤프 파일을 열려면 간단한 클릭으로, .dmp 확장자를 WinDBG 유틸리티에 매핑합니다.

열려 있는 명령줄관리자 권한으로 64비트 시스템용 명령을 실행합니다: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
windbg.exe -IA
32비트 시스템의 경우:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
windbg.exe -IA
결과적으로 .DMP, .HDMP, .MDMP, .KDMP, .WEW 파일 형식이 WinDBG에 매핑됩니다.

WinDBG에서 디버깅 기호 서버 설정

디버깅 기호(디버그 기호 또는 기호 파일)는 실행 파일과 함께 프로그램을 컴파일하는 동안 생성된 데이터 블록입니다. 이러한 데이터 블록에는 함수, 라이브러리 등이라는 변수 이름에 대한 정보가 포함되어 있습니다. 이 데이터는 프로그램을 실행할 때 필요하지 않지만 디버깅할 때 유용합니다. Microsoft 구성 요소는 Microsoft 기호 서버를 통해 배포된 기호로 컴파일됩니다.

WinDBG를 다음과 같이 구성합니다. 마이크로소프트 사용기호 서버:

WinDBG를 엽니다.
메뉴로 이동 파일 –> 기호 파일 경로;
Microsoft 웹사이트에서 디버깅 기호를 다운로드하기 위한 URL과 캐시를 저장하기 위한 폴더를 포함하는 줄을 작성합니다. SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols 이 예에서는 캐시가 다운로드됩니다. E:\Sym_WinDBG 폴더에 어떤 항목이든 표시할 수 있습니다.
메뉴 변경 사항을 저장하는 것을 잊지 마세요 파일–>WorkSpace를 저장하세요.

WinDBG는 로컬 폴더에서 기호를 검색하고, 필요한 기호를 찾지 못한 경우 지정된 사이트에서 기호를 자동으로 다운로드합니다. 자신만의 기호 폴더를 추가하려면 다음과 같이 할 수 있습니다.

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

인터넷에 연결되어 있지 않으면 먼저 Windows 기호 패키지 리소스에서 기호 패키지를 다운로드하세요.

WinDBG의 크래시 덤프 분석

WinDBG 디버거는 덤프 파일을 열고 로컬 폴더나 인터넷에서 디버깅에 필요한 기호를 다운로드합니다. 이 프로세스 중에는 WinDBG를 사용할 수 없습니다. 창 하단(디버거 명령줄)에 메시지가 나타납니다. 디버그 대상이 연결되지 않았습니다.

명령은 창 하단에 있는 명령줄에 입력됩니다.

주의해야 할 가장 중요한 것은 오류 코드입니다. 오류 코드는 항상 16진수로 표시되며 다음과 같은 형식을 갖습니다. 0xXXXXXXXX(옵션 중 하나에 표시됨 - STOP: , 07/02/2019 0008F, 0x8F). 이 예에서 오류 코드는 0x139입니다.

디버거는!analyze -v 명령을 실행하도록 제안합니다. 링크 위에 마우스를 놓고 클릭하기만 하면 됩니다. 이 명령은 무엇을 위한 것인가요?

예비 메모리 덤프 분석을 수행하고 다음을 제공합니다. 자세한 정보분석을 시작합니다.
이 명령은 오류의 STOP 코드와 기호 이름을 표시합니다.
충돌을 일으킨 명령 호출의 스택을 보여줍니다.
또한 IP 주소, 프로세스 및 등록 오류가 여기에 표시됩니다.
팀은 문제 해결을 위해 미리 준비된 권장 사항을 제공할 수 있습니다.

!analyze –v 명령 실행 후 분석 시 주의해야 할 주요 사항(목록 미완성).

1: kd> !분석 -v

* *
* 버그체크 분석 *
* *
*****************************************************************************
STOP 오류의 상징적 이름(BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
오류에 대한 설명(커널 구성 요소가 중요한 데이터 구조를 손상시켰습니다. 이러한 손상으로 인해 잠재적으로 공격자가 이 시스템을 제어할 수 있게 될 수 있습니다):

커널 구성 요소가 중요한 데이터 구조를 손상시켰습니다. 손상으로 인해 잠재적으로 악의적인 사용자가 이 시스템을 제어할 수 있습니다.
오류 인수:

인수:
Arg1: 0000000000000003, LIST_ENTRY가 손상되었습니다(예: 이중 제거).
Arg2: ffffd0003a20d5d0, 버그 체크를 발생시킨 예외에 대한 트랩 프레임의 주소
Arg3: ffffd0003a20d528, 버그 체크를 일으킨 예외에 대한 예외 레코드의 주소
Arg4: 0000000000000000, 예약됨
디버깅 세부정보:
------------------

카운터에는 유사한 오류로 인해 시스템이 충돌한 횟수가 표시됩니다.

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

단축 형식의 STOP 오류 코드:

BUGCHECK_STR: 0x139

오류가 발생한 프로세스(반드시 오류의 원인은 아니며 오류가 발생한 당시 이 프로세스가 메모리에서 실행 중임):

PROCESS_NAME: sqlservr.exe

오류 코드 설명: 시스템은 이 응용 프로그램에서 스택 버퍼 오버플로를 감지했습니다. 이로 인해 공격자가 이 응용 프로그램을 제어할 수 있습니다.

ERROR_CODE: (NTSTATUS) 0xc0000409 - 시스템이 이 응용 프로그램에서 스택 기반 버퍼의 오버런을 감지했습니다. 이러한 오버런으로 인해 악의적인 사용자가 이 응용 프로그램을 제어할 수 있는 가능성이 있습니다.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - 시스템이 이 응용 프로그램에서 스택 기반 버퍼의 오버런을 감지했습니다. 이러한 오버런으로 인해 악의적인 사용자가 이 응용 프로그램을 제어할 수 있는 가능성이 있습니다.

스택의 마지막 호출:

LAST_CONTROL_TRANSFER: fffff8040117d6a9에서 fffff8040116b0a0까지

실패 시 호출 스택:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? ::FNODOBFM::`문자열"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600: nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiSystemServiceCopyEnd+0x1 3
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x00007ffb`47530 7다

오류가 발생한 코드 섹션:

후속 조치_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov 바이트 ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: 기계 소유자

커널 개체 테이블에 있는 모듈의 이름입니다. 분석기가 감지할 수 있는 경우 문제가 있는 운전자, 이름은 MODULE_NAME 및 IMAGE_NAME 필드에 표시됩니다.

MODULE_NAME:nt
IMAGE_NAME: ntkrnlmp.exe

1: kd> lmvm nt
전체 모듈 목록 찾아보기
로드된 기호 이미지 파일: ntkrnlmp.exe
매핑된 메모리 이미지 파일: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
이미지 경로: ntkrnlmp.exe
이미지 이름: ntkrnlmp.exe
내부 이름: ntkrnlmp.exe
원본파일명 : ntkrnlmp.exe
제품버전: 6.3.9600.18946
파일 버전: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

주어진 예에서 분석은 커널 파일 ntkrnlmp.exe를 가리켰습니다. 메모리 덤프 분석이 시스템 드라이버(예: win32k.sys) 또는 커널 파일(예: ntkrnlmp.exe)을 가리킬 가능성이 가장 높습니다. 이 파일문제의 원인은 아닙니다. 장치 드라이버에 문제가 있는 경우가 종종 있습니다. BIOS 설정또는 장비 오작동.

BSOD가 타사 드라이버로 인해 발생한 것으로 확인되면 해당 이름이 MODULE_NAME 및 IMAGE_NAME 값에 표시됩니다.

예를 들어:

이미지 경로: \SystemRoot\system32\drivers\cmudaxp.sys
이미지 이름: cmudaxp.sys

드라이버 파일의 속성을 열고 버전을 확인하세요. 대부분의 경우 드라이버 문제는 업데이트를 통해 해결됩니다.

2010년 6월 22일

이전에는 Windbg를 별도로 다운로드할 수 있었습니다. 그러나 최신 버전의 경우 Microsoft는 이를 Windows SDK의 일부로 유지합니다. 아래의 다운로드 링크를 찾아주세요.

윈도우 10

Windows 7용 Windbg의 최신 버전은 https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk 링크에서 다운로드할 수 있습니다.

윈도우 7

위 링크에서 설치 프로그램을 다운로드하세요. 이는 전체 SDK를 다운로드하는 것이 아니라 단지 설치 프로그램일 뿐이라는 점에 유의하세요. 파일을 실행하고 나면, 당신은 할 수다운로드할 도구를 선택하세요. Windbg에만 관심이 있는 경우 다른 모든 항목을 제외하고 '공용 유틸리티'에서 '디버깅 도구'만 선택할 수 있습니다.

위 패키지는 windbg 6.12 버전을 설치합니다. windbg를 빠르게 설치하려면 다음에서 다운로드할 수 있는 이전 버전(6.11)을 사용할 수 있습니다.
이 게시물 끝에 제공된 링크.

설치를 완료하면 시작 메뉴 -> 모든 프로그램 -> Windows용 디버깅 도구 -> Windbg에서 프로그램을 찾을 수 있습니다.

WinDBG 소개 - 1부

알렉산더 안티포프

WinDBG는 훌륭한 디버거입니다. 매우 사용자 친화적인 인터페이스가 없을 수 있으며 기본적으로 검은색 배경이 없지만 현재 Windows OS에서 가장 강력하고 안정적인 디버거 중 하나입니다. 이 기사에서는 WinDBG를 시작할 수 있도록 WinDBG의 기본 사항을 소개합니다.

이것은 WinDBG에 관한 시리즈의 첫 번째 기사입니다. 이 시리즈에 포함된 모든 기사 목록:

파트 1 - 설치, 인터페이스, 기호, 원격/로컬 디버깅, 도움말 시스템, 모듈, 레지스터.
2부 - 중단점.
3부 – 메모리 검사, 단계별 프로그램 디버깅, 팁과 요령.

이 글에서는 설치와 프로세스 연결을 살펴보고, 다음 글에서는 중단점, 단계별 디버깅, 메모리 검사를 살펴보겠습니다.

WinDBG 설치

Windows 7과 비교하여 Windows 8의 WinDBG 설치 프로세스는 약간의 변경을 거쳤습니다. 이 섹션에서는 두 가지 모두에 대한 디버거 설치를 살펴보겠습니다. 운영체제.

Windows 8에 WinDBG 설치

Windows 8에서는 WinDBG가 WDK(Windows 드라이버 키트)에 포함되어 있습니다. Visual Studio 및 WDK를 설치하거나 WinDBG가 포함된 Windows 8.1용 디버깅 도구 패키지를 별도로 설치할 수 있습니다.

설치 프로그램은 WinDBG를 로컬로 설치할지 아니면 다른 컴퓨터용 전체 개발 패키지를 다운로드할지 묻습니다. 후자는 본질적으로 동등하다 오프라인 설치 프로그램, 나중에 다른 시스템에 패키지를 설치하려는 경우 매우 편리합니다.

그림 1: 설치 유형 선택

다음 창에서 "Windows용 디버깅 도구"를 제외한 모든 항목을 선택 취소하고 "다운로드" 버튼을 클릭해야 합니다.

설치 프로그램이 작업을 마치면 패키지를 다운로드한 디렉터리(기본적으로 c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK)로 이동하여 설치 절차를 진행합니다.

Windows 7 및 이전 버전에 WinDBG 설치

Windows 7 이하의 경우 WinDBG는 Windows SDK 및 .Net Framework에 포함된 "Windows용 디버깅 도구" 패키지의 일부입니다. 설치 프로그램을 다운로드한 다음 설치 프로세스 중에 "Windows용 디버깅 도구"를 선택해야 합니다.

설치하는 동안 "재배포 가능 패키지" 아래의 "디버깅 도구" 옵션을 선택하여 향후 설치를 더 쉽게 하기 위해 독립 실행형 설치 프로그램을 생성했습니다.

그림 2: 독립형 설치 프로그램을 생성하기 위한 설치 옵션 선택

설치가 완료되면 다양한 플랫폼용 WinDBG 설치 프로그램이 있어야 합니다(c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ 디렉터리에 있음).

그림 3: 다양한 플랫폼용 WinDBG 설치 프로그램이 포함된 폴더

WinDBG 인터페이스

그림 4: WinDBG 외관

처음 봐요 모습 WinDGB를 사용하면 디버거가 놀라울 정도로 간단하다는 것을 알게 될 것입니다. 대부분의 WinDBG 기능은 프로세스 디버깅 중에 학습됩니다. 인터페이스를 설명하는 데 시간을 소비하는 대신 다음 섹션에서는 가장 중요한 사항만 다루겠습니다.

디버거 인터페이스에 대해 알아야 할 가장 기본적인 사항은 두 영역으로 구성된 명령 창입니다. 첫 번째 영역: 명령 실행 결과가 표시되는 창입니다. 두 번째 영역: 명령을 입력하기 위한 작은 텍스트 필드입니다.

그림 5: WinDBG 명령 창

기호

대부분의 경우 WinDBG는 특별한 설정이 필요하지 않으며 기본적으로 올바르게 작동합니다. 하지만 구성해야 할 중요한 것 중 하나는 캐릭터입니다. 기호는 프로그램이 컴파일될 때 실행 파일과 함께 생성되는 파일이며 디버깅 정보(함수 및 변수 이름)를 포함합니다. 디버그 정보를 사용하면 디버깅하거나 분해하는 동안 애플리케이션의 기능을 검사할 수 있습니다. 많은 Microsoft 구성 요소는 Microsoft 기호 서버를 통해 배포되는 기호로 컴파일됩니다. 나머지 실행 파일의 경우 모든 것이 그다지 장밋빛이 아닙니다. 디버그 정보가 포함된 파일이 애플리케이션에 포함되는 경우는 거의 없습니다. 대부분의 경우 회사는 그러한 정보에 대한 접근을 제한합니다.

Microsoft 기호 서버를 사용하도록 WinDBG를 구성하려면 파일:기호 파일 경로로 이동하여 경로를 SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols로 설정합니다. 물론 별표를 구분 기호로 사용하는 것은 조금 이상합니다. Microsoft 기호 서버를 설정하면 기호가 C:\Symbols 폴더에 다운로드됩니다.

그림 6: Microsoft 기호 서버 설정

WinDBG는 필요할 때 바이너리 파일에 대한 기호를 자동으로 로드합니다. 다음과 같이 자신만의 기호 폴더를 추가할 수도 있습니다.

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder

디버깅하는 동안 기호 추가

디버깅하는 동안 기호를 가져와야 하는 경우 .sympath를 사용하여 이를 수행할 수 있습니다(프로세스에 연결하면 명령 창이 나타납니다). 예를 들어 c:\SomeOtherSymbolFolder 폴더를 추가하려면 다음 명령을 입력합니다.

0:025> .sympath+ c:\SomeOtherSymbolFolder
기호 검색 경로는 SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder입니다.
확장된 기호 검색 경로는 srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder입니다.

경로를 추가하거나 변경한 후 기호를 다시 로드하는 것이 좋습니다.

0:025> .다시 로드
현재 모듈을 다시 로드하는 중
................................................................
...............................................

로드된 기호 확인

어떤 모듈에 기호가 로드되어 있는지 확인하려면 x*!명령을 사용할 수 있습니다. WinDBG는 필요한 경우에만 기호를 로드하지만 x*! 로드할 수 있는 기호가 표시됩니다. ld * 명령을 사용하여 기호를 강제로 로드할 수 있습니다(이 작업은 시간이 걸릴 수 있으며 Debug:Break로 이동하여 프로세스를 중지할 수 있습니다).

이제 각 모듈의 기호를 볼 수 있습니다.

그림 8: 기호 목록

로컬 프로세스 디버깅

로컬 프로세스를 디버깅할 때 다음 두 가지 옵션이 있습니다.

이미 실행 중인 프로세스에 연결합니다.
WinDBG를 통해 프로세스를 시작하십시오.

각 방법에는 고유한 장점과 단점이 있습니다. 예를 들어 WinDBG를 통해 프로그램을 실행하는 경우 애플리케이션 충돌을 일으킬 수 있는 일부 특수 디버깅 옵션(예: 힙 디버깅)에 액세스할 수 있습니다. 반면에 디버거를 연결하면 충돌이 발생하는 프로그램도 있습니다. 일부 애플리케이션(특히 맬웨어)은 시작 중에 시스템에 디버거가 있는지 확인하므로 이 경우 이미 실행 중인 프로세스를 유지하는 것이 좋습니다. 시작 중에 일부 매개변수를 설정하는 Windows 서비스를 디버깅하는 경우가 있으므로 디버깅 프로세스를 단순화하려면 디버거를 통해 서비스를 실행하는 것보다 실행 중인 프로세스에 연결하는 것이 더 좋습니다. 일부 사람들은 디버거를 통해 프로세스를 실행하면 성능에 심각한 영향을 미친다고 주장합니다. 즉, 두 가지를 모두 시도해보고 가장 적합한 것을 선택하십시오. 어떤 이유로 특정 방법을 선호한다면 댓글로 여러분의 생각을 공유해 주세요!

프로세스 시작

로컬로 실행되고 네트워크와 통신하지 않는 독립 실행형 애플리케이션을 디버깅하는 경우 WinDBG를 통해 실행할 수 있습니다. 그러나 이는 이미 실행 중인 프로세스에 연결할 수 없다는 의미는 아닙니다. 귀하에게 가장 편리한 방법을 선택하십시오.

프로세스를 시작하는 것은 어렵지 않습니다. "파일:실행 파일 열기"로 이동하여 디버깅하려는 실행 파일을 선택합니다. 인수를 지정하거나 시작 디렉터리를 설정할 수도 있습니다.

그림 9: 선택 실행 가능 파일디버깅을 위해

프로세스 연결

이미 실행 중인 프로세스에 연결하는 것도 어렵지 않습니다. 그러나 어떤 경우에는 디버깅하려는 정확한 프로세스를 찾는 데 시간이 걸릴 수 있습니다. 예를 들어 일부 브라우저에서는 하나의 상위 프로세스를 만든 다음 각 탭에 대해 여러 개의 추가 프로세스를 만듭니다. 따라서 디버깅 중인 크래시 덤프에 따라 상위 프로세스가 아닌 탭과 연결된 프로세스에 연결하고 싶을 수도 있습니다.

이미 실행 중인 프로세스에 연결하려면 "파일:프로세스에 연결"로 이동한 다음 프로세스의 PID 또는 이름을 선택합니다. 프로세스에 참여하려면 적절한 권한이 있어야 한다는 점을 기억하세요.

그림 10: 연결할 프로세스 선택

연결 후 애플리케이션이 작동을 일시 중지하는 경우 해당 상자를 선택하여 "Noninvaise" 모드를 사용할 수 있습니다.

원격 프로세스 디버깅

때로는 원격 시스템에서 프로세스를 디버깅해야 할 수도 있습니다. 로컬 디버거를 사용하는 것보다 로컬 디버거를 사용하여 이 문제를 해결하는 것이 훨씬 더 편리할 것입니다. 가상 기기또는 RDP. 또는 시스템이 잠겨 있을 때만 액세스할 수 있는 LoginUI.exe 프로세스를 디버깅하고 있을 수도 있습니다. 이와 같은 상황에서는 로컬 버전의 WinDBG를 사용하여 원격으로 프로세스에 연결할 수 있습니다. 이러한 문제를 해결하는 가장 일반적인 두 가지 방법이 있습니다.

기존 디버그 세션

이미 로컬에서 프로그램 디버깅을 시작한 경우(WinDBG를 통해 프로세스를 연결하거나 실행하여) 특정 명령을 입력하면 WinDBG는 원격 디버거가 연결할 수 있는 "리스너"를 시작합니다. 이렇게 하려면 .server 명령을 사용하십시오.

서버 TCP:포트=5005

위의 명령을 실행한 후 다음과 같은 경고가 표시될 수 있습니다.

그림 11: 리스너를 생성하는 명령을 실행한 후 나타날 수 있는 경고 메시지

그러면 WinDBG는 서버가 실행 중이라고 보고합니다.

0:005> .server tcp:port=5005
0: -원격 TCP:포트=5005,서버=USER-PC

이제 "파일:원격 세션에 연결"로 이동하여 텍스트 필드에 다음과 같은 내용을 입력하여 원격 호스트에서 기존 디버그 세션에 연결할 수 있습니다: tcp:Port=5005,Server=192.168.127.138

그림 12: 디버그 세션에 대한 원격 연결

연결되면 원격 클라이언트에서 확인 메시지를 받게 됩니다.

서버가 시작되었습니다. 클라이언트는 다음 명령줄 중 하나로 연결할 수 있습니다.
0: -원격 TCP:포트=5005,서버=USER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) 2013년 12월 16일 월요일 09:03:03에 연결됨

디버거 로컬 버전의 메시지는 다음과 같습니다.

MACHINENAME\User (tcp 192.168.127.138:13334) 2013년 12월 16일 월요일 09:03:03에 연결됨

원격 서버 생성

WinDBG를 사용하여 별도의 서버를 생성하고 원격으로 연결한 후 디버깅할 프로세스를 선택할 수도 있습니다. 이는 프로세스를 디버그하려는 dbgsrv.exe 파일을 사용하여 수행할 수 있습니다. 이러한 서버를 시작하려면 다음 명령을 실행하십시오.

dbgsrv.exe -t tcp:포트=5005

그림 13: 원격 서버 시작

이번에도 다음 사항을 수락해야 한다는 보안 경고가 표시될 수 있습니다.

그림 14: 디버그 서버 시작 중에 나타날 수 있는 보안 메시지

파일: 원격 스텁에 연결로 이동하고 텍스트 필드에 다음 줄을 입력하여 디버그 서버에 연결할 수 있습니다. tcp:포트=5005,서버=192.168.127.138

그림 15: 디버그 서버에 연결

일단 연결되면 연결되었다는 신호를 받지 못하지만, “파일:프로세스에 연결”로 이동하면 디버그 서버 프로세스(dbgsrv.exe가 실행 중인) 목록을 볼 수 있습니다. 이제 로컬에서 수행하는 것처럼 프로세스에 연결할 수 있습니다.

도움말 시스템

WinDBG의 도움말 시스템은 훌륭합니다. 새로운 것을 배우는 것 외에도 명령에 대한 배경 정보를 얻을 수 있어야 합니다. .hh 명령을 사용하여 WinDBG 도움말에 액세스합니다.

특정 명령에 대한 도움말 정보를 얻을 수도 있습니다. 예를 들어, .reload 명령에 대한 도움말을 보려면 다음 명령을 사용하십시오.

바람bg> .hh .reload

아니면 도움말:목차 섹션으로 이동하세요.

모듈

프로그램이 실행되는 동안 애플리케이션의 기능을 제공하기 위해 다양한 모듈을 가져옵니다. 따라서 애플리케이션이 어떤 모듈을 가져왔는지 알면 해당 애플리케이션이 어떻게 작동하는지 더 잘 이해할 수 있습니다. 대부분의 경우 실행 파일 자체가 아닌 프로그램이 로드한 특정 모듈을 디버깅하게 됩니다.

프로세스에 연결되면 WinDBG는 로드된 모듈을 자동으로 표시합니다. 예를 들어, 다음은 calc.exe에 연결한 후의 모듈입니다.

Microsoft(R) Windows 디버거 버전 6.12.0002.633 X86
저작권 (c) 마이크로소프트 주식회사. 판권 소유.

*** 보류 중인 첨부 파일을 기다리세요.
기호 검색 경로는 SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols입니다.
실행 가능한 검색 경로는 다음과 같습니다.
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
모드로드: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
모드로드: 77550000 77624000 C:\Windows\system32\kernel32.dll
모드로드: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
모드로드: 76410000 77059000 C:\Windows\system32\SHELL32.dll
모드로드: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
모드로드: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
모드로드: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
모드로드: 777b0000 777ba000 C:\Windows\system32\LPK.dll
모드로드: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
모드로드: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
모드로드: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
모드로드: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
모드로드: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
모드로드: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
모드로드: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
모드로드: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
모드로드: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll

나중에 디버깅 프로세스에서 lmf 명령을 사용하여 이 목록을 다시 표시할 수 있습니다.

0:005>lmf
시작 끝 모듈 이름
00a70000 00b30000 계산 C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
Controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 버전 C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 커널베이스 C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000 LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

"lmf m" 명령을 사용하여 특정 모듈의 로딩 주소를 찾을 수도 있습니다.

0:005> lmf m kernel32
시작 끝 모듈 이름
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

또한!dh 확장자를 사용하여 특정 모듈의 이미지 헤더에 대한 정보를 얻을 수도 있습니다( 느낌표확장자를 나타냅니다):

0:005> !dh 커널32

파일 유형: DLL
파일 헤더 값
14C 머신(i386)
섹션 수 4개
4A5BDAAD 시간 날짜 스탬프 2009년 7월 13일 월요일 21:09:01

0 심볼 테이블에 대한 파일 포인터
0개의 기호
선택적 헤더의 E0 크기
2102 특성
실행 가능
32비트 워드 머신
DLL

선택적 헤더 값
10B마법#
9.00 링커 버전
C4600 코드 크기
초기화된 데이터의 C800 크기
초기화되지 않은 데이터의 크기가 0입니다.
510C5 진입점 주소
1000 기본 코드
----- 새로운 -----
77550000 이미지 베이스
1000 섹션 정렬
200 파일 정렬
3개 하위 시스템(Windows CUI)
6.01 운영 체제 버전
6.01 이미지 버전
6.01 하위 시스템 버전
D4000 이미지 크기
헤더 크기 800
D5597 체크섬
00040000 스택 예비 크기
00001000 스택 커밋 크기
00100000 힙 예약 크기
00001000 힙 커밋 크기
140 DLL 특성
다이나믹 베이스
NX 호환
B4DA8 [ A915] 내보내기 디렉토리 주소
BF6C0 [ 1F4] 가져오기 디렉터리 주소
C7000 [520] 리소스 디렉토리 주소
0 [ 0] 예외 디렉터리 주소
0 [ 0] 보안 디렉터리 주소
C8000 [B098] 기지 재배치 디렉토리 주소
C5460 [ 38] 디버그 디렉토리 주소
0 [ 0] 설명 디렉터리의 주소
0 [ 0] 특수 디렉토리의 주소
0 [ 0] 스레드 저장 디렉토리의 주소
816B8 [ 40] 로드 구성 디렉터리의 주소
278 [408] Bound Import Directory 주소
1000 [DE8] 가져오기 주소 테이블 디렉터리의 주소
0 [ 0] 지연 가져오기 디렉터리 주소
0 [ 0] COR20 헤더 디렉토리의 주소
0 [ 0] 예약된 디렉터리의 주소

섹션 헤더 #1
.텍스트 이름
C44C1 가상 크기
1000 가상 주소
원시 데이터의 C4600 크기
원시 데이터에 대한 800 파일 포인터

재배치 횟수 0
0 줄 번호
60000020 플래그
암호
(정렬이 지정되지 않음)
읽기 실행

디버그 디렉터리(2)
유형 크기 주소 포인터
이력서 25 c549c c4c9c 형식: RSDS, guid, 2, kernel32.pdb
(10) 4c5498c4c98

섹션 헤더 #2
.데이터 이름
FEC 가상 크기
C6000 가상 주소
E00 원시 데이터 크기
원시 데이터에 대한 C4E00 파일 포인터
재배치 테이블에 대한 파일 포인터가 0개입니다.
줄 번호에 대한 파일 포인터가 0개입니다.
재배치 횟수 0
0 줄 번호
C0000040 플래그
초기화된 데이터
(정렬이 지정되지 않음)
읽기 쓰기

섹션 헤더 #3
.rsrc 이름
520 가상 크기
C7000 가상 주소
600 크기의 원시 데이터
원시 데이터에 대한 C5C00 파일 포인터
재배치 테이블에 대한 파일 포인터가 0개입니다.
줄 번호에 대한 파일 포인터가 0개입니다.
재배치 횟수 0
0 줄 번호
40000040 플래그
초기화된 데이터
(정렬이 지정되지 않음)
읽기 전용

섹션 헤더 #4
.reloc 이름
B098 가상 크기
C8000 가상 주소
원시 데이터의 B200 크기
원시 데이터에 대한 C6200 파일 포인터
재배치 테이블에 대한 파일 포인터가 0개입니다.
줄 번호에 대한 파일 포인터가 0개입니다.
재배치 횟수 0
0 줄 번호
42000040 플래그
초기화된 데이터
폐기 가능
(정렬이 지정되지 않음)
읽기 전용

메시지 및 예외

프로세스에 연결하면 먼저 모듈 목록이 표시된 다음 다른 메시지가 나타날 수 있습니다. 예를 들어, calc.exe에 연결하면 WinDBG는 자동으로 중단점(단순히 응용 프로그램을 중지하는 데 사용되는 마커)을 설정합니다. 중단점 정보가 화면에 표시됩니다.

(da8.b44): 중단 명령 예외 - 코드 80000003(첫 번째 기회)

이 특정 메시지는 예외, 즉 첫 번째 예외입니다. 기본적으로 예외는 프로그램 실행 중에 발생하는 특별한 조건입니다. 첫 번째 예외는 예외가 발생한 직후 프로그램이 중지되었음을 의미합니다. 두 번째 예외는 예외가 발생한 후 일부 작업이 수행되고 프로그램이 작동을 멈추는 것을 의미합니다.

레지스터

디버거는 메시지와 예외를 표시한 후 프로세서 레지스터의 상태를 표시합니다. 레지스터는 작은 정보 조각을 저장하거나 메모리의 상태를 모니터링하는 프로세서 내부의 특수 변수입니다. 프로세서는 이러한 레지스터의 정보를 매우 빠르게 처리할 수 있습니다. 이는 매번 RAM에서 버스를 통해 정보를 얻는 것보다 훨씬 빠릅니다.

calc.exe에 연결한 후 WinDBG는 다음 레지스터에 대한 정보를 자동으로 표시합니다.

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

나중에 r 명령을 사용하여 이 정보를 다시 복제할 수 있습니다.

0:005>r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540cc 정수 3

특정 레지스터의 값을 얻으려면 다음 명령을 실행할 수 있습니다.

0:005> r eax
eax=7ffd9000

다음과 같이 여러 레지스터에서 동시에 정보를 얻을 수 있습니다.

0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8

지시사항에 대한 포인터

마지막 명령은 실행 지침에 관한 것입니다. 여기에서는 r 명령의 경우처럼 EIP 레지스터에 포함된 내용에 대한 정보도 화면에 표시됩니다. EIP는 프로세서가 실행할 다음 명령의 위치를 포함하는 레지스터입니다. WinDBG가 표시하는 것은 u eip L1 명령과 동일합니다. 그 후 WinDBG는 EIP 레지스터에 지정된 주소로 이동하여 이 섹션을 어셈블리 코드로 변환하여 화면에 표시합니다.

ntdll!DbgBreakPoint:
77663540cc 정수 3

연락을 유지하다

향후 기사에서는 중단점, 단계별 디버깅, 메모리 검색 등 현장에서 WinDBG를 사용하는 방법을 살펴보겠습니다. 전환하지 마십시오! 제이.

Windows용 디버깅 도구- 운영 코드 디버깅 도구 윈도우 시스템. 이는 사용자 모드 및 커널 모드 코드(응용 프로그램, 드라이버, 서비스, 커널 모듈) 디버깅을 위해 설계된 Microsoft의 무료 배포 프로그램 세트입니다. 툴킷에는 콘솔 및 GUI 모드 디버거, 기호 작업을 위한 유틸리티, 파일, 프로세스 및 원격 디버깅을 위한 유틸리티가 포함되어 있습니다. 툴킷에는 다양한 시스템 구성 요소의 오류 원인을 찾는 데 사용할 수 있는 유틸리티가 포함되어 있습니다. Windows용 디버깅 도구특정 시점부터 독립 실행형 배포 형태로 다운로드할 수 없으며 Windows SDK(Windows 소프트웨어 개발 키트)의 일부입니다. 악기 세트 윈도우 도구 SDK는 MSDN 구독 프로그램의 일부로 제공되거나 msdn.microsoft.com에서 별도의 배포판으로 무료로 다운로드할 수 있습니다. 개발자에 따르면 최신이자 가장 현재 버전 Windows용 디버깅 도구는 Windows SDK에 특별히 포함되어 있습니다.

Windows용 디버깅 도구는 자주 업데이트되어 공개적으로 제공되며 이 프로세스는 운영 체제 릴리스에 전혀 의존하지 않습니다. 따라서 정기적으로 새 버전을 확인하십시오.

이제 특히 디버깅 도구가 무엇인지 살펴보겠습니다. 마이크로소프트 윈도우:

로컬 애플리케이션, 서비스, 드라이버 및 커널을 디버그합니다.
네트워크를 통해 원격 애플리케이션, 서비스, 드라이버 및 커널을 디버깅합니다.
실행 중인 애플리케이션을 실시간으로 디버그합니다.
애플리케이션, 커널 및 시스템의 메모리 덤프 파일을 전체적으로 분석합니다.
x86/x64/Itanium 아키텍처 기반 시스템으로 작업합니다.
사용자 모드 및 커널 모드 프로그램을 디버그합니다.

사용 가능한 Windows용 디버깅 도구 버전은 32비트 x86, Intel Itanium, 64비트 x64입니다. x86 또는 x64 중 두 가지가 필요합니다.

Windows용 디버깅 도구를 설치하는 방법에는 여러 가지가 있습니다. 이 문서에서는 주요 방법만 고려합니다.

웹 설치 프로그램을 통해 설치.
ISO에서 Windows용 디버깅 도구 설치 Windows 이미지 SDK.
dbg_amd64.msi / dbg_x86.msi 패키지에서 직접 Windows용 디버깅 도구를 설치합니다.

어떤 시점에서 내 컴퓨터에 디버깅 도구를 설치해야 하는지 불분명합니다. 종종 작업 환경에 간섭이 매우 바람직하지 않은 상황에 직면하게 됩니다! 더욱이 새 제품을 설치하는 것, 즉 레지스트리/시스템 파일을 변경하는 것은 완전히 용납되지 않을 수 있습니다. 예로는 업무상 중요한 서버가 있습니다. 개발자가 설치가 필요 없는 휴대용 버전의 응용 프로그램 옵션을 고려하지 않는 이유는 무엇입니까?
버전에 따라 Windows용 디버깅 도구 패키지의 설치 프로세스가 일부 변경됩니다. 이제 설치 프로세스로 직접 이동하여 툴킷을 설치할 수 있는 방법을 살펴보겠습니다.

웹 설치 프로그램을 사용하여 Windows용 디버깅 도구 설치

Windows SDK 아카이브 페이지로 이동하여 "Windows 10 SDK(10586) 및 Windows 10 Mobile(Microsoft)(버전 10586.11)이 포함된 장치 에뮬레이터" 항목 아래에서 Windows 10이라는 섹션을 찾으세요.

항목을 클릭하세요 SDK 설치. 클릭한 후 Windows SDK의 온라인 설치 프로세스를 시작하는 sdksetup.exe 파일을 다운로드하여 실행합니다. 초기 단계에서 설치 프로그램은 .NET Framework 패키지가 시스템에 설치되어 있는지 확인합니다. 최신 버전(V 이 순간 4.5입니다.) 패키지가 누락된 경우 설치가 제공되고 완료 시 스테이션이 재부팅됩니다. 재부팅 직후 사용자 인증 단계에서 Windows SDK 자체 설치 프로세스가 시작됩니다.

패키지의 모든 구성 요소를 예외 없이 선택하면 설치 과정에서 오류가 발생하는 경우가 종종 있습니다. 이 경우 최소한의 필수 세트로 구성요소를 선택적으로 설치하는 것이 좋습니다.

Windows용 디버깅 도구 설치가 완료된 후 디버깅 파일의 위치는 다음과 같습니다. 이 방법우리의 설치는 다음과 같습니다:

64비트 버전: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
32비트 버전: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* 여기서 x.x는 개발 키트의 특정 버전입니다.
버전 8 이상에서는 설치 경로가 모든 사람의 기존 경로와 눈에 띄게 다르다는 것을 확인했습니다. 이전 버전디버깅 도구?

큰 장점 이 방법 Windows용 디버깅 도구를 설치하려면 모든 아키텍처에 대한 디버깅 도구 버전을 한 번에 설치해야 합니다.

Windows SDK ISO에서 Windows용 디버깅 도구 설치

이 방법에는 전체 Windows SDK(소프트웨어 개발자 키트) 설치 이미지를 사용하여 Windows용 디버깅 도구를 설치하는 작업이 포함됩니다. 특정 시간까지 다운로드 ISO 이미지해당 시스템의 경우 Windows SDK 아카이브 페이지에서 가능했습니다. 그러나 현재 웹 설치 프로그램 sdksetup.exe를 실행하고 다음을 선택하여 SDK의 ISO 이미지를 얻을 수 있습니다. Windows 소프트웨어 개발 키트 다운로드설치 프로그램 시작 창에서:

우리가 알아낸 바와 같이, 웹 설치 프로그램을 사용한 이전 설치 방법은 매우 변덕스럽고 오류로 끝나는 경우가 많습니다. 클린 시스템에서는 문제 없이 설치되지만 충분히 로드된 시스템에서는 수많은 문제가 발생합니다. 이런 경우라면 이 방법을 사용해보세요.

따라서 페이지에서 필요한 배포판을 선택해야 합니다. 현재는 "Windows 7 및 .NET Framework 4용 Windows SDK"이고 바로 아래에서 "ISO 받기" 링크를 클릭하세요. DVD 이미지” .

msdn.microsoft.com 사이트에서 작업할 때 브라우저 사용을 권장합니다. 인터넷 익스플로러, 경쟁 제품이 작동하지 않는 경우가 있었기 때문에!

따라서 꼭 필요에 따라 선택하는 것이 필요합니다. 일반적으로 Windows용 디버깅 도구의 비트는 시스템의 비트와 일치합니다. 내 시스템은 대부분 64비트이므로 대부분의 경우 64비트 시스템 GRMSDKX_EN_DVD.iso용 이미지를 다운로드합니다.
그런 다음 이미지를 다운로드한 후 어떻게든 기존 ISO 이미지로 작업해야 합니다. 전통적인 방법은 물론 CD를 굽는 것이지만 이는 다소 시간이 오래 걸리고 때로는 비용이 많이 드는 방법입니다. 무료 유틸리티를 사용하여 시스템에 가상 디스크 장치를 생성하는 것이 좋습니다. 개인적으로 저는 이러한 목적으로 DEAMON Tools Lite를 사용하는 것을 선호합니다. 누군가는 취향과 색상에 따라 다른 기본 설정, 더 직접적이거나 가벼운 유틸리티를 가질 수 있습니다. DAEMON Tools Lite를 설치한 후 GRMSDKX_EN_DVD.iso 이미지 파일을 두 번 클릭하기만 하면 시스템에 새로운 가상 파일이 나타납니다. CD:

그런 다음 두 번 클릭하여 자동 로드를 활성화하고 Windows SDK 설치를 시작합니다.

목록에서 설치할 구성 요소를 선택할 때가 되면 스크린샷에 표시된 옵션을 제외한 모든 옵션을 완전히 비활성화합니다. 이는 이제 불필요한 실수를 피하는 데 도움이 될 것입니다.

모든 것이 똑같습니다. 스크린샷에는 "Windows Performance Toolkit"과 "Windows용 디버깅 도구"라는 두 가지 옵션이 있습니다. Windows Performance Toolkit이 작업에 확실히 도움이 되므로 둘 다 선택하십시오! 그런 다음 "다음" 버튼을 클릭하면 평소대로 설치가 계속됩니다. 그리고 마지막에는 "설치 완료"라는 문구가 표시됩니다.
설치가 완료되면 Windows용 디버깅 도구 패키지의 작업 디렉터리는 다음과 같습니다.

x86 버전의 경우:
x64 버전의 경우:

이 시점에서 Windows용 디버깅 도구 설치가 완료된 것으로 간주할 수 있습니다.

.msi 파일을 통해 Windows용 디버깅 도구 설치

이전 두 가지 방법을 사용하여 Windows용 디버깅 도구를 설치할 때 문제가 발생하는 경우, 가장 안정적이고 오랜 테스트를 거쳐 구출된 방법 중 하나가 더 남아 있습니다. 옛날 옛적에 Windows SDK에 통합되기 전에는 Windows용 디버깅 도구가 별도의 installer.msi로 제공되었는데, 이는 여전히 찾을 수 있지만 이미 Windows SDK 배포판에 포함되어 있습니다. 이미 Windows SDK의 ISO 이미지가 있으므로 시스템에 마운트할 수는 없지만 이미 잘 알려진 WinRAR 아카이버 또는 ISO 디스크의 내용과 작동하는 다른 제품을 사용하여 열 수 있습니다.

이미지를 연 후 루트에 있는 "Setup" 디렉터리로 이동한 다음 디렉터리 중 하나를 선택해야 합니다.

64비트 버전을 설치하려면: \Setup\WinSDKDebuggingTools_amd64이 디렉터리에서 dbg_amd64.msi 파일의 압축을 풉니다.
32비트 버전을 설치하려면: \Setup\WinSDKDebuggingTools를 실행하고 이 디렉터리에서 dbg_x86.msi 파일의 압축을 풉니다.

설치가 완료되면 Windows용 디버깅 도구 패키지의 작업 디렉터리는 다음과 같습니다.

x86 버전의 경우: C:\Program Files (x86)\Windows용 디버깅 도구(x86)
x64 버전의 경우: C:\Program Files\Windows용 디버깅 도구(x64)

이 시점에서 Windows용 디버깅 도구 설치가 완료된 것으로 간주할 수 있습니다.

추가 정보

내 부주의로 인해 이것이 무엇과 연결되어 있는지 모르겠지만 Windows용 디버깅 도구를 설치한 후 설치 프로그램이 시스템 경로 변수 Path에 디버거가 있는 디렉터리 경로를 설정하지 않습니다. 이로 인해 콘솔에서 직접 다양한 디버깅 작업을 시작하는 데 특정 제한이 적용됩니다. 따라서 경로가 없으면 창에 독립적으로 씁니다. 환경 변수 디버깅 도구 경로:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

* 귀하의 경우, 다른 비트 크기의 OS를 사용하거나 다른 SDK 버전을 사용하여 경로가 다를 수 있습니다.

Windows용 디버깅 도구 패키지의 유틸리티는 이식 가능한 응용 프로그램으로 작동할 수 있습니다. 작업 시스템에서 디렉터리를 복사하기만 하면 됩니다. Microsoft Windows 성능 도구 키트프로덕션 서버에서 휴대용 버전으로 사용하세요. 하지만 시스템 용량을 고려하는 것을 잊지 마세요!! 중요한 시스템에 패키지 설치를 완료한 경우에도 설치 후 바로 작업을 시작할 수 있으며 재부팅할 필요가 없습니다.

Windows용 디버깅 도구 구성

이제 마지막으로 Windows용 디버깅 도구의 구성은 다음과 같습니다.

파일	목적
adplus.doc	ADPlus 유틸리티에 대한 설명서입니다.
adplus.exe	하나 이상의 프로세스에 대한 덤프 및 로그 파일을 생성하기 위해 cdb 디버거 작업을 자동화하는 콘솔 애플리케이션입니다.
agestore.exe	기호 서버 또는 소스 서버에서 사용하는 저장소에서 사용되지 않는 파일을 제거하기 위한 유틸리티입니다.
breakin.exe	CTRL+C를 누르는 것과 유사하게 사용자 정의 나누기 조합을 프로세스에 보낼 수 있는 유틸리티입니다.
cdb.exe	사용자 모드 콘솔 디버거.
변환스토어.exe	기호를 2계층에서 3계층으로 변환하는 유틸리티입니다.
dbengprx.exe	원격 디버깅을 위한 리피터(프록시 서버)입니다.
dbgrpc.exe	RPC 호출 상태 정보를 표시하는 유틸리티입니다.
dbgsrv.exe	원격 디버깅에 사용되는 서버 프로세스입니다.
dbh.exe	기호 파일의 내용에 대한 정보를 표시하는 유틸리티입니다.
dumpchk.exe	덤프 검사 유틸리티. 덤프 파일을 빠르게 확인하는 유틸리티입니다.
dumpexam.exe	메모리 덤프를 분석하기 위한 유틸리티입니다. 결과는 %SystemRoot%\MEMORY.TXT로 출력됩니다.
gflags.exe	전역 시스템 플래그 편집자입니다. 이 유틸리티는 레지스트리 키 및 기타 설정을 관리합니다.
i386kd.exe	kd용 래퍼. x86 시스템용 Windows NT/2000 기반 시스템에서 kd가 한때 호출되었던 것입니까? 아마도 호환성 문제로 남아있을 것입니다.
ia64kd.exe	kd용 래퍼. ia64 시스템용 Windows NT/2000 기반 시스템에서는 한때 kd라고 불렸습니까? 아마도 호환성 문제로 남아있을 것입니다.
kd.exe	커널 모드 콘솔 디버거.
kdbgctrl.exe	커널 디버깅 관리 도구. 커널 디버깅 연결을 관리하고 구성하기 위한 유틸리티입니다.
kdsrv.exe	KD용 연결 서버입니다. 이 유틸리티는 원격 연결을 실행하고 기다리는 작은 응용 프로그램입니다. kd는 클라이언트에서 실행되며 원격 디버깅을 위해 이 서버에 연결됩니다. 서버와 클라이언트는 모두 동일한 디버깅 도구 어셈블리에 있어야 합니다.
kill.exe	프로세스를 종료하는 유틸리티입니다.
목록.exe	파일의 내용을 화면에 표시하는 유틸리티입니다. 이 소형 유틸리티는 큰 텍스트나 로그 파일을 보는 한 가지 목적으로 포함되었습니다. 텍스트를 부분적으로 로드하기 때문에 메모리 공간을 거의 차지하지 않습니다.
로거.exe	하나의 프로세스에서만 작동할 수 있는 소형 디버거입니다. 이 유틸리티는 연구 중인 프로그램의 모든 함수 호출과 기타 작업을 기록하는 프로세스 공간에 logexts.dll을 삽입합니다.
로그뷰어.exe	logger.exe 디버거에 의해 기록된 로그를 보기 위한 유틸리티입니다.
ntsd.exe	Microsoft NTSD(NT 기호형 디버거). 실행 시 텍스트 창을 생성한다는 점을 제외하면 cdb와 동일한 디버거입니다. cdb와 마찬가지로 ntsd는 콘솔 응용 프로그램과 그래픽 응용 프로그램을 모두 디버깅할 수 있습니다.
pdbcopy.exe	기호 파일에서 개인 기호를 제거하고 기호 파일에 포함된 공용 기호를 제어하는 유틸리티입니다.
원격.exe	모든 콘솔 디버거 KD, CDB 및 NTSD의 원격 디버깅 및 원격 제어를 위한 유틸리티입니다. 이러한 모든 콘솔 디버거를 원격으로 실행할 수 있습니다.
rtlist.exe	원격 작업 뷰어. 이 유틸리티는 DbgSrv 서버 프로세스를 통해 실행 중인 프로세스 목록을 표시하는 데 사용됩니다.
Symchk.exe	Microsoft 기호 서버에서 기호를 다운로드하고 로컬 기호 캐시를 생성하는 유틸리티입니다.
Symstore.exe	네트워크 또는 로컬 심볼 저장소(2계층/3계층)를 생성하기 위한 유틸리티입니다. 기호 저장소는 특정 구조에 따라 구축되고 기호를 포함하는 디스크의 특수 디렉토리입니다. 구성 요소 이름과 동일한 이름을 가진 하위 폴더 구조가 기호의 루트 디렉터리에 생성됩니다. 결과적으로 이러한 각 하위 폴더에는 이진 파일을 해싱하여 얻은 특수 이름을 가진 중첩 하위 폴더가 포함되어 있습니다. Symstore 유틸리티는 구성 요소 폴더를 검색하고 모든 클라이언트가 해당 구성 요소를 검색할 수 있는 기호 저장소에 새 구성 요소를 추가합니다. Symstore는 0-tier 스토리지로부터 심볼을 받아 2-tier/3-tier 스토리지에 넣는 데 사용된다고 합니다.
tlist.exe	작업 뷰어. 실행 중인 모든 프로세스 목록을 표시하는 유틸리티입니다.
umdh.exe	사용자 모드 덤프 힙 유틸리티. 선택한 프로세스의 힙을 분석하기 위한 유틸리티입니다. 힙에 대한 다양한 매개변수를 표시할 수 있습니다.
usbview.exe	USB 뷰어. 컴퓨터에 연결된 USB 장치를 보기 위한 유틸리티입니다.
vmdemux.exe	가상 머신 디멀티플렉서. 하나의 COM 연결에 대해 여러 개의 명명된 파이프를 만듭니다. 채널은 다양한 가상 머신 구성요소를 디버깅하는 데 사용됩니다.
windbg.exe	GUI를 갖춘 사용자 모드 및 커널 모드 디버거.

원인을 확인하려면 블루 스크린(BSOD) 메모리 덤프 분석이 필요합니다. 대부분의 경우 심각한 오류가 발생할 경우 시스템에서 생성되는 미니덤프로 충분합니다.
이 기사에는 다음이 포함되어 있습니다. 단계별 지시 WinDBG 설치 및 구성 - BSOD의 실제 원인을 식별할 수 있는 강력한 디버깅 도구입니다.