집 무료 프로그램 Windows용 디버깅 도구. Windows용 디버깅 도구를 설치합니다. 시스템 구성

Windows용 디버깅 도구. Windows용 디버깅 도구를 설치합니다. 시스템 구성

WinDBG 소개 - 1부

알렉산더 안티포프

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

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

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

이 기사에서는 프로세스에 마운트 및 연결하는 방법을 살펴보고 다음 기사에서는 중단점, 단계별 실행 및 메모리 검사를 다룰 것입니다.

WinDBG 설치

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

Windows 8에 WinDBG 설치

Windows 8에서 WinDBG는 Windows 드라이버 키트(WDK)에 포함되어 있습니다. 당신은 설치할 수 있습니다 비주얼 스튜디오및 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 Symbol Server를 사용하도록 WinDBG를 구성하려면 File:Symbol 파일 경로 섹션으로 이동하여 경로를 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: 연결할 프로세스 선택

연결 후 응용 프로그램이 작업을 일시 중단한 경우 해당 상자를 선택하여 "비냉각" 모드를 사용할 수 있습니다.

원격 프로세스 디버깅

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

기존 디버그 세션

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

서버 TCP:포트=5005

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

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

그런 다음 WinDBG는 서버가 실행 중임을 보고합니다.

0:005> .서버 TCP:포트=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 명령에 대한 도움말을 보려면 다음 명령을 사용하십시오.

windbg> .hh .reload

또는 "도움말: 목차" 섹션으로 이동하십시오.

모듈

프로그램이 실행되는 동안 응용 프로그램의 기능을 제공하는 다양한 모듈을 가져옵니다. 따라서 응용 프로그램에서 어떤 모듈을 가져오는지 알면 작동 방식을 더 잘 이해할 수 있습니다. 대부분의 경우 실행 파일 자체가 아니라 프로그램에 의해 로드된 특정 모듈을 디버깅하게 됩니다.

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

Microsoft(R) Windows 디버거 버전 6.12.0002.633 X86
저작권 (c) Microsoft Corporation. 판권 소유.

*** 보류 중인 연결로 대기
기호 검색 경로: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
실행 가능한 검색 경로는 다음과 같습니다.
모드로드: 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
모드로드: 75fa0000 76069000 C:\Windows\system32\USER32.dll
모드로드: 777b0000 777ba000 C:\Windows\system32\LPK.dll
모드로드: 774b0000 7754d000 C:\Windows\system32\USP10.dll
모드로드: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
모드로드: 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
모드로드: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
모드로드: 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
모드로드: 74260000 74273000 C:\Windows\system32\dwmapi.dll
모드로드: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
모드로드: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
모드로드: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll

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

0:005>영화
시작 끝 모듈 이름
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 777ba000LPK 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] 바운드 가져오기 디렉토리 주소
가져오기 주소 테이블 디렉토리의 1000 [DE8] 주소
0 [ 0] Delay Import Directory 주소
0 [ 0] COR20 헤더 디렉토리의 주소
0 [ 0] 예약된 디렉토리의 주소

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

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

디버그 디렉토리(2)
유형 크기 주소 포인터
cv 25 c549c c4c9c 형식: RSDS, guid, 2, kernel32.pdb
(10) 4 c5498 c4c98

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

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

섹션 헤더 #4
.relocname
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 int 3

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

0:005> 렉스
eax=7ffd9000

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

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

지시에 대한 포인터

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

ntdll!DbgBreakPoint:
77663540cc int 3

연락을 유지하다

다음 기사에서는 전투에서 WinDBG를 사용하는 방법(중단점, 단계별 디버깅 및 메모리 보기)을 살펴보겠습니다. 전환하지 마십시오! 제이.

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

1단계 - 작은 메모리 덤프 기록 설정

2단계 - WinDBG 설치

메모리 덤프를 분석하려면 Windows SDK에 포함된 WinDBG 디버거를 설치해야 합니다. 작성 당시 사용 가능한 최신 Windows SDK 버전은 다음과 같습니다.

Windows 10 SDK(온라인 설치 프로그램 다운로드)
Windows 8.1 SDK(온라인 설치 프로그램 다운로드)

3단계 - .dmp 파일을 WinDBG에 매핑

.dmp 파일을 WinDBG에 매핑하여 메모리 덤프를 더 쉽게 읽고 분석할 수 있습니다. 이렇게 하면 예비 실행을 건너뛰고 WinDBG에서 직접 탐색기의 덤프 파일을 열 수 있습니다.

4단계 — 디버그 기호 파일을 수신하도록 기호 서버 설정

이제 WinDBG의 설치 및 초기 구성이 완료되었습니다. 모양을 변경하려면 메뉴로 이동할 수 있습니다. 보다- 항목을 선택하여 찾을 글꼴 설정 폰트및 콘솔 창 설정 옵션.

치명적인 오류가 발생하면 Windows 운영 체제가 작동을 멈추고 다음과 같이 표시됩니다. 블루 스크린죽음(BSOD). 콘텐츠 랜덤 액세스 메모리발생한 오류에 대한 모든 정보가 페이징 파일에 기록됩니다. 다음에 윈도우 부팅크래시 덤프는 저장된 데이터를 기반으로 하는 디버깅 정보로 생성됩니다. 시스템 이벤트 로그에 치명적인 오류 항목이 생성됩니다.

주목!디스크 하위 시스템에 장애가 발생하거나 크래시 덤프가 생성되지 않습니다. 치명적 오류 Windows를 로드하는 초기 단계에서 발생했습니다.

Windows 크래시 덤프 유형

현재 Windows 10 운영 체제의 예를 사용하여( 윈도우 서버 2016) 시스템이 생성할 수 있는 주요 메모리 덤프 유형을 고려하십시오.

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

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

Win + Pause를 사용하여 시스템 설정 창을 열고 " 추가 시스템 설정" (고급 시스템 설정). 탭에서 " 추가적으로"(고급), ""(시작 및 복구) 섹션, " 옵션» (설정). 열리는 창에서 시스템 장애 시 조치를 구성하십시오. 확인란을 선택하십시오 " 이벤트 쓰기 시스템 로그 » (시스템 로그에 이벤트 쓰기), 시스템 충돌 시 생성될 덤프 유형을 선택합니다. 체크박스에 " 기존 덤프 파일 바꾸기» (기존 파일 덮어쓰기) 확인란을 선택하면 충돌이 발생할 때마다 파일을 덮어씁니다. 이 상자의 선택을 취소하는 것이 좋습니다. 그러면 분석을 위한 추가 정보가 제공됩니다. 또한 비활성화 자동 재부팅시스템(자동으로 다시 시작).

대부분의 경우 작은 메모리 덤프만으로도 BSOD의 원인을 분석하기에 충분합니다.

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

Windows에 WinDBG 설치

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

파일이 호출됩니다 windksetup.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 기호 서버를 통해 배포되는 기호로 컴파일됩니다.

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진수 값그리고 보인다 0xXXXXXXXXX(옵션 중 하나에 표시됨 - STOP:, 07/02/2019 0008F, 0x8F). 이 예에서 오류 코드는 0x139입니다.

디버거가 명령을 실행하라는 메시지를 표시합니다!analyst -v, 링크 위로 마우스를 가져간 다음 클릭하기만 하면 됩니다. 이 명령은 무엇을 위한 것입니까?

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

!analyze -v 명령을 실행한 후 분석할 때 주의해야 할 주요 사항(목록이 완전하지 않음).

1: kd> !분석 -v

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

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

인수:
Arg1: 0000000000000003, A 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:
ffgffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d 체크
fffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: Check nt!KiBatch
Disstdffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000:00000000 00000000`00000000 00000000000
fffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9:Security nt!
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 fffd000`3a20nt!951: ?? ::FNODOBFM::`문자열"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf!Nt000eb`a0cf1380:4Filent
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`0
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000

오류가 발생한 코드 섹션:

FOLLOWUP_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

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

이러한 유형의 실패는 일반적으로 정확히 찾아내기 어려울 수 있는 실패한 드라이버와 관련이 있습니다. 그러나 개선된 버그 추적 시스템 윈도우 비스타(비스타 뿐만 아니라!) 종종 문제가 있는 파일로 이어질 수 있습니다. 결과적으로 대부분의 사람들은 불안정한 컴퓨터에서 미친 듯이 작업을 중단하고 편집증 규칙으로 문서를 저장하고 최고를 기대합니다.

~에 Windows 충돌일반적으로 소위 "메모리 덤프"가 생성됩니다. 후자는 무료 디버그 도구로 탐색할 수 있습니다. 윈도우 도구문제의 원인을 알려줄 수 있는 디버깅 도구. 따라서 다음 작업만 수행하면 됩니다.

디버깅 도구 다운로드

Microsoft 웹 사이트에서 직접 Windows 디버깅 도구를 다운로드할 수 있습니다. 이 프로그램은 Windows NT 4에서 시작하여 Windows 2008로 끝나는 많은 운영 체제에서 작동하므로 문제가 없어야 합니다. 예, Windows 7 RC에서 안정적이라고 말할 수는 없지만 테스트에 따르면 여전히 작동합니다. 따라서 Windows 7 RC에서 문제 진단을 시도하더라도 성공할 수 있습니다.

시스템 구성

충돌이 발생하는 동안 컴퓨터는 나중에 디버거에 대한 정보 소스 역할을 할 메모리 덤프를 생성해야 합니다. 따라서 덤프를 생성하도록 Windows를 구성하는 것이 중요합니다. 운영 체제를 사용자 지정하려면 마우스 오른쪽 버튼으로 클릭내 컴퓨터 위에 마우스를 놓고 속성을 선택합니다. 그런 다음 고급 시스템 설정 탭을 클릭하고 시작 및 복구 설정 하위 섹션을 찾아 디버깅 정보 쓰기 옵션이 커널 메모리 덤프 또는 전체 메모리 덤프로 설정되어 있는지 확인합니다.

그런 다음 시작을 클릭하고 프로그램(모든 프로그램)으로 이동하여 디버깅 도구를 선택하고 WinDbg를 실행합니다. 프로그램에서 파일 메뉴로 이동하여 기호 파일 경로 ...를 선택한 다음 열리는 창에 다음 줄을 작성합니다.

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

후자는 특수 데이터에 대한 경로를 정의합니다. 소위 "기호"(기호)는 디버깅 도구가 충돌한 파일을 식별하는 데 도움이 될 수 있습니다.

문자열을 입력한 후 확인 버튼을 클릭합니다. 나중에 디버거로 작업할 때 이 줄을 사용하면 msdl.microsoft.com에서 기호를 다운로드하고 c:\symbols 폴더에 저장합니다.

문제 해결

이제 또 다른 블루 스크린 오류가 발생하고 컴퓨터가 다시 시작될 때까지 기다리십시오. 그런 다음 WinDbg를 다시 실행하고(Vista 사용자는 프로그램을 관리자로 실행해야 함) 파일 메뉴를 클릭하고 크래시 덤프 열기를 선택하고 \Windows\MEMORY.DMP 파일을 열면 프로그램이 즉시 분석을 시작합니다.

불행히도, WinDbg는 그것이 하는 일에 대한 정보를 거의 제공하지 않기 때문에 프로그램이 멈췄다고 생각할 수도 있습니다. 그러나 기다리십시오. 예를 들어 4GB의 메모리에 대한 분석은 그리 많지 않습니다. 강력한 컴퓨터최대 몇 시간이 소요될 수 있습니다. 따라서 인내심을 갖고 분석을 밤새도록 두십시오.

그러나 일반적으로 몇 분 안에 결과를 얻을 수 있습니다. 이것은 "아마도 원인: UACReplace.sys"와 같은 버그 체크 분석 라인에 의해 입증됩니다. 러시아어로 번역하면 문제가 UACReplace.sys 파일로 인해 발생할 수 있음을 의미합니다. 예를 들어 Google과 같은 검색 창에 입력하면 실제 출처를 알 수 있습니다. 특히, 설치한 프로그램 중 하나에 속하거나 설치된 드라이버, 당신은 그것을 또는 그를 업데이트하려고 할 수 있습니다. 아마도 이것은 당신의 문제를 해결할 것입니다.

나는 때때로 WinDbg가 파일 이름을 전혀 지정할 수 없거나 단순히 Windows DLL 중 하나를 선택한다고 말해야 합니다. 이런 일이 발생하면 상태 표시줄 위의 명령 창을 클릭하고 다음 명령을 입력합니다.

그런 다음 Enter 키를 누릅니다. 이렇게 하면 에 대한 정보가 포함될 수 있는 보다 자세한 보고서가 제공됩니다. 가능한 이유당신의 고민.

이번에 운이 좋지 않다면 절망하지 마십시오. 디버깅은 전문가에게도 매우 어렵습니다. 따라서 다음 충돌 후에 WinDbg를 닫고 분석기를 다시 실행하십시오. 아마도 이것은 당신에게 더 많은 정보를 줄 것입니다. 행운을 빕니다!

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

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

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

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

다음 버전의 Windows용 디버깅 도구를 사용할 수 있습니다. 32비트 x86, Intel Itanium, 64비트 x64. x86 또는 x64의 두 가지가 필요합니다.

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

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

어느 시점에서 컴퓨터에 디버깅 도구를 설치해야 하는지 명확하지 않습니다. 종종 결국, 당신은 개입해야 하는 상황에 직면하게 됩니다. 근무 환경매우 바람직하지 않습니다! 더욱이 새 제품을 설치한 이후, 즉 레지스트리/시스템 파일을 변경하는 것은 완전히 용납되지 않을 수 있습니다. 미션 크리티컬 서버가 그 예입니다. 왜 개발자는 설치가 필요하지 않은 애플리케이션의 휴대용 버전을 고려하지 않습니까?
버전마다 Windows용 디버깅 도구 패키지를 설치하는 프로세스가 일부 변경됩니다. 이제 설치 프로세스로 바로 이동하여 툴킷을 설치할 수 있는 방법을 살펴보겠습니다.

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

Windows SDK 아카이브 페이지로 이동하여 "Windows 10 SDK(10586) 및 Microsoft Windows 10 Mobile Device Emulator(버전 10586.11)" 항목 아래에서 Windows 10이라는 섹션을 찾습니다.

항목을 클릭하십시오 SDK 설치. 클릭 후 sdksetup.exe 파일을 다운로드하여 실행하면 프로세스가 시작됩니다. Windows 온라인 설치 SDK. 초기 단계에서 설치 프로그램은 최신 버전의 .NET Framework 패키지가 시스템에 설치되어 있는지 확인합니다(현재는 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용 Debigging 도구 설치는 모든 아키텍처에 대한 디버깅 도구 버전을 한 번에 설치하는 것입니다.

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

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

알고보니 기존에 웹 인스톨러를 이용한 설치 방식은 상당히 변덕스럽고 실패하는 경우가 많습니다. 에 깨끗한 시스템문제없이 설치되지만 이미 충분히로드되면 많은 문제가 발생합니다. 이 경우 이 방법을 사용하십시오.

따라서 페이지에서 필요한 배포 키트를 선택해야 합니다. 저에게(많은 사람들이 생각합니다) 현재 "Windows 7 및 .NET Framework 4용 Windows SDK"이고 "Get DVD ISO 이미지" .

msdn.microsoft.com 사이트에서 작업할 때 다음을 사용하는 것이 좋습니다. 인터넷 브라우저익스플로러는 경쟁 제품이 작동하지 않는 것을 보았기 때문에!

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

그런 다음 두 번 클릭하여 자동 로드를 활성화하고 실행합니다. 윈도우 설치 SDK:

목록에서 설치할 구성 요소를 선택할 차례가 되면 스크린샷에 표시된 옵션을 제외한 모든 옵션을 절대적으로 비활성화합니다. 이것은 우리가 지금 불필요한 실수를 피하는 데 도움이 될 것입니다.

맞습니다. 스크린샷은 "Windows 성능 도구 키트" 및 "Windows용 디버깅 도구"의 두 가지 옵션을 보여줍니다. Windows Performance Toolkit이 작업에 확실히 도움이 될 것이므로 둘 다 선택하십시오! 또한 "다음" 버튼을 클릭하면 일반 모드로 설치가 계속됩니다. 그리고 끝에 "설치 완료"라는 비문이 표시됩니다.
설치가 완료되면 Windows용 디버깅 도구 키트의 작업 디렉터리는 다음과 같습니다.

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

이것으로 Windows용 디버깅 도구 설치가 완료되었습니다.

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

이전의 두 가지 방법으로 Windows용 디버깅 도구를 설치하는 동안 문제가 발생하는 경우 가장 안정적이고 오랜 시간 테스트를 거친 도구가 하나 더 남아 있어 두 번 이상 도움이 되었습니다. 한 번은 Windows SDK에 통합하기 전에 Windows용 디버깅 도구를 별도의 .msi 설치 프로그램으로 사용할 수 있었습니다. 이 설치 프로그램은 여전히 찾을 수 있지만 이미 Windows SDK 배포판에 포함되어 있습니다. 이미 Windows SDK의 ISO 이미지가 있으므로 시스템에 마운트할 수 없지만 잘 알려진 WinRAR 아카이버 또는 ISO 디스크의 내용과 함께 작동하는 다른 제품을 사용하여 열면 됩니다.

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

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

* 귀하의 경우 bitness가 다른 OS의 사용과 다른 버전의 SDK 사용으로 인해 경로가 다를 수 있습니다.

Windows용 디버깅 도구 패키지의 유틸리티는 이식 가능한 응용 프로그램으로 작동할 수 있습니다. 작업 시스템목록 Microsoft Windows 성능 도구 키트프로덕션 서버에서 휴대용 버전으로 사용하십시오. 그러나 시스템의 용량을 고려하는 것을 잊지 마십시오!! 중요한 시스템에 패키지를 완전히 설치했더라도 설치 직후에 작업을 시작할 수 있으며 재부팅할 필요가 없습니다.