출처: http://comlog.kr/77

닥터 왓슨 (Dr. Watson) 은 명탐정 셜록 홈즈의 든든한 친구로 활약하기도 했지만 우리가 사용하고 있는 윈도우에서도 보이지 않게 많은 활약을 하고 있습니다. :)

윈도우에 고용된 닥터왓슨 (Dr. Watson, drwtsn32.exe) 은 윈도우 응용프로그램에서 오류가 발생했을 때, 해당 오류를 수정하기 용이하도록 오류 정보를 기록하고 메모리 덤프를 저장하는 디버거 (Debugger, 오류를 수정하는데 도움을 주는 프로그램) 역할을 하고 있습니다.

하지만 직접 디버깅 (Debugging, 오류를 수정하는 일) 을 하지 않고, 저장된 오류 정보를 분석하기 힘든 일반 사용자들에게는 그저 월급만 축내는 귀찮은 존재입니다. 오늘은 윈도우 응용프로그램 오류 디버거닥터 왓슨 (Dr. Watson) 을 해고하여 보겠습니다. :)

먼저, 윈도우 프로그램에서 오류가 발생했을 때 닥터 왓슨이 아무 일도 하지 않게 설정하여 보겠습니다.
'시작 - 실행' 을 선택하거나 '윈도우 + R' 키를 눌러 실행창을 띄운 후 다음 명령어를 입력합니다.

drwtsn32


그러면 아래와 같은 닷터왓슨 설정창이 나타납니다.

윈도우 닥터 왓슨 Dr. Watson drwtsn32.exe


위 화면같이 '명령 개수' 와 '저장할 오류 개수' 를 '0' 으로 수정하고, 아래 옵션 항목의 모든 체크를 해제합니다.
이제 닥터 왓슨은 응용프로그램에서 오류가 발생해도 아무런 일도 수행하지 않습니다. :) 즐거운 컴퓨터고난기록기

만약 윈도우가 디버거 자체를 사용하지 않도록 하려면 아래의 레지스트리 키를 삭제합니다.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug


레지스트리 작업을 할 때는 그 어느 때보다 주의를 기울여야 합니다. 자칫 다른 레지스트리의 항목을 잘못 수정하거나 삭제하면 윈도우 동작에 이상이 발생할 수도 있습니다.

반대로, 다시 닥터 왓슨을 윈도우 기본 디버거로 사용하려면 실행창에서 다음 명령어를 입력합니다.

drwtsn32 -i
AND

출처: http://debugjung.tistory.com/176

Visual C++ 개념: C/C++ 프로그램 빌드
링크

링커 사용에 대한 자세한 내용은 다음 항목을 참조하십시오.

개념

C/C++ 빌드 참조


Visual C++ 링커 옵션
링커 옵션

LINK는 COFF(Common Object File Format) 개체 파일과 라이브러리를 링크하여 실행 파일(.exe)이나 DLL(동적 연결 라이브러리)을 만드는 도구입니다.

다음 표에서는 LINK.exe의 모든 옵션 목록을 보여 줍니다. 이 단원에는 다음 항목에 대한 정보도 포함되어 있습니다.

명령줄에 지정되는 링커 옵션은 대/소문자를 구분하지 않습니다. 즉, /base와 /BASE는 동일하게 취급됩니다.

일부 링커 옵션은 comment pragma를 사용하여 지정할 수 있습니다.

옵션

용도

@

지시 파일을 지정합니다.

/ALIGN

각 섹션의 정렬 방식을 지정합니다.

/ALLOWBIND

DLL을 바인딩할 수 없도록 지정합니다.

/ALLOWISOLATION

매니페스트 조회 동작을 지정합니다.

/ASSEMBLYDEBUG

관리되는 이미지에 DebuggableAttribute를 추가합니다.

/ASSEMBLYLINKRESOURCE

관리되는 리소스에 대한 링크를 만듭니다.

/ASSEMBLYMODULE

MSIL(Microsoft Intermediate Language) 모듈을 어셈블리로 가져오도록 지정합니다.

/ASSEMBLYRESOURCE

관리되는 리소스 파일을 어셈블리에 포함시킵니다.

/BASE

프로그램의 기준 주소를 설정합니다.

/CLRIMAGETYPE

CLR 이미지의 형식(IJW, pure 또는 safe)을 설정합니다.

/CLRSUPPORTLASTERROR

P/Invoke 메커니즘을 통해 호출한 함수의 마지막 오류 코드를 저장합니다.

/CLRTHREADATTRIBUTE

CLR 프로그램의 진입점에 적용하려는 스레드 특성을 지정합니다.

/CLRUNMANAGEDCODECHECK

/CLRUNMANAGEDCODECHECK는 링커가 생성하여 관리 코드에서 네이티브 DLL로 호출되는 PInvoke 스텁에 링커가 SuppressUnmanagedCodeSecurity 특성을 적용할지 여부를 지정합니다.

/DEBUG

디버깅 정보를 만듭니다.

/DEF

모듈 정의 파일(.def)을 링커에 전달합니다.

/DEFAULTLIB

외부 참조를 확인할 때 지정된 라이브러리를 검색합니다.

/DELAY

DLL의 지연 로드를 제어합니다.

/DELAYLOAD

지정된 DLL을 지연 로드시킵니다.

/DELAYSIGN

어셈블리에 부분적으로 서명합니다.

/DLL

DLL을 빌드합니다.

/DRIVER

Windows NT 커널 모드 드라이버를 만듭니다.

/DYNAMICBASE

로드할 때 Windows Vist의 ASLR(Address Space Layout Randomization) 기능을 사용하여 임의로 기준 주소를 지정할 수 있는 실행 가능 이미지를 생성할지 여부를 지정합니다.

/ENTRY

시작 주소를 설정합니다.

/errorReport

내부 링커 오류를 Microsoft에 보고합니다.

/EXPORT

함수를 내보냅니다.

/FIXED

기본 기준 주소에서만 로드할 수 있는 프로그램을 만듭니다.

/FORCE

확인되지 않거나 기호가 두 번 이상 정의된 경우에도 링크를 완료하도록 합니다.

/FUNCTIONPADMIN

핫 패치할 수 있는 이미지를 만듭니다.

/HEAP

힙 크기를 바이트 단위로 설정합니다.

/IDLOUT

.idl 파일과 기타 MIDL 출력 파일의 이름을 지정합니다.

/IGNOREIDL

특성 정보가 .idl 파일로 처리되지 않도록 합니다.

/IMPLIB

기본 가져오기 라이브러리 이름을 무시합니다.

/INCLUDE

기호 참조를 강제 적용합니다.

/INCREMENTAL

증분 링크를 제어합니다.

/KEYCONTAINER

어셈블리에 서명할 키 컨테이너를 지정합니다.

/KEYFILE

어셈블리에 서명할 키 또는 키 쌍을 지정합니다.

/LARGEADDRESSAWARE

응용 프로그램에서 2GB 이상의 주소를 지원하도록 컴파일러에 지시합니다.

/LIBPATH

사용자가 환경 라이브러리 경로를 재정의할 수 있도록 합니다.

/LTCG

링크 시간 코드 생성을 지정합니다.

/MACHINE

대상 플랫폼을 지정합니다.

/MANIFEST

side-by-side 매니페스트 파일을 만듭니다.

/MANIFESTDEPENDENCY

매니페스트 파일에 <dependentAssembly> 섹션을 지정합니다.

/MANIFESTFILE(매니페스트 파일 이름 지정)

매니페스트 파일의 기본 이름을 변경합니다.

/MANIFESTUAC

프로그램 매니페스트에 UAC(사용자 계정 컨트롤) 정보를 포함할지 여부를 지정합니다.

/MAP

맵 파일을 만듭니다.

/MAPINFO

지정한 정보를 맵 파일에 포함시킵니다.

/MERGE

섹션을 결합합니다.

/MIDL

MIDL 명령줄 옵션을 지정합니다.

/NOASSEMBLY

.NET Framework 어셈블리를 만들지 않습니다.

/NODEFAULTLIB

외부 참조를 확인할 때 모든 또는 지정한 기본 라이브러리를 무시합니다.

/NOENTRY

리소스 전용 DLL을 만듭니다.

/NOLOGO

시작 배너를 표시하지 않습니다.

/NXCOMPAT

실행 파일을 Windows 데이터 실행 방지 기능과 호환되는지 테스트한 것으로 표시합니다.

/OPT

LINK 최적화를 제어합니다.

/ORDER

COMDAT을 미리 결정된 순서로 이미지에 배치합니다.

/OUT

출력 파일 이름을 지정합니다.

/PDB

PDB(프로그램 데이터베이스) 파일을 만듭니다.

/PDBSTRIPPED

전용 기호가 없는 PDB(프로그램 데이터베이스) 파일을 만듭니다.

/PGD

프로필 기반 최적화를 위한 .pgd 파일을 지정합니다.

/PROFILE

성능 도구 프로파일러와 함께 사용할 수 있는 출력 파일을 생성합니다.

/RELEASE

.exe 헤더의 체크섬을 설정합니다.

/SAFESEH

이미지에 안전한 예외 처리기 테이블이 포함되도록 지정합니다.

/SECTION

섹션의 특성을 재정의합니다.

/STACK

스택 크기를 바이트 단위로 설정합니다.

/STUB

MS-DOS 스텁 프로그램을 Win32 프로그램에 연결합니다.

/SUBSYSTEM

운영 체제에 .exe 파일의 실행 방법을 지정합니다.

/SWAPRUN

운영 체제에서 링커 출력을 실행하기 전에 스왑 파일로 복사하도록 지정합니다.

/TLBID

링커에서 생성한 형식 라이브러리의 리소스 ID를 지정할 수 있도록 합니다.

/TLBOUT

.tlb 파일과 기타 MIDL 출력 파일의 이름을 지정합니다.

/TSAWARE

터미널 서버에서 실행하도록 디자인된 응용 프로그램을 만듭니다.

/VERBOSE

링커 진행 메시지를 표시합니다.

/VERSION

버전 번호를 할당합니다.

/WX

링커 경고를 오류로 처리합니다.

자세한 내용은 컴파일러 제어 LINK 옵션을 참조하십시오.

AND

출처 :http://blog.naver.com/saojung50?Redirect=Log&logNo=120038406993

Just-in-time 디버깅

WinDbg -I로 실행하면 기본 JIT 디버거로서 설정할 수 있다. 이 명령은 레지스트리 키 HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug를 WinDbg롤 설정한다. JIT 디버거로 설정되면, 응용프로그램인 디버깅중이 아닐 경우에 예외를 던지고 그 예외를 처리하지 않을 경우 WinDbg가 동작하게된다.

 

 예외 디버깅

디버거는 각각의 예외에 2번 통지받는다. 응용프로그램이 예외를 처리하기 전에 first chance exception을 통지받고, 응용프로그램이 그 예외를 처리하지 않을 경우 second-chance excepton을 처리할 기회를 얻게된다. 디버거가 second-chance exception을 처리하지 않는다면, 응용프로그램은 종료한다.

.lastevent 또는 !analyze -v는 예외 기록과 예외가 발생했을 때의 함수의 스택 트레이스를 보여준다. .exr, .cxr 및 .ecxr 명령들을 예외 및 문맥 기록들(context records)을 화면에 표시하는데 사용할 수 있다. sxe, sxd, sxn 및 sxi 명령들을 이용하여 예외에 대해 first-chance 처리 옵션을 변경할 수 있다.

 



77818 c


처음 프로그램을 실행하면..

쓰레드를 생성하게 됍니다.

그 부분에서

First-chance exception이 나오는데요...

디버그 랩에서 보고 브레이크 포인터 까지 거는것 까지 했습니다.

하지마나 어디서 그 부분이 나오는지를 찾지 못하겠더군요..

쓰레드 생성 부분을 제거 하고 프로젝트를 실행하면 나오지는 않는데요..

왜 이런 현상이 나오는지 모르겠습니다.

여러 쓰레드를 생성하지만 특별히 몇개의 쓰레드에서만 나오는거 같은데요..


특별한 원인이 없는거 같은데..잘 모르겠더군요..


해결의 실마리가 있을런지 해서 이렇게 조언을 구합니다.

조언 부탁드리겠습니다.


답글 작성자 : 서우석 등록일 : 2004-06-01 오후 10:34
Re : First-chance Exception...

안녕하세요. 좋은 질문이네요..

우선 First-Chance Exception에 대해서 Microsoft의 KB에서 다음과 같이 소개하고 있습니다.

http://support.microsoft.com/default.aspx?kbid=105675

It is a common practice to use SEH as a signaling mechanism. Some application programming interfaces (APIs) register an exception handler in anticipation of a failure condition that is expected to occur in a lower layer.

When an exception is raised, the handler may correct or ignore the condition rather than allow a failure to propagate up through intervening layers. This is very useful in complex environments such as networks where partial failures are expected and it is not desirable to fail an entire operation just because one of several optional parts failed. In this case, the exception can be handled so that the application does not recognize that an exception has occurred.

However, if the application is being debugged, the debugger sees all exceptions before the program does. This is the distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.

해석 : 하지만 만약 응용 프로그램이 디버깅되고 있는 중이라면, 디버거는 프로그램이 예외를 확인하기 전에 먼저 모든 예외를 감시한다. 이것이 바로 첫번째(first-chance)와 두번째(second-chance) 예외의 차이점이다. 디버거는 프로그램에서 발생하는 모든 예외를 살펴볼 수 있는 가장 첫번째 기회(first-chance라고 하는 이유)를 갖게된다. 만약 디버거가 프로그램 실행을 계속 허용하고 해당 예외를 처리하지 않는다면, 프로그램은 평상시와 마찬가지로 예외를 확인하게 될 것이다. 만약 프로그램이 그 예외를 처리하지 않는다면, 디버거는 프로그램이 처리하지 않은 예외를 최종적으로 다시 한번 확인할 수 있는 두번째 기회(second-chance)를 갖게된다. 후자의 경우에는 일반적으로 디버거가 존재하지 않을 경우에 프로그램이 곧바로 충돌할 것이다.

* 보충 설명 ---------------

일반적으로 first-chance exception이 발생했다는 메시지를 확인했음에도 불구하고 프로그램이 충돌하지 않는 이유는 내부 코드에서 이 예외를 처리하고 있기 때문이라고 보시면 됩니다. 따라서 API를 호출하는 대부분의 경우에는 first-chance exception이 발생했다고 하더라도 무시하면 됩니다(내부적으로 처리가 되고 있기 때문이죠). 물론, first-chance exception을 확인하고 난 후, second-chance exception이 발생하여 프로그램이 충돌하면 당연히 오류를 잡아주어야 겠죠.

If you do not want to see the first chance exception in the debugger, you should disable first chance exception handling for the specific exception code. Otherwise, when the first chance exception occurs, you may need to instruct the debugger to pass on the exception to the program to be handled as usual.


만약 Visual Studio 6.0을 사용하고 계시다면, 이 툴로 first-chance exception을 잡을 방법이 없습니다. 다음 링크에서 WinDBG를 다운로드 하시면 간단하게 잡을 수 있죠. VS.NET에서는 원하는 exception을 선택할 수 있기 때문에 더욱 간단하구요. 물론 BoundsChecker와 같은 프로그램을 사용하셔도 잡으실 수 있을 것입니다. 결국 이 메세지를 디버깅 시에 확인하더라도 API 단에서 발생하는 경우라면 크게 걱정하지 않아도 건강에는 지장이 없다라는 것입니다. ^^

http://www.microsoft.com/ddk/debugging/




답글 작성자 : 박시존 등록일 : 2004-06-11 오후 3:54
Re : First-chance Exception...

 이런 경우에는 Debug -> exception -> 다이알로그 창에서 맨 밑의 항목 Microsoft C++ Exception을 stop always로 설정하셔도 많은 부분을 잡아낼 수 있습니다. 이렇게 해두면 예를 들어 DB exception이 발생하여 보통때는 "~ 테이블을 찾을 수 없습니다.." 정도로 메시지를 뿌려주고 지나가는 경우에도 먼저 브레이크가 걸린 다음에 메시지 박스가 나타나는 것에서부터 쓰레드 관련 오류 메모리 관련 오류( Access Violation을 stop always로 설정)등등 많은 부분이 미리 캐치됩니다. visual studio 6.0에서 사용하는 내용이고 Debug -> exception 메뉴는 프로그램 실행 중에만 활성화됩니다. F5 누르고 프로그램 시작하셔서 설정하시면 됩니다.



답글 작성자 : 관리자 등록일 : 2004-06-11 오후 11:15
Re : First-chance Exception...

좋은 답변 감사합니다. ^^


출처 : http://www.debuglab.com/board/board_detail.aspx?id=128&table=qna&pagenum=10


AND

출처: http://laigo.kr/329

Process 의 crash, hang 덤프를 수집하기 위해 Debug Diag 또는 adplus.vbs 를 흔히 사용하고 있습니다. 하지만 간혹 프로세스 crash 가 발생하였음에도 불구하고 터미널 세션에서 crash dump 를 수집하지 못하는 경우가 있었습니다. 이런 경우 WinDbg 를 통해서 덤프를 내려받을 수 있습니다. WinDbg 를 사용한 덤프 수집 방법에 대해서 아래와 같이 정리하였습니다.


1. 테스트를 위해 계산기(calc.exe) 프로그램을 실행합니다.
2. WinDbg 실행 - File - Attach to a Process - calc.exe 해당 PID 선택



3. 대상 프로세스(Debuggee)가 정상적으로 Debugger Tool 에 Attach 되면 'g' 명령을 수행하여 Debuggee 가 제어권을 가지도록 넘겨 줍니다.



4. calc.exe 프로세스를 강제 종료합니다. 제어권이 다시 디버거로 돌아옵니다.
eax=00000000 ebx=00000000 ecx=7c7d0000 edx=7c9ae120 esi=7c93de6e edi=00000000
eip=7c93e514 esp=0007fde8 ebp=0007fee4 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!KiFastSystemCallRet:
7c93e514 c3              ret



5. .dump 명령을 수행하여 메모리 덤프 파일을 내려 받습니다.
0:000> .dump /f d:\calc_crash.dmp
Creating d:\calc_crash.dmp - mini user dump
Dump successfully written

※ /f : Creates a complete memory dump, /o : overwrites an existing dump file  
[참고자료]
AND

출처: http://blog.naver.com/gilverth?Redirect=Log&logNo=70067163332

Windbg 설치 폴더로 이동 (예:C:\Program Files\Debugging Tools for Windows (x86))

WinDbg -I 실행 ( <== 반드시 대문자 I 를 입력해주어야함~);

설정 완료 후 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug'에서 설정 내용 확인 가능

이젠 오류나면 Windbg가 실행된다~

AND

PROTECTED ARTICLE. TYPE THE PASSWORD.

출처: http://blog.naver.com/agfe2?Redirect=Log&logNo=90032760597

아래는 미리 정리해둔 내용이다.

프로그램 다운로드는 외국사이트의 경우 file hippo 를 애용한다. 최근에 업데이트 첵크 툴이 나와서

프로그램이 갱신될 경우 쉽게 알 수 있다.

국내사이트 마이폴더 , 심파일에도 그런 기능이 있던 것으로 기억한다.


네트워크 유틸리티 정리를 위해 찾아본 결과 download3k 역시 정리가 잘 돼있었다.





네트워크 캡쳐, 스니퍼를 사용할때는 컴퓨터의 성능과 하드디스크 용량을 잘 생각해서 동작시켜야 한다.

계속적인 캡쳐를 원할 경우는 파일을 지정 사이즈, 또는 시간을 지정 , 장기간 동작시 문제 발생하지 않게 해야 한다.


1. WireShark

Ethereal 로 초기부터 , 네트워크 캡쳐, 스니퍼 계의 강자였던 프로그램이

더욱 강력하고 간편해 졌다.

WireShark 에서 사용하기 위한 Preference, CaptureFilter, DisplayFilter 를 하나로 묶어 첨부한다.

기본 설정은 포트, 데이터 길이, 패킷간 시간 차이 등이 없어서 추가로 넣었다.

설정 파일을 사용자 계정 application data 폴더 아래에 넣어주면 된다. (복사 후 재시작해야 효과가 있음)


Wireshark를 이용하면, 네트워크 브로드캐스트 데이타의 캡쳐 (더미허브를 쓰는 경우에 한한다. 스위치허브에서는 안됨)
HTTP 문서의 확인

RTP 데이타의 분석 등 여러가지 기능이 가능하다.



* 사용하는 네트워크 카드/드라이버에 따라서 정상적인 경우인데도 TCP CheckSum Error 를 표시할 경우가 있다.

   일단은 칼라링정책에서 무시하도록 설정했다.


2. SmartSniff


WireShark 가 강려하지만 사용이 약간 어려운 반면, SmartSniff 는 간략하고 사용이 간편하다.

이 툴역시 캡쳐 필터, 디스플레이 필터를 사용해야 한다.

기본적인 설명은 툴에 나와있다.

웹사이트를 분석할 경우 최고로 사용할 수 있다. (데이타를 그냥 처리해서 문자로 보여준다.)




3. TcpView


sys internal 의 좋은 유틸리티 중 하나.

아쉽게도 마이크로소프트사에 먹혀 버렸지만

프로그램은 계속 무료로 사용가능하다.


컴퓨터에서 사용하는 네트워크 정보를 손쉽게 보여준다.

명령창을 열어서 (command/cmd) "netstat -pn tcp" 등 명령을 주어야 하지만

이 툴이 있다면, 사용중인 프로세스와 그 프로세스에서 사용하는 네트워크 리소스 (포트, 소켓상태)를 보여준다.



 


 


 

AND

출처: http://msdn.microsoft.com/ko-kr/library/350dyxd0.aspx

Visual Studio 디버거
방법: 데이터 중단점 설정(네이티브 전용)

업데이트: 2007년 11월

이 항목은 다음 언어에 적용됩니다.

Edition

Visual Basic

C#

C++

Web Developer

Express

항목이 적용되지 않음 항목이 적용되지 않음

네이티브 전용

항목이 적용되지 않음

Standard

항목이 적용되지 않음 항목이 적용되지 않음

네이티브 전용

항목이 적용되지 않음

Pro 및 Team

항목이 적용되지 않음 항목이 적용되지 않음

네이티브 전용

항목이 적용되지 않음

표의 범례:

항목이 적용됨

해당

항목이 적용되지 않음

해당 없음

항목이 적용되지만 명령은 기본적으로 숨겨짐

명령은 기본적으로 숨겨져 있습니다.

데이터 중단점을 사용하면 특정 메모리 위치에 저장된 값이 기록될 때 실행을 중단할 수 있습니다. 값을 쓰지 않고 읽을 때는 실행이 중단되지 않습니다.

디버깅되지 않는 프로세스에서 해당 메모리 위치에 쓰는 경우나 둘 이상의 프로세스에서 해당 메모리 위치를 공유하는 경우에는 데이터 중단점이 작동하지 않습니다. 커널 내에서 메모리 위치가 업데이트되는 경우에도 데이터 중단점이 작동하지 않습니다. 예를 들어 32비트 Windows ReadFile 함수에 메모리가 전달된 경우 커널 모드에서 메모리가 업데이트되므로 메모리에 쓸 때 디버거에서 실행이 중단되지 않습니다.

데이터 중단점을 설정하려면 디버거가 중단 모드여야 합니다.

변수의 주소는 디버깅 세션마다 달라집니다. 이러한 이유로 데이터 중단점은 각 디버깅 세션이 끝날 때 자동으로 해제됩니다.

데이터 중단점을 지역 변수에 설정한 경우에는 함수가 종료되어도 데이터 중단점이 설정된 상태로 유지됩니다. 그러나 설정된 메모리 주소의 의미는 달라집니다. 따라서 이러한 중단점의 결과는 예측할 수 없습니다. 지역 변수에 데이터 중단점을 설정한 경우에는 함수가 종료되기 전에 중단점을 제거하거나 해제하는 것이 좋습니다.

Visual Studio에서는 솔루션당 최대 4개의 데이터 중단점을 지원합니다.

참고:

표시되는 대화 상자와 메뉴 명령은 실제 설정이나 버전에 따라 도움말에서 설명하는 것과 다를 수 있습니다. 설정을 변경하려면 도구 메뉴에서 설정 가져오기 및 내보내기를 선택합니다. 자세한 내용은 Visual Studio 설정을 참조하십시오.

메모리 변경 중단점을 설정하려면

  1. 디버그 메뉴에서 새 중단점을 선택한 다음 새 데이터 중단점을 클릭합니다.

    — 또는 —

    중단점 창 메뉴에서 새로 만들기를 클릭한 다음 새 데이터 중단점을 선택합니다.

    새 중단점 대화 상자가 나타납니다.

  2. 주소 상자에 메모리 주소나 메모리 주소를 계산하는 식을 입력합니다. 예를 들어, &avar 를 입력하면 avar 변수의 내용이 바뀔 때 실행이 중단됩니다.

  3. 바이트 계산 상자에 디버거에서 조사할 바이트 수를 입력합니다. 예를 들어, 4를 입력하면 디버거에서 &myFunction부터 4바이트를 조사하고 이러한 바이트의 값이 변경되면 실행을 중단합니다.

  4. 확인을 클릭합니다.

AND

출처: http://blog.naver.com/98haruki?Redirect=Log&logNo=110039906083

 

windbg 명령어 정리 Win Internals

2008/12/31 10:14

복사 http://blog.naver.com/98haruki/110039906083

1) 커널의 모든 구조체 나열 : dt nt!_* (dt는 data type의 약자이고, nt는 윈도우 nt를 말하는게 아닐런지...ㅎㅎㅎ)

2) 커널의 특정 구조체 나열(인터럽트 관련) : dt nt!_*interrupt*

3) 특정 구조체의 구조 보기 : dt nt!_ktrap_frame

4) 특정 구조체 내의 하부 구조체까지 보는 명령 : dt nt!_ktrap_frame -r

5) 커널 내의 모든 스택 정보 보기 : !stacks 0

6) 시스템에 로드된 디바이스 드라이버 나열 : lm t n(lm은 list module의 약자 인듯...)


7) 전체 IDT(Interrupt Dispatch Table) 나열 : !idt -a

8) 빈번히(?) 호출된 interrupt 나열 : !idt => 어떤 빈도로 나열되는지 모르겠음.


9) 인터럽트 컨트롤러 나열 : !pic, !apic(작동 안함???)

10) io pic(programmable interrupt controller) 나열 : !ioapic


--------------------------------------- crash 분석 ---------------------------------------------------------

11) !analyze -v : 분석 결과 보기

12) kb : crash 당시의 커널 call stack 보기

13) !process -1 0 : crash 당시의 수행 중이던 프로세스

     !process -1 7 : crash 당시의 수행 중이던 프로세스의 상세 정보 출력(7이 상세 정보 출력 옵션임)

     - !process 0 0 : crash 당시의 가상메모리에 load 되어 있던 모든 프로세스(마지막이 0 flag 이므로, 간략히 출력 옵션임)

     - !process [process 시작주소] : 프로세스 관련 상세 정보 출력,

                                                   위의 커맨드로 시작주소를 알 수 있음.

     - 출력 정보 설명 :

        PROCESS : 프로세스의 정보가 들어있는 EPROCESS Block의 주소

        Cid : 프로세스 ID

        Peb : Process Environment Block 의 주소

        ParentCid : 부모 프로세스 ID

        Image : 프로세스 이름


14) !vm : crash 당시의 가상 메모리 사용 내역 요약 및 프로세스 리스트

15) !poolused : crash 당시의 커널 paged&nonpaged pool list

     - !poolused 2 : nonpaged pool 할당량 별로 정렬 후 출력

     - !poolused 4 : paged pool 할당량 별로 정렬 후 출력

16) !thread [thread 시작주소] : !process [process시작주소]를 하면 프로세스에 포함된 thread의 정보가

                                           나와서 확인 가능함.

     - 출력 정보 설명 : teb(thread environment block 시작 주소)

17) !locks : crash 당시 resource lock 정보

18) !handle : crash 당시에 open된 handle 정보 나열

     !handle [프로세스주소] : 해당 프로세스가 소유한 핸들을 출력함

     !handle [프로세스주소] f

19) !stack [프로세스주소] : 프로세스 관련 Stack 정보를 보여줌


--------------------------------------- hang 분석 ------------------------------------------------------

1) !analyze -hang -v : hang 분석을 해줌


--------------------------------------- !analyze -v 해석 ------------------------------------------------------

덤프에 따라, 일부 값은 안 나올수도 있음.


-v(verbose)  옵션은 상세 결과를 출력하게 함


1) FAULTING_IP : fault가 발생했을 때의 명령의 포인터 값

2) BUGCHECK_STR : 발생한 BUGCHECK을 설명하는 문장임.

                               BUGCHECK은 주로 커널 모드 fault와 연관이 있음.

3) DEFAULT_BUCKET_ID : 현재의 fault가 어떤 범주의 fault에 속하는지를 알려줌

4) LAST_CONTROL_TRANSFER : 스택에서 이뤄진 마지막 두 함수 호출을 보여준다.

                                               이들 주소에 ln 명령을 사용하면, 마지막 함수를 확인 가능함.

                                               (ln [주소] : 주소가 나타내는 심볼을 표시함)

5) STACK_TEXT : 스레드의 전체 스택 트레이스를 보여준다.

6) STACK_COMMAND : fault를 유발한 스레드의 stack trace를 구하기 위해 실행된 명령을 보여준다.

                                  ; 는 구분자임.

6) FOLLOWUP_IP : fault를 유발했을 가능성이 가장 큰 명령을 보여줌

7) SYMBOL_NAME : fault가 발생한 심볼의 이름을 보여줌

                              nt!ExDeferredFreePool+540 으로 나오는 것은 심볼이름이 아님. 주소를 나타냄

                              Private Symbol 이 없기 때문에 해당 주소의 구체적인 함수명 같은 심볼을 안 보여줌

                              (MS만 볼 수 있음)

8) FOLLOWUP_NAME : 이 fault를 누가 사후 점검해야 하는지를 나타냄

                                  보통 MachineOwner가 많음

9) IMAGE_NAME : fault가 발생한 이미지의 이름을 나타냄

10) MODULE_NAME : fault를 보이는 모듈의 이름을 나타냄

                              (lmvm [모듈명] 으로 조회 가능)

11) BUCKET_ID : fault가 속하는 문제의 범주를 보여줌

11) FOLLOW_UP : 이 fault에 가장 알맞은 소유자를 보여준다. 소유자를 찾을수 없다면 디폴트인 MachineOwner가 됨.

[출처] windbg 명령어 정리|작성자 난이

AND

출처: http://blog.naver.com/exit0828?Redirect=Log&logNo=30028292814

Visual Leak Detector(VLD) - 메모리 누수 추적 프로그램 MFC/C++

2008/02/27 13:41

복사 http://blog.naver.com/exit0828/30028292814

첨부파일 (1)

첨부파일 내용

 

 

설치 방법

 

1. 라이브러리 파일(vld.lib, vldmt.lib, vldmtdll.lib)을

C:\Program Files\Microsoft Visual Studio\VC98\Lib 에 복사한다.

 

2. 헤더 파일(vld.h, vldapi.h)을

C:\Program Files\Microsoft Visual Studio\VC98\Include 에 복사한다.

 

3. 프로그램이 시작하는 소스 파일 (App.h나 main함수가 있는 파일)에 vld.h 파일을 포함한다.

#include "vld.h"   을 최상위 라인에 적는다. 단, stdafx.h 파일을 포함할 경우, 그 다음 라인에 적는다.

 

4. 만약 운영 프로그램이 Windows2000 또는 이하 버전이라면 dbghelp.dll 파일을 프로그램의 Debug 폴더에 복사한다. 

 

5. 프로그램을 디버그 버전으로 빌드한다.

 

* 유의 사항 *

 

1. 사용자의 프로그램 경로에 한글이 있을경우 추적경로가 잘려서 제대로 나오지 않은 경우도 있음.

  ==> 이럴경우 폴더나 프로그램 이름을 영문으로 수정해야 함.

 

2. static, extern 선언 변수와 같이 프로그램이 종료되기 직전에 메모리를 해제하는 변수는 메모리릭으로 보여지는 경우도 있다.

 ==> vld가 실행되는 시점이 변수 해제 전이기 때문이다. app 파일에 최상위 라인에 적어도 해결이 안될 경우가 있으므로, 추적라인의 메모리 해제 부분이 있을 경우 브레이크를 걸어서 프로그램이 종료되고 들어오는 경우 그냥 넘어가도 될듯하다..;



AND