[WinDbg] Heap Corrupt - Overrun

-
힙오버런의 경우는 초기화안된 상태의 결과와는 틀릴 수 있다. 그냥 실행하는 경우에 문제가 없다고 나올 수 있는 것이다.

경험적으로 초기화안된 상태의 경우("Heap 손상 - 초기화안된 상황" 참조)
디버거에서 실행하는 경우 : 채움패턴으로 인해서 바로 AV를 발생시켜줌
그냥 실행하는 경우 : 보통 프로세스 종료시 문제 발생

힙오버런의 경우
디버거에서 실행하는 경우 : "Heap block at 00152E50 modified at 00152E6C past requested size of 14" 왼쪽과 같은 메시지를 뿌려준다. 아래 참조
보통 이 경우를 확인하는 첫번째 방법으로는 세그먼트가 정상적으로 보존되어 있는지를 확인해 보는것이 먼저 해야 할 순서이다. !heap 명령어를 쓰거나 Segments 멤버의 링크되어 있는 노드를 순서적으로 접근을 해 본다. 이렇게 해 보면 보통의 경우는 가장 마지막 노드의 메타데이터가 깨져 있는 것을 알 수가 있다.
그냥 실행하는 경우 : 이상없이 종료됨

00152e50  06 00 07 00 7d 07 1c 00-30 00 31 00 32 00 33 00  ....}...0.1.2.3.
00152e60  34 00 35 00 36 00 37 00-38 00 39 00 30 00 31 00  4.5.6.7.8.9.0.1.
00152e70  32 00 33 00 34 00 35 00-36 00 37 00 38 00 39 00  2.3.4.5.6.7.8.9.
파란색 : 메타데이터(8바이트)
빨간색 : 할당된 유저 영역(20바이트)
녹색 : 후위바이트영역(이 부분을 넘어서 사용하고 있어서 힙손상을 일으키고 있다.)

일반페이지힙을 설정한 후에 그냥 실행하는 경우에는 어플리케이션 베리파이어의 영향으로 손상지점을 좀더 쉽게 파악할 수가 있다.
gflags -p /enable "이미지 풀패스" 엔터

일반페이지힙과 비교해서 완전페이지힙은 손상시점의 확인을 나중에 확인이 아니라 즉시 확인을 할 수 있으나 너무 많은 자원을 소비하기 때문에 사용에 신중을 기해야 한다. 일단 이 부분은 패스...

댓글

댓글 쓰기

이 블로그의 인기 게시물

[WinAPI] 모달리스 다이얼로그 설명

-
이미지
출처 : http://www.winprog.org/tutorial/modeless_dialogs.html Now we take a look at CreateDialog() , DialogBox() 's sister function. The difference is that while DialogBox() implements it's own message loop and does not return untill the dialog is closed, CreateDialog() acts more like a window created with CreateWindowEx() in that it returns immediately and depends on your message loop to pump the messages as it does for your main window. This is termed Modeless , whereas DialogBox() creates Modal dialogs. You can create the dialog resource just like you did for the last dialog example, you might also want to set the "Tool window" extended style to give it's title bar the typical smaller caption of toolbars. The dialog resource I created follows: IDD_TOOLBAR DIALOGEX 0, 0, 98, 52 STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION EXSTYLE WS_EX_TOOLWINDOW CAPTION "My Dialog Toolbar" FONT 8, "MS Sans Serif" BEGIN PUSHBUTTON "...
자세한 내용 보기

[WinDbg] Debugging a stack overflow

-
참조 : http://msdn.microsoft.com/en-us/library/windows/hardware/ff540620(v=vs.85).aspx Debugging a Stack Overflow 5 out of 11 rated this helpful - Rate this topic A stack overflow is an error that user-mode threads can encounter. There are three possible causes for this error: A thread uses the entire stack reserved for it. This is often caused by infinite recursion. A thread cannot extend the stack because the page file is maxed out, and therefore no additional pages can be committed to extend the stack. A thread cannot extend the stack because the system is within the brief period used to extend the page file. When a function running on a thread allocates local variables, the variables are put on the thread's call stack. The amount of stack space required by the function could be as large as the sum of the sizes of all the local variables. However, the compiler usually performs optimizations that reduce the stack space required by a function. For example, if two...
자세한 내용 보기

[WinDbg] first-chance, second-chance Exception

-
First-chance Exception 이란 디버거에서 프로그램이 실행 중일 때 SEH 같은 Exception 처리 구문이 들어가 있는 코드를 실행 하다가 어떠한 이유에서 던지 Exception 이 일어 났고 그 Exception 에 대한 처리 코드가 존재 하여 처리가 되었음을 디버거에 알리는 것입니다. 이 Exception이 꼭 프로그램에 심각한 오류가 있음을 말하는 것은 아니며 Exception 처리 코드에 의해 해당 Exception이 안전하게 처리가 되었고 계속 실행할 수 있음을 의미 할 수 있습니다.(대개는 대부분 별 문제 없는 경우입니다.) 만약 그런 Exception에 대한 처리가 없는 경우 디버거는 이를 인지 하고 사용자에게 직접 Exception이 났음 을 알리는데 이를 Second Chance Exception 이라고 하고 이것이 우리가 프로그램 디버깅 중 흔히 보는 에러 상황이 되겠습니다. http://support.microsoft.com/kb/105675              __try              {                            bReturn = IsBadReadPtr(buffer, sizeof(buffer));                     ...
자세한 내용 보기