I started to get this error after switching on (for test purposes) the new setting "Beta: Use Unicode UTF-8 for worldwide language support" in the recent Windows 10 Spring 2018 update.

The message would then appear for every file that has non-ascii characters (German Umlauts mostly in my case) and had not been stored as UTF8 before.

Short-time fix: Revert the setting to not use UTF-8 as the "Current language for non-unicode programs", but use a language with the special characters that are used in the source files.

Long-time fix: Convert all your soure files to UTF-8.

ref : stackoverflow.com/questions/4305923/file-load-some-bytes-have-been-replaced-with-the-unicode-substitution-character

File Load Some bytes have been replaced with the Unicode substitution character while loading file

I was debugging in the .Net framework source code suddenly when I stepped into a file of theirs, visual studio 2010 raised this error: File Load: Some bytes have been replaced with the Unicode

stackoverflow.com

ERROR: Unable to create child process

1) delete .vs folder

2)

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

정적코드분석(static code analysis)을 통한 버그 탐지 (0)	2016.10.27
윈도우 심볼 다운로드 (0)	2013.06.15
C2086, C2084, LNK2005 오류에 대하여 (0)	2013.02.27
WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
병렬 스택 창 사용 (0)	2012.12.27

정적코드분석

컴퓨터 소프트웨어를 분석하는 방법 가운데 하나로 그 소프트웨어로부터 만들어진 프로그램을 실제로 실행해보지 않고 분석하는 방법이다. (프로그램을 실행해보고 분석하는 방법은 동적 프로그램 분석이다). 대부분의 경우 원시 코드의 형태를 가지고 분석을 수행하지만 목적 코드의 형태를 가지고 분석하는 경우도 있다. 일반적으로 사람이 어느 정도 프로그램에 대한 이해를 바탕으로 자동화된 도구를 이용해서 분석하는 것을 정적 프로그램 분석이라고 부른다. (from wiki)

정적코드분석이 무엇인지 더 자세히 알아보기 위해서 c++ 언어의 정적코드분석 툴중에 하나인 cppcheck를 예를 들어 설명해 보겠다.

아래의 소스코드는 아무런 에러없이 컴파일이 잘 된다.

using namespace std;
int main()
{
    char *pBuf = NULL;
    char *pBuf1 = NULL;
    FILE *pFile;
    char szBuf[1024];
    vectorstList(4, 1);
    vector::iterator itr;
    pBuf = (char *)malloc( 1024 );
    pBuf1 = (char *)malloc( 1024 );
    pFile = popen("pwd", "r");
    if ( pFile != NULL ) {
        if ( fgets( szBuf, sizeof(szBuf), pFile ) != NULL ) {
            printf("pwd : %s", szBuf);
        }
        fclose(pFile);
    }
    stList.push_back(2);
    stList.push_back(3);
    printf("stList : ");
    for ( itr= stList.begin(); itr != stList.end(); itr++ ) {
        printf("%d ", *itr);
    }
    printf("\n");
    for ( itr= stList.begin(); itr != stList.end(); itr++ ) {
        if ( *itr == 1 ) {
            stList.erase(itr);
            itr--;
        }
    }
    printf("stList : ");
    for ( itr= stList.begin(); itr != stList.end(); itr++ ) {
        printf("%d ", *itr);
    }
    printf("\n");
    delete pBuf1;
    return 1;
}
 
 
1# g++ -g -Wall -o test test.cpp
2# ./test
3pwd : /usr/esm/src/module/test
4stList : 1 1 1 1 2 3
5stList : 2 3
6#

하지만 정적코드분석 툴인 cppcheck 를 이용하면 소스코드의 버그를 발견할 수 있다.

`1`	`# cppcheck test.cpp`

`2`	`Checking test.cpp...`

`3`	`[test.cpp:50]: (error) Memory leak: pBuf`

`4`	`[test.cpp:49]: (error) Mismatching allocation and deallocation: pBuf1`

`5`	`[test.cpp:24]: (error) Mismatching allocation and deallocation: pFile`

`6`	`[test.cpp:38]: (error) Dangerous iterator usage. After erase the iterator is invalid so dereferencing it or comparing it with another iterator is invalid.`

7 #

cppcheck 에서 발견한 버그들은 Memory leak, Mismatching allocation and deallocation, Dangerous iterator usage 와 같은 버그들이 발견되었다.

정적소스코드 분석툴을 이용하여 모든 버그를 발견할 수는 없겠지만 프로그래머가 실수할 수 있는 부분에 대해서 다시 점검할 수 있도록 도와준다고 할 수 있겠다. 또는 미숙한 프로그래머에게는 좋은 학습도구가 될 수 있을 것으로 보인다.

[참고]
위키피디아 : List of tools for static code analysis
위키피디아 : cppcheck

[출처] 정적코드분석(static code analysis)을 통한 버그 탐지|작성자 강이

http://godway1225.blog.me/80120146362

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

Error : File Load Some bytes have been replaced with the Unicode substitution character while loading file, ERROR: Unable to create child process (0)	2020.12.16
윈도우 심볼 다운로드 (0)	2013.06.15
C2086, C2084, LNK2005 오류에 대하여 (0)	2013.02.27
WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
병렬 스택 창 사용 (0)	2012.12.27

https://www.visualstudio.com/downloads/download-visual-studio-vs

Visual Studio 다운로드

Visual Studio Community 2013 업데이트 5

Visual Studio Community 2013은 무료로 제공되고 모든 기능을 갖춘 IDE로, 강력한 코딩 생산성 기능, Windows, iOS 및 Android용 플랫폼 간 모바일 개발 도구, 그리고 수천 개의 확장에 대한 액세스를 제공합니다. 이 Visual Studio 버전은 비 엔터프라이즈 응용 프로그램 개발에 무료로 사용할 수 있습니다. 설치 후 Visual Studio 갤러리를 확인하세요. 도구, 컨트롤 및 템플릿에 빠르게 액세스하여, Visual Studio를 최대한 활용할 수 있도록 해줍니다.

참고: Visual Studio Community 2013(원본 릴리스 버전)이 이미 설치되어 있는 상태에서 이 다운로드를 실행하면 업데이트 5만 설치됩니다. Visual Studio Community 2013이 설치되어 있지 않은 상태에서 이 다운로드를 실행하면 Visual Studio Community 2013과 업데이트 5가 모두 설치됩니다. 두 경우 모두 Visual Studio 2013 언어 팩(원래 릴리스 버전)도 설치할 수 있습니다.

형식 선택: 웹 설치 관리자 ISO

오프라인으로 파일을 설치하는 방법

다운로드

Visual Studio Community 2013 업데이트 5 - 영어

Visual Studio 2013 언어 팩

Visual Studio 2013 언어 팩은 Visual Studio 사용자 인터페이스에 표시된 언어를 전환하는 데 사용할 수 있는 무료 추가 기능입니다.

언어 선택:

다운로드

Visual Studio 2013 언어 팩 - 체코어

다운로드

Visual Studio 2013 언어 팩 - 폴란드어

다운로드

Visual Studio 2013 언어 팩 - 터키어

다운로드

Visual Studio 2013 언어 팩 - 포르투갈어 - 브라질

다운로드

Visual Studio 2013 언어 팩 - 중국어(간체)

다운로드

Visual Studio 2013 언어 팩 - 중국어(번체)

다운로드

Visual Studio 2013 언어 팩 - 독일어

다운로드

Visual Studio 2013 언어 팩 - 영어

다운로드

Visual Studio 2013 언어 팩 - 스페인어

다운로드

Visual Studio 2013 언어 팩 - 프랑스어

다운로드

Visual Studio 2013 언어 팩 - 이탈리아어

다운로드

Visual Studio 2013 언어 팩 - 일본어

다운로드

Visual Studio 2013 언어 팩 - 한국어

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

멀티쓰래드 메모리릭 _CrtSetDbgFlag (0)	2013.10.24
[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace (0)	2013.05.22
디버깅및 메모리 누수 감지 툴들 (0)	2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07

아래 프로그램을 돌려보면 릭이 잡히기도 하고 안잡히기도 한다, 즉 프로그램 내에서 _CrtSetDbgFlag 으로는 한계가 있다는 것을 알 수 있다

#include <windows.h>

#include <crtdbg.h>

#include <process.h>

#include <iostream>

UINT WINAPI ProcessIO(LPVOID lpParameter)

{

int* p = new int;

return 0;

}

int _tmain(int argc, _TCHAR* argv[])

{

_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

UINT ulThreadID = 0;

HANDLE m_hThread = (HANDLE) _beginthreadex (NULL, NULL, ProcessIO, NULL, NULL, &ulThreadID);

CloseHandle(m_hThread);

WaitForSingleObject( m_hThread, INFINITE );

return 0;

}

http://happyq.egloos.com/3505278

음... 멀티스레드 프로그램에서 효과가 없다는 것은 Crt Debug함수에 대한 설명이었습니다. 그런 경우엔 LeakDiag 등의 다른 방법을 사용해야 합니다. ^^

Visual Leak Detector - Enhanced Memory Leak Detection for Visual C * Visual memory leak detector - 사내양's 개발자 노트 * Native Code에서 Memory Leak을 잡는 방법-1 - Leak Debugging(1) - CRT 디버그함수를 이용한 메모리 누수(Memory Leak) 탐지하기 * Umdh.exe를 사용하여 메모리 누수를 찾는 방법 - Private Bytes는 프로세스에 할당되었지만 다른 프로세스와 공유하지 않는 총 메모리 - Virtual Bytes는 프로세스가 사용하는 가상 주소 공간의 현재 크기를 바이트로 나타낸 것 - Virtual Bytes를 모니터링하여 가상 메모리가 사용되는지 확인* Debugging Tools for Windows (MSDN) - Debugging Tools for Windows - Overview (WHDC)* Leak Debugging(2) - LeakDiag로 메모리 누수 디버깅하기 (Debugging Memory Leak with LeakDiag) - 좋은 툴인 것 같다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

visual studio 2013 comunity 비주얼 스튜디오 2013 커뮤니티버전 (0)	2015.11.01
[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace (0)	2013.05.22
디버깅및 메모리 누수 감지 툴들 (0)	2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07

http://cafe.naver.com/windev/51

윈도우 심볼 다운로드

디버깅 시 콜스택을 보면 윈도우 모듈에서 에러가 발생한 경우 함수의 이름이 아니라

모듈에서의 주소로 표시됩니다. 사실 그 주소만 봐서는 구체적으로 어떤 함수인지 알기 어렵습니다.

그러나 윈도우 심볼을 설치하시면 그러한 주소만 나오는 것이 아니라 함수 이름으로 표시됩니다.

그러므로 자신이 사용하는 운영체제에 맞는 윈도우 심볼을 설치해 두고 개발하는 것이 편합니다.

아래 링크에서 윈도우 심볼을 받을 수 있으니 참고하시기 바랍니다.

http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

심볼을 설치하여 등록한 경우 Call stack에서 나타나는 모양은 다음과 같이 달라지게 됩니다.

(※ 심볼을 등록하려면 심볼이 설치된 폴더를 "Visual Studio > 도구 > 옵션 > 기호"에 등록해주시면 됩니다.)

그런 다음 도구->옵션->기호 로가서 심폴이 설치된 절대경로를 포함한다

window7이고 기본 상태의 경우 C:\Symbols 임

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

Error : File Load Some bytes have been replaced with the Unicode substitution character while loading file, ERROR: Unable to create child process (0)	2020.12.16
정적코드분석(static code analysis)을 통한 버그 탐지 (0)	2016.10.27
C2086, C2084, LNK2005 오류에 대하여 (0)	2013.02.27
WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
병렬 스택 창 사용 (0)	2012.12.27

sjh_VSstyle.WEW

오홍~

심볼은 d 드라이브에서 불러옴

BLOG main image

저작자표시 비영리 동일조건

'디버깅 & 스킬 > WinDbg 사용법' 카테고리의 다른 글

!analyze -v 명령 (0)	2012.12.23
비주얼스튜디오 스타일로 꾸민 windbg UI (0)	2012.12.14
[WinDbg] 6. 실행과 정지 (0)	2012.12.14
[ 세미나 1탄 ] WinDbg... Part 1. (0)	2012.12.12
WinDbg 명령어들 (0)	2012.12.09

http://www.codeproject.com/Articles/3134/Memory-Leak-and-Exception-Trace-CRT-and-COM-Leaks

Introduction

With this utility you can simply find memory leaks in your program (CRT and COM-Leaks!). Each leak is displayed with the callstack (including the source line) of the allocation. So, you can easily find leaks, while using the STL. It will also write a file with the callstack if your application crashes (it can also handle stack-overflows!). It almost has no runtime-overhead (runtime-cost). And the best: it is free (GNU Lesser General Public License).

Finding memory leaks

It is easy to implement this in your existing VC code:

Add Stackwalker.cpp and Stackwalker.h to your project.
Include Stackwalker.h in your main source file.
Call InitAllocCheck() right after the beginning of your main.
Call DeInitAllocCheck() just before the end of your main (here all the leaks will be reported).

All the leaks will be listed in the file YouAppName.exe.mem.log in the application directory (only in debug builds; it is deactivated for release builds). This will also activate exception-handling by default (release and debug builds).

Only use exception-handling

If you only want to use exception handing, you need to do the following:

Add Stackwalker.cpp and Stackwalker.h to your project.
Include Stackwalker.h in your main source file.
Call OnlyInstallUnhandeldExceptionFilter() right after the beginning of your main.

If an exception occurs, it will write a file with the callstack in the application directory with the nameYouAppName.exe.exp.log.

Example

A simple example is given below:

Collapse | Copy Code

#include <windows.h>
#include "Stackwalker.h"

void main()
{
  // Uncomment the following if you only
  // need the UnhandledException-Filter
  // (to log unhandled exceptions)
  // then you can remove the "(De)InitAllocCheck" lines
  //OnlyInstallUnhandeldExceptionFilter();

  InitAllocCheck();

  // This shows how the mem-leak function works
  char *pTest1 = new char[100];

  // This shows a COM-Leak
  CoTaskMemAlloc(120);

  // This shows the exception handling
  // and log-file writing for an exception:
  // If you want to try it, please comment it out...
  //char *p = NULL;
  //*p = 'A'; // BANG!

  DeInitAllocCheck();
}

If you execute this example, you will get a file Appication-Name.exe.mem.log with the following content:

Collapse | Copy Code

##### Memory Report ########################################
11/07/02 09:43:56

##### Leaks: ###############################################
RequestID:           42, Removed: 0, Size:          100
1: 11/07/02 09:43:56
1: f:\vs70builds\9466\vc\crtbld\crt\src\dbgheap.c(359)
                              +30 bytes (_heap_alloc_dbg)
1: f:\vs70builds\9466\vc\crtbld\crt\src\dbgheap.c(260)
                              +21 bytes (_nh_malloc_dbg)
1: f:\vs70builds\9466\vc\crtbld\crt\src\dbgheap.c(139) +21 bytes (malloc)
1: f:\vs70builds\9466\vc\crtbld\crt\src\newop.cpp(12) +9 bytes (operator new)
1: d:\privat\memory_and_exception_trace\
            memory_and_exception_trace\main.cpp(9) +7 bytes (main)
1: f:\vs70builds\9466\vc\crtbld\crt\src\crt0.c(259)
                               +25 bytes (mainCRTStartup)

**** Number of leaks: 1

##### COM-Leaks: ###############################################
(shortened)
**** Number of leaks: 1

Explanation

Now, I will explain the Memory-Report-File:

Collapse | Copy Code

RequestID:           42, Removed: 0, Size:          100

This line is the beginning of one leak. If you have more than one leak, then each leak will start with a RequestID.

RequestID
For CRT: This is the RequestID which is passed to the AllocHook. This ID clearly identifies an allocation. The CRT just increments this number for each allocation. You can also use this number with the_CrtSetBreakAlloc function.
For COM: This is the address of the allocated memory.
Removed
In a memory leak dump this must always be 0 (false).
Size
This is the size of the allocated memory block.

Collapse | Copy Code

1: f:\vs70builds\9466\vc\crtbld\crt\src\dbgheap.c(359)
                                   +30 bytes (_heap_alloc_dbg)

This is an actual stack entry. The stack is shown from the last function on the top going through each callee until the end of the stack is reached.

1:
This number is incremented for each complete callstack. You can ignore this.
f:\vs70builds\9466\vc\crtbld\crt\src\dbgheap.c
The actual filename.
(359)
The line number inside the file.
+30 bytes
This is the offset from this line in bytes (if a line produces more than one assembler instruction).
(_heap_alloc_dbg)
The name of the function.

More options by calling InitAllocCheck

InitAllocCheck has three parameters:

Parameter name Description

Parameter name	Description
`eAllocCheckOutput` `eOutput`	This is an `enum` for output-format. The following is possible: `ACOutput_Simple` (default) This outputs the callstack as seen above. `ACOutput_Advanced` This has a more detailed output of the callstack. For more info seehere. `ACOutput_XML` This outputs the leaks in an XML file so that you can read it easily from other applications or use some XSLT to transform it to a more readable format you want. For more info see here.
`BOOL` `bSetUnhandledExeptionFilter`(default: `TRUE`)	If this is set, an `UnhandledExceptionFilter` will be installed. If an (unhandled) exception occurs it will write the callstack in a log file and terminate. For more info see here.
`ULONG` `ulShowStackAtAlloc` (default: `0`)	Notice: This works only for CRT-`alloc`s. Here you can specify the level of `malloc`s/`free`s logging. By default nothing will be logged in the log file at runtime. If you need to know what happens while executing the program you can specify a value. Then the`malloc`/`free` action will be logged to the file (either with or without callstack). Valid values are: `0` = Do not write any output during runtime-`alloc`-call (default). `1` = Write only the `alloc` action (`malloc`, `realloc`, `free`). `2` = Write `alloc` action and callstack only for `malloc`/`realloc`. `3` = Write `alloc` action and callstack for all actions.

eAllocCheckOutput
eOutput

This is an enum for output-format. The following is possible:

ACOutput_Simple (default)
This outputs the callstack as seen above.
ACOutput_Advanced
This has a more detailed output of the callstack. For more info seehere.
ACOutput_XML
This outputs the leaks in an XML file so that you can read it easily from other applications or use some XSLT to transform it to a more readable format you want. For more info see here.

BOOL
bSetUnhandledExeptionFilter(default: TRUE)

If this is set, an UnhandledExceptionFilter will be installed. If an (unhandled) exception occurs it will write the callstack in a log file and terminate. For more info see here.

ULONG
ulShowStackAtAlloc (default: 0)

Notice: This works only for CRT-allocs.

Here you can specify the level of mallocs/frees logging. By default nothing will be logged in the log file at runtime. If you need to know what happens while executing the program you can specify a value. Then themalloc/free action will be logged to the file (either with or without callstack).

Valid values are:

0 = Do not write any output during runtime-alloc-call (default).
1 = Write only the alloc action (malloc, realloc, free).
2 = Write alloc action and callstack only for malloc/realloc.
3 = Write alloc action and callstack for all actions.

Log-output with more info

You can also get an output with more info about each stack entry. For this you have to call InitAllocCheck with the first parameter set to ACOutput_Advanced. If you execute the following sample you will get a file Appication-Name.exe.mem.log with more info:

Collapse | Copy Code

#include <windows.h>
#include "Stackwalker.h"

void main()
{
  InitAllocCheck(ACOutput_Advanced);
  // This shows how the mem-leak function works
  char *pTest1 = new char[100];
  DeInitAllocCheck();
}

And here is the (shortened) output:

Collapse | Copy Code

##### Memory Report ########################################
11/04/02 09:04:04

##### Leaks: ###############################################
RequestID:           45, Removed: 0, Size:          100
1: 11/04/02 09:04:04
// ...
1:   5     main +49 bytes
1:     Decl: main
1:     Line: d:\privat\memory_and_exception_trace\main.cpp(27) +7 bytes
1:     Mod:  Memory_and_Exception_Trace, base: 00400000h

1:   6     mainCRTStartup +363 bytes
1:     Decl: mainCRTStartup
1:     Line: f:\vs70builds\9466\vc\crtbld\crt\src\crt0.c(259) +25 bytes
1:     Mod:  Memory_and_Exception_Trace, base: 00400000h

1:   7     _BaseProcessStart@4 +35 bytes
1:     Decl: _BaseProcessStart@4
1:     Mod:  kernel32, base: 77e40000h

**** Number of leaks: 1
// ...

Explanation

Here, I will explain the Memory-Report-File:

Collapse | Copy Code

RequestID:           45, Removed: 0, Size:          100

This line is the same as above:

Collapse | Copy Code

1:   5     main +49 bytes

1:
This number is incremented for each complete callstack. You can ignore this.
5
This is the depth of the callstack. This number is incremented for each stack entry. The stack is shown from the last function on the top (number 0) going through each callee until the end of the stack is reached.
main +49 bytes
The number of bytes from the beginning of this function, where the instruction for this callstack is stored.

Collapse | Copy Code

1:     Decl: main
1:     Line: d:\privat\memory_and_exception_trace\main.cpp(27) +7 bytes
1:     Mod:  Memory_and_Exception_Trace, base: 00400000h

Decl: main
This is the declaration of the function.
Line: ....xyz.cpp(27) +7 bytes
This shows the actual line (in brackets) of the callstack (here: line 27). In addition, it gives the offset from this line in bytes (if a line produces more than one assembler instruction).
Mod: Memory_and_Exception_Trace
The name of the module (EXE, DLL, OCX, a.s.o.).
base: 00400000h
The base address of this module.

XML output

If you set the first parameter to ACOutput_XML an XML file will be produced. It has the following contents:

Collapse | Copy Code

<MEMREPORT date="11/08/02" time="10:43:47">
  <LEAK requestID="47" size="100">
    <!-- shortened -->
    <STACKENTRY decl="main" decl_offset="+100"
                    srcfile="d:\...\main.cpp" line="16"
      line_offset="+7" module="Memory_and_Exception_Trace" base="00400000"/>
    <STACKENTRY decl="mainCRTStartup" decl_offset="+363"
                    srcfile="f:\...\crt0.c" line="259"
      line_offset="+25" module="Memory_and_Exception_Trace" base="00400000"/>
  </LEAK>
</MEMREPORT>

It is pretty self explaining if you take a look at the "advanced log output".

Mem-leak-analyse tool

If you are using the XML-output format then you can use my MemLeakTool to display the leaks in a sorted order (sorted by callstack). Just select the "xml-leak"-File and press "Read". The callstack will be displayed in a TreeView. If you select a node, the source code will be shown in the right part (if it could be found).

Information: This program requires .NET Framework 1.0!

A word on leaks

You should be aware, that some leaks might be the result of other leaks. For example the following code throws two leaks, but if you remove the "originator" of the leaks, the other leak will also disappear. For example:

Collapse | Copy Code

#include <windows.h>
#include <stdlib.h>
#include "stackwalker.h"
class MyTest
{
  public:
    MyTest(const char *szName)
    {
      // The following is the second resulting leak
      m_pszName = strdup(szName);
    }
    ~MyTest()
    {
      if (m_pszName != NULL)
        free(m_pszName);
      m_pszName = NULL;
    }
  protected:
    char *m_pszName;
};

void main()
{
  InitAllocCheck();

  // This is the "main" leak
  MyTest *pTest = new MyTest("This is an example");

  DeInitAllocCheck();
}

How it works (CRT)

The basis of the memory leak logger is a Hashtable with information about all the allocated memory (including callstack). Basically _CrtSetAllocHook is called to hook all the memory allocations / frees. Therefore only C/C++ allocations are logged. On every allocation a portion of the callstack and the Instruction-Pointer is caught and stored in the Hashtable, with some other information about the allocation.

If the application calls DeinitAllocCheck then the Hashtable will be iterated and the (saved) callstack of all the entries will be listed in the file. For this we provide a pointer to our ProcessMemoryRoutine function to theStackWalk function.

In detail

Hashtable

The Hashtable contains by default 1024 entries. You can change this value if you are doing many allocations and want to reduce the collisions. Just change the ALLOC_HASH_ENTRIES define.

As hash-key, the lRequestID for each allocation is used. This ID is passed to the AllocHook function (at least forallocs). If it is not passed (for example, for freeing), then an (valid) address is passed. By having this address it is also possible to get the lRequestID, by looking into the _CrtMemBlockHeader of the allocated block.

For hashing, a very simple and fast hash-function is used:

Collapse | Copy Code

static inline ULONG AllocHashFunction(long lRequestID) {
  return lRequestID % ALLOC_HASH_ENTRIES;
}  // AllocHashFunction

Insert an allocation into the Hashtable

If a new allocation should be inserted into the Hashtable, first a thread context for the actual thread is made by callingGetThreadContext. This function requires a "real" thread handle and not a pseudo handle which is returned byGetCurrentThred. So, for this I have to create a "real" handle by calling DuplicateHandle.

Actually, I only need the current Ebp and Eip registers. This could also be done by just reading the registers with the inline assembler. Now having the registers, I read the memory at the specified address. For Eip, I only need to read 4 bytes. I do not know why StackWalk needs to read the Eip values, but if the values could not be read fromStackWalk it fails to build the callstack. The real important part is the callstack which is stored in the memory pointing from Ebp (or Esp).

At the moment, I just try to read 0x500 bytes by calling the ReadProcessMemory function. I don't read the complete stack, because it might use too much memory for many allocations. So, I reduced the maximum size to 0x500. If you need a deeper callstack, you can change the MAX_ESP_LEN_BUF define.

If the callstack is not 0x500 bytes deep, then the ReadProcessMemory will fail with ERROR_PARTIAL_COPY. If this happens, I need to ask how many are possible, to read without any error. For this I need to query this value by callingVirtualQuery. Then, I try to read as many bytes as possible.

Having the callstack I can simply insert the entry into the Hashtable. If the given hash-entry is already occupied, I make a linked list and append this entry to the end.

Building the leak-list

If you call DeInitAllocCheck I simply walk through the Hashtable and output every entry which was not freed. For this I call StackWalk with a pointer to my own memory-reading-function (ReadProcMemoryFromHash). This function is called from the internals of StackWalk. If it is called it looks up the Hashtable for the given lRequestID and returns the memory which was stored in the Hashtable. The lRequestID is passed in the hProcess parameter of theStackWalk function (as stated in the documentation of StackWalk).

Ignoring allocations

Allocations/frees for _CRT_BLOCK are ignored (for more info, see here). This is because CRT dynamically allocates some memory for "special purposes". The tool also checks the _CRTDBG_ALLOC_MEM_DF flag of the _crtDbgFlag variable. If it is off, then all the allocations are ignored. For more details see _CrtSetDbgFlag.

How it works (COM)

To track COM-memory-leaks, you have to provide an IMallocSpy interface. This interface must be registered withCoRegisterMallocSpy. After that the (own) IMallocSpy instance is called for every memory (re)allocation/free. So, you can track all memory actions.

The storage of the callstack is done in the same way as for CRT-allocs (in a Hashtable). So, for more info please read the CRT-section.

A word on COM-leaks

Actually, there is nothing to say, but...

If you are using MSXML 3 or 4 implementation, you have to be aware of the fact that this parser uses a "smart" pseudo-garbage collector. This means that they allocate memory and will not free it after it is used! So, you may see some leaks which are only "cached memory". If you first call CoUninitialize, then all the cached memory will be freed and the "real" COM-leaks will be reported.

For more info see: Understanding the MSXML Garbage Collection Mechanism.

MFC usage

The problem with MFC is that the derived CWinApp class is instantiated by the C-runtime, because it is a global variable. The easiest solution to implement the Leak-Finder is to declare the following static struct inside yourMainApp.cpp.

You also have to add stackwalk.cpp and stackwalk.h to your project. You also need to add the #include<stdafx.h> on top of the stackwalk.cpp file (if you use precompiled headers). A sample of an MFC application is also available from the top of this article:

Collapse | Copy Code

static struct _test
{
  _test()
  {
    InitAllocCheck();
  }

  ~_test()
  {
    DeInitAllocCheck();
  }
} _myLeakFinder;

Temporarily disable logging (only CRT)

When you don't want to log a special allocation of your application (for whatever reason; MFC does this often), then you can simply deactivate it by disabling the CRT flag _CRTDBG_ALLOC_MEM_DF with the _CrtSetDbgFlag function. Here is an example of how you can do this:

Collapse | Copy Code

#include "Stackwalker.h"

#include <crtdbg.h>

bool EnableMemoryTracking(bool bTrack)
{
  int nOldState = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
  if (bTrack)
    _CrtSetDbgFlag(nOldState | _CRTDBG_ALLOC_MEM_DF);
  else
    _CrtSetDbgFlag(nOldState & ~_CRTDBG_ALLOC_MEM_DF);
  return nOldState & _CRTDBG_ALLOC_MEM_DF;
}

void main()
{
  InitAllocCheck();

  // The following will be logged
  char *pTest1 = new char[100];

  EnableMemoryTracking(false);  // disable logging
  // The following will NOT be logged
  char *pTest2 = new char[200];
  EnableMemoryTracking(true);  // enable logging

  // The following will be logged
  char *pTest3 = new char[300];

  DeInitAllocCheck();
}

Unhandled exceptions

There are three ways to use this tool for unhandled exceptions.

Simple using

If you just call InitAllocCheck with no parameters or with the second parameter set to TRUE, then an unhandled exception filter will be installed. If an unhandled exception occurs, a log file with the callstack will be written, a dialog box with the exception message will be displayed, and the application will be terminated with FatalAppExit.

Second simple using

If you don't want the AllocCheck-overhead (the (small) overhead is only present in debug builds), you can simply callOnlyInstallUnhandeldExceptionFilter. This will install the UnhandledExceptionFilter which writes a log file if an (unhandled) exception occurs. The log file will be stored in the application directory with the nameYouAppName.exe.exp.log:

Collapse | Copy Code

int main()
{
  OnlyInstallUnhandeldExceptionFilter();

  // do your main code here...
}

Advanced using

You can write your own exception filter and just call StackwalkFilter to produce the callstack. Then you can do whatever you want. Here is a small example:

Collapse | Copy Code

static LONG __stdcall MyUnhandlerExceptionFilter(EXCEPTION_POINTERS* pExPtrs)
{
   LONG lRet;
   lRet = StackwalkFilter(pExPtrs,
             EXCEPTION_EXECUTE_HANDLER, _T("\\exception.log"));
   TCHAR lString[500];
   _stprintf(lString,
      _T("*** Unhandled Exception!\n")
      _T("   ExpCode: 0x%8.8X\n")
      _T("   ExpFlags: %d\n")
      _T("   ExpAddress: 0x%8.8X\n")
      _T("   Please report!"),
      pExPtrs->ExceptionRecord->ExceptionCode,
      pExPtrs->ExceptionRecord->ExceptionFlags,
      pExPtrs->ExceptionRecord->ExceptionAddress);
   FatalAppExit(-1,lString);
   return lRet;
}

int main()
{
  InitAllocCheck(ACOutput_Advanced, FALSE);
  SetUnhandledExceptionFilter(MyUnhandlerExceptionFilter);

  // do some stuff...

  DeInitAlloocCheck();
}

Common mistakes

One of the most common mistakes while using this tool is that you statically instantiate classes in your main function. The problem is that the destructor of the class is called after the call to DeInitAllocCheck. If some memory was allocated inside this class, this memory will appear as a leak. For example:

Collapse | Copy Code

#include <windows.h>
#include "Stackwalker.h"
#include <string>

void main()
{
  InitAllocCheck();
  std::string szTemp;
  szTemp = "This is a really long string";
  DeInitAllocCheck();
}

There are two solutions for this. You can start a block after the call to InitAllocCheck and end it before the call toDeInitAllocCheck. With this you can be sure that the destructors are called before the leak file is produced. For example:

Collapse | Copy Code

#include <windows.h>
#include "Stackwalker.h"
#include <string>

void main()
{
  InitAllocCheck();
  {
    std::string szTemp;
    szTemp = "This is a really long string";
  }
  DeInitAllocCheck();
}

The second solution is to use the same technique that is used for MFC applications (see above).

Visual Studio 7 and Win2K / NT

I found a problem with the executables built with VS7 and run on Win2K or NT. The problem is due to an old version ofdbghelp.dll. The PDB files generated from VS7 are in a newer format (DIA). It appears that the VS installations do not update dbghelp.dll on Win2K. So the original version (5.0.*) is still on the system and will be used. But with this version it is not possible to read the new PDB format. So, no callstack can be displayed.

To get it to work you have to do the following

Download the latest Debugging Tools for Windows (which includes dbghelp.dll). You have to install it to get the files. But you only need the dbghelp.dll! Now we have another problem. The installer does not replace the originaldbghelp.dll. So we need to copy the dbghelp.dll in our EXE dir. Now to make sure the right version is loaded you have to put a file with the name appname.local in your EXE dir (please replace appname with the EXE name (without extension)). Now it should also work on WinNT/2K.

Known issues

The memory leak works correctly only if the lRequestID does not wrap (32-bit value). If the value wraps around, then it is not possible to clearly assign a given lRequestID to a previous allocation, because it is possible that this ID was used twice (or even more). But this happens only with VC7, because VC6 has a bug in the C-runtime which will call _DbgBreak if the lRequestID wraps (if no _CrtBreakAlloc is used).
If you compile with "Detect 64-bit portability issues (/Wp64)" option on VC7, it will generate a warning.
If you use this tool in managed C++ it will not correctly display the callstack for managed code.
For some reason, the COM-alloc-callstack cannot display the stack-entry which really calls theCoTaskMemAlloc function. Only the upper stack entry can be shown.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

visual studio 2013 comunity 비주얼 스튜디오 2013 커뮤니티버전 (0)	2015.11.01
멀티쓰래드 메모리릭 _CrtSetDbgFlag (0)	2013.10.24
디버깅및 메모리 누수 감지 툴들 (0)	2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07

http://cafe.naver.com/xheaven/205

1.LeakDiag

사용 시나리오 : 메모리 누수 탐지 툴

다운로드 주소 :

ftp://ftp.microsoft.com/pss/tools/developer support tools/LeakDiag/leakdiag125.msi

2. Debugging Tools for Windows

사용 시나리오 : 디버거와 툴의 모임

다운로드 주소 :

http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx

커스텀 디버거 익스텐션을 작성하기 위해서는 커스텀 설치와 SDK 모두 설치를 해야한다.

1) UMDH

사용 시나리오 : 메모리 누수 탐지

2) gFlags

사용 시나리오 : 구성 설정

3.Microsoft Application Verifier

사용 시나리오 :일반 어플리케이션 문제 해결

다운로드 주소 :

http://www.microsoft.com/downloads/details.aspx?FamilyID=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en

4.프로세스 익스플로러(Process Explorer)

사용 시나리오 : 시스템과 프로세스의 전반적인 상태 분석

다운로드 주소 :

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

5.프로세스 모니터 (Process Monitor)

사용 시나리오 : 파일 시스템과 레지스트리, 프로세스와 스레드 동작을 보여주는 감시툴

다운로드 주소 :

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

6.윈도우 드라이버 킷 (WDK)

사용시나리오 : 일반 개발

다운로드 주소 :

http://www.microsoft.com/whdc/devtools/WDK/default.mspx

7.Wireshark

사용시나리오 : 네트워크 프로토콜 분석기

다운로드 주소:

http://www.wireshark.org/download.html

8.DebugDiag

사용 시나리오 : 프로세스 문제(메모리 누수와 크래시)해결

다운로드 주소:

https://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

멀티쓰래드 메모리릭 _CrtSetDbgFlag (0)	2013.10.24
[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace (0)	2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02

http://www.borland.com/products/devpartner/

http://www.borland.com/products/devpartner/try/devpartnervisualcboundscheckersuite.aspx 에서 작성하고 다운 받을 수 있다 [트라이얼임]

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace (0)	2013.05.22
디버깅및 메모리 누수 감지 툴들 (0)	2013.05.22
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02
Visual Studio 2010을 사용한 코딩 개선 (0)	2012.12.27

http://www-01.ibm.com/software/awdtools/purify/

Rational Purify

Product line

Rational® Purify® is a dynamic software analysis tool designed to help developers write more reliable code. It includes two capabilities: 1) Memory debugging (pinpoints hard to find memory errors such as uninitialized memory access, buffer overflow and improper freeing of memory), 2) Memory leak detection (identifies memory blocks that no longer have a valid pointer). Purify is supported on Windows®, Linux®, Solaris®, and AIX®.

Product Editions

Compare editions

Purify for Linux and UNIX

Dynamic software analysis tool for UNIX application development

Purify for Windows

Dynamic software analysis tool for Windows application development

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

디버깅및 메모리 누수 감지 툴들 (0)	2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02
Visual Studio 2010을 사용한 코딩 개선 (0)	2012.12.27
심볼 스토어 생성 (0)	2012.12.23

http://blog.naver.com/tipsware/100149886155

먼저 오류번호 앞에 C 가 붙어 있으면 컴파일 오류코드라는 뜻이고 LNK 가 붙어 있으면 컴파일은 성공했지만 링크(link) 작업을

하다가 생긴 오류코드라는 뜻입니다.

"소스파일(*.c, *.cpp)" -> 컴파일 -> "목적파일(*.obj)" -> 링크 -> "실행파일(*.exe)"

1. C2086 오류코드

C/C++ 언어에서는 전역변수를 동일한 이름으로 중복해서 선언할수 없기 때문에 이와같은 컴파일 오류가 발생합니다.

( g_data 전역변수를 중복해서 선언하여 발생한 오류 )

이런경우는 대부분 전역변수를 많이 사용하는 프로그래머들이 실수로 이름을 중복 사용해서 발생하며 중복된 이름을

다른 이름으로 변경하여 오류를 수정해야합니다.

int g_data;
int g_data; // error C2086: 'g_data' : redefinition

void main()
{

}

2. C2084 오류코드

C 언어에서는 함수를 동일한 이름으로 중복해서 정의할수 없기 때문에 이와같은 컴파일 오류가 발생합니다. C++ 에서는

함수의 오버로딩을 사용하여 동일한 이름을 가진 함수를 정의할수 있지만 아래와 같이 동일한 이름과 동일한 매개변수 구조를

가진 경우에는 오버로딩이 적용되지 않기 때문에 아래와 같이 오류가 발생합니다.

( Test 라는 함수가 같은 소스내에 중복해서 정의 되었기 때문에 발생하는 오류 )

    void Test()
    {
    }

    void Test()    // error C2084: function 'void __cdecl Test(void)' already has a body
    {
    }

    void main()
    {
        Test();
    }

3. LNK2005 오류코드

다양한 기능을 가진 프로그램을 하다보면 하나의 소스파일로 작업하지 않고 의미있는 코드를 그룹지어 여러개의

소스로 나누어 작업하는 경우도 많습니다. 예를들의 자신의 프로젝트가 Exam1.cpp 의 소스파일로만 구성될수도

있지만 Exam1.cpp, Exam2.cpp 와 같이 두개의 소스 파일로 구성될수도 있습니다.

프로젝트를 구성하고 있는 소스파일은 관리를 편하게 하기 위해서 나누어진것일뿐 실제로는 하나의 소스라고

생각하시면 됩니다. 따라서 자신의 프로젝트가 Exam1.cpp, Exam2.cpp 이라는 두개의 소스 파일로 구성되어

있고 아래와 같이 소스를 작성해보겠습니다.

// Exam1.cpp

int g_data;

void main()

{

}

// Exam2.cpp

int g_data;

void Test()

{

}

위 예제를 컴파일해보면 각각의 소스파일에는 문제가 없기 때문에 정상적으로 컴파일되어 Exam1.obj, Exam2.obj 로

목적파일이 만들어집니다. 하지만 두개의 목적파일을 링크하여 실행파일 만드는 과정에서 아래와 같은 오류가

발생합니다. 이것은 각각 소스에서 사용한 g_data 라는 전역변수가 전체 프로그램(프로젝트)에서 봤을때는 중복해서

선언된 것이기 때문에 오류처리된 것입니다. 즉, 전역변수는 단위소스에서만 전역적으로 사용 가능한것이 아니라

프로그램(프로젝트) 전체에서 전역적으로 사용한것이기 때문입니다.

int g_data" (?g_data@@3HA) already defined in Exam1.obj

이렇게 발생한 오류를 해결하는 방법은 크게 두가지 입니다.

3.1 두개의 전역변수가 이름은 같지만 서로 다른 의미로 사용된 경우

가장 간단한 방법은 둘중에 한개의 전역변수의 이름을 변경하는 것입니다. 하지만, 여러가지 이유로 이름을 변경할 수

없는 상황이라면 아래와 같이 전역변수 앞에 static 키워드를 붙여서 사용하면 오류를 제거할수 있습니다.

( 중복된 두개의 전역변수중에 한군데만 static 을 사용해도 오류가 제거됩니다. )

static int g_data;

전역변수 앞에 static 키워드를 사용하면 해당 소스파일에서만 전역적으로 사용할수 있는 전역변수로 범위가 한정됩니다.

3.2 두개의 전역변수가 같은 의미로 사용된 경우 ( 동일한 변수 이여야 하는 경우 )

하나의 전역변수를 두개의 소스파일에서 사용하고 싶은 경우라면 한쪽을 원본으로 하고 나머지 한쪽은 참조하는 형식으로

선언해서 사용해야 합니다. 위와 같은 경우라면 Exam1.cpp 에 선언된 g_data 전역 변수는 그대로 유지하고 Exam2.cpp 에

선언된 g_data 전역변수 앞에 extern 키워드를 추가해서 사용하면 됩니다. 소스를 재구성해보면 아래와 같습니다.

// Exam1.cpp

int g_data;

void main()

{

}

// Exam2.cpp

extern int g_data;

void Test()

{

}

extern 을 전역변수 선언에 같이 사용하면 전체 프로그램(프로젝트)내에 동일한 이름을 가진 전역변수가 존재하고

그 전역변수를 이 소스파일에서 참조해서 사용하겠다는 뜻이됩니다.

LNK2005 오류는 전역변수에서만 발생하는것이 아니라 함수도 같은 이름을 사용하면 발생합니다. ( 오버로딩이 적용 안되는 경우 )

아래와 같이 Exam1.cpp 와 Exam2.cpp 가 하나의 프로젝트에 포함되어 있다면 각각의 소스파일은 정상적으로 컴파일 되겠지만

링크시에

void __cdecl Test(void)" (?Test@@YAXXZ) already defined in Exam1.obj

이라는 오류가 발생합니다. 이것도 하나의 프로그램(프로젝트)에 동일한 이름을 가진 두개의 함수가 정의 되었기 때문에

발생한 오류입니다.

// Exam1.cpp

void Test()

{

}

void main()

{

Test();

}

// Exam2.cpp

void Test()

{

}

void MyFunc()

{

Test();

}

이 문제를 해결하려면 전역변수와 마찬가지로 두가지 해결 방법이 있습니다.

3.3 두개의 함수가 이름은 같지만 서로 다른 의미로 사용된 경우

전역변수와 마찬가지로 두개의 함수의 이름을 다르게 하거나 해당 함수앞에 static 키워드를 사용하여 사용범위를 제한하면

오류를 해결할수 있습니다. 이때도 둘중에 한곳에만 static 을 사용하면 됩니다.

// Exam1.cpp

void Test()

{

}

void main()

{

Test();

}

// Exam2.cpp

static void Test()

{

}

void MyFunc()

{

Test(); // Exam2.cpp 에 있는 Test 함수가 호출됨

}

3.4 두개의 함수가 동일하게 사용되어야 하는 경우 ( 양쪽 소스에서 같은 Test 함수를 호출하고 싶은 경우 )

같은 프로젝트에 포함된 다른 소스에 존재하는 함수를 사용하고 싶다면 해당 함수의 원형(prototype)만 선언해주고

사용하면 됩니다.

// Exam1.cpp

void Test()

{

}

void main()

{

Test();

}

// Exam2.cpp

void Test(); // 사용하고 싶은 함수의 원형을 명시한다.

void MyFunc()

{

Test(); // Exam1.cpp 에 있는 Test 함수가 호출됨

}

사실 위와 같은 경우는 소스를 수정하여 오류를 제거할수 있기 때문에 이런 오류 코드가 문제가 되지 않습니다. 정말 난감한 문제는

자신이 두개의 라이브러리(Library, *.lib)를 사용해야 하는데 각 라이브러리에 동일한 이름을 가진 함수가 있을때도 LNK2005 오류가

발생한다는 것입니다. 자신이 만든 라이브러리라면 소스를 수정해서 다시 라이브러리를 만들면 되겠지만 소스가 없는 없다면

Visual C++ 의 링크 옵션을 조절해서 해결을 해야합니다.

이런 경우는 상황에 따라서 대처하는 방법이 다르기 때문에 해결책을 직접적으로 알려드리기는 어려울듯합니다. 그래서

관련해서 예시가 있으니 아래에 링크해드린 자료를 한번 읽어보시기 바랍니다.

http://support.microsoft.com/kb/148652/ko

저는 www.tipssoft.com 사이트의 관리자이며 위 자료는 해당 사이트에도 동일하게 게시되어 있음을 알려드립니다.
www.tipssoft.com 사이트는 프로그래머들의 정보공유를 위해 제가 운영하고 있는 사이트 입니다.

이 게시물과 동일한 자료의 www. tipssoft.com 게시물 URI 는 다음과 같습니다.
( http://www.tipssoft.com/bulletin/tb.php/FAQ/1156 )

[출처] C2086, C2084, LNK2005 오류에 대하여|작성자 희망가

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

정적코드분석(static code analysis)을 통한 버그 탐지 (0)	2016.10.27
윈도우 심볼 다운로드 (0)	2013.06.15
WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
병렬 스택 창 사용 (0)	2012.12.27
비주얼스튜디오 : 스레드디버깅 (2) : 다중 스레드 응용 프로그램 디버깅 (0)	2012.12.27

http://www.slideshare.net/hebory/11-0730-gpg-2111

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
Visual Studio 2010을 사용한 코딩 개선 (0)	2012.12.27
심볼 스토어 생성 (0)	2012.12.23
Debug Diagnostic Tool (0)	2012.12.23

http://process3.blog.me/20065867268

최근에 덤프를 하나 분석하고 있는데 동기화 관련해서 이슈가 발생한것 같습니다. criticalsection 관련 WinDbg 명령하나를 정리합니다. 필요하신 분들 참고하세요~

1) 문제가 있는 CriticalSection 오브젝트가 있는지 확인한다.

0:019> !locks -o
Looking for orphaned critical sections

CritSec at 100a4824 could not be read
Perhaps the critical section was a global variable in a dll that was unloaded?

CritSec at 100a4648 could not be read
Perhaps the critical section was a global variable in a dll that was unloaded?

CritSec at 100a47e0 could not be read
Perhaps the critical section was a global variable in a dll that was unloaded?

CritSec at 100a4660 could not be read
Perhaps the critical section was a global variable in a dll that was unloaded?

Scanned 650 critical sections

총 650개 critical sections 중에 약 4개가 문제가 있는것 같습니다.

2)!cs 명령을 통해서 좀 더 자세하게 확인해 보겠습니다.

0:019> !cs -l
-----------------------------------------
DebugInfo          = 0x00154990
Critical section   = 0x008f211c (+0x8F211C)
LOCKED
LockCount          = 0x0
OwningThread       = 0x000001c0
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000
-----------------------------------------
DebugInfo          = 0x001497a0
Critical section   = 0x008f335c (+0x8F335C)
LOCKED
LockCount          = 0x0
OwningThread       = 0x00000204
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000
-----------------------------------------
DebugInfo          = 0x00149840
Critical section   = 0x008f304c (+0x8F304C)
LOCKED
LockCount          = 0x0
OwningThread       = 0x00000208
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000
Cannot read structure field value at 0x100a4828, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section   = 0x100a4824 (+0x100A4824)
DebugInfo          = 0x0015a198
Cannot read structure field value at 0x100a464c, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section   = 0x100a4648 (+0x100A4648)
DebugInfo          = 0x0015a2d0
Cannot read structure field value at 0x100a47e4, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section   = 0x100a47e0 (+0x100A47E0)
DebugInfo          = 0x0015a2f8
Cannot read structure field value at 0x100a4664, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section   = 0x100a4660 (+0x100A4660)
DebugInfo          = 0x0015a320
-----------------------------------------
DebugInfo          = 0x001676d8
Critical section   = 0x009609ac (+0x9609AC)
LOCKED
LockCount          = 0x0
OwningThread       = 0x0000064c
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000
-----------------------------------------
DebugInfo          = 0x001771e8
Critical section   = 0x00978664 (+0x978664)
LOCKED
LockCount          = 0x0
OwningThread       = 0x000001c0
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000
-----------------------------------------
DebugInfo          = 0x001478b0
Critical section   = 0x00978684 (+0x978684)
LOCKED
LockCount          = 0x0
OwningThread       = 0x000001c0
RecursionCount     = 0x1
LockSemaphore      = 0x0
SpinCount          = 0x00000000

...

이 프로그램이 생각보다 많은 Critical Section 오브젝트를 사용하고 LOCKED 되어 있는것도 많습니다.

또한 Looking for orphaned critical sections(소유자가 없는 Critical Section 오브젝트)도 4개나 있습니다.

3) 소유주가 없는 Critical Section 오브젝트를 좀 더 조사해 봅시다.

0:019> !cs -o 0x100a4648
Cannot read DebugInfo adddress at 0x100a4648. Possible causes:
- The critical section is not initialized, deleted or corrupted
- The critical section was a global variable in a DLL that was unloaded
- The memory is paged out
Cannot read structure field value at 0x100a464c, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section = 0x100a4648 (+0x100A4648)
DebugInfo = 0x00000137

아래 3가지 경우중에 하나이면 소유주가 없는 Critical Section 오브젝트가 생겨서 크래쉬가 발생하고 문제 해결이 정말 어려워지는 버그가 발생합니다.

- 초기화 되지 않았거나 지워졌거나 오염된 경우(The critical section is not initialized, deleted or corrupted)
- DLL에서 전역변수로 Critical Section 오브젝트가 선언되었는데 DLL이 언로드된 경우 (The critical section was a global variable in a DLL that was unloaded)
- 메모리가 페이지 아웃된 경우 (The memory is paged out)

[Critical section 에서 문제가 발생할 수 있는 상황 정리]

1. InitializeCriticalSection(...) 함수를 호출 하지 않았다.
2. 여러번 InitializeCriticalSection(...) 호출되었고 DeleteCriticalSection(...)이 한번도 호출되지 않은 상황에서 다시 초기화된 경우
3. DeleteCriticalSection(...) 호출되었다 그러나 Critical section 오브젝트가 계속해서 참조되고 사용된다.
4. 스레드에서 EnterCriticalSection(...) 호출되고 사용된다. 그러나 LeaveCriticalSection(...).함수를 호출하지 않았다. 그리고 다른 스레드에서 EnterCriticalSection(...).함수를 호출해서 사용한다.

즉, 메모리에 선언되지 않았거나 메모리에서 지워진 Critical section 오브젝트를 사용하면 큰일 난다

1)초기화 하지 않은 Critical section 오브젝트

// Not initilize the Critical section.
// Global variable
CRITICAL_SECTION CriticalSection;
int _tmain(int argc, _TCHAR* argv[])
{
    //InitializeCriticalSection(&CriticalSection);
    EnterCriticalSection(&CriticalSection);

    LeaveCriticalSection(&CriticalSection);

DeleteCriticalSection(&CriticalSection);
return 0;
}

2)삭제된 Critical section 오브젝트 참조하기
// Global variable
CRITICAL_SECTION CriticalSection;
DWORD WINAPI ThreadProc( LPVOID lpParameter )
{
//InitializeCriticalSection(&CriticalSection);
    // Request ownership of the critical section.
    EnterCriticalSection(&CriticalSection);
    // Release ownership of the critical section.
    LeaveCriticalSection(&CriticalSection);
DeleteCriticalSection(&CriticalSection);
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
    // Initialize the critical section one time only.
    InitializeCriticalSection(&CriticalSection);
CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);

Sleep(3000);
EnterCriticalSection(&CriticalSection);
LeaveCriticalSection(&CriticalSection);
DeleteCriticalSection(&CriticalSection);
return 0;
}

출처 : 다년간의 프로그램밍 삽질(경험)->요즈음 나를 괴롭히는 버그... ㅠㅠ 그리고 구글 검색으로부터...

[출처] WinDbg를 이용해서 Critical Section 추적해 보기.|작성자 갱주니

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

윈도우 심볼 다운로드 (0)	2013.06.15
C2086, C2084, LNK2005 오류에 대하여 (0)	2013.02.27
병렬 스택 창 사용 (0)	2012.12.27
비주얼스튜디오 : 스레드디버깅 (2) : 다중 스레드 응용 프로그램 디버깅 (0)	2012.12.27
비주얼스튜디오 : 스레드 디버깅(1) (0)	2012.12.27

http://msdn.microsoft.com/ko-kr/magazine/ee336135.aspx

Visual Studio 2010을 사용한 코딩 개선

Doug Turnure

Microsoft가 오랜 전통의 기함급 통합 개발 환경인 Visual Studio를 처음 발표한지도 13년이 지났습니다. 1997년 첫 Visual Studio 릴리스부터 Visual Basic과 Visual C++ 버전 5는 하나의 공통된 IDE에 속하게 되었습니다. 여기에는 또한 Visual InterDev, Microsoft Transaction Server, Visual SourceSafe 5.0 등 한때 이름을 떨쳤던 기술이 적용된 Enterprise Edition이 포함되었습니다. 이 릴리스의 핵심적인 목표는 개발자가 구성 요소를 사용하여 분산 응용 프로그램(클라이언트/서버 응용 프로그램과 웹 응용 프로그램 모두)을 구축할 수 있게끔 돕는 것이었습니다.

그 후 우리 개발자들은 많은 변화를 겪었습니다. 클라이언트/서버와 웹 아키텍처의 변형이 여전히 코딩 분야를 지배하고 있지만 응용 프로그램의 범위와 요구 사항은 동종 시스템과 강력한 형식의 개체 대 개체 호출이라는 영역을 넘어 확장되었습니다.

이제 REST(Representational State Transfer) 및 그 관련 기술이 주요 기본 통신 메커니즘으로 자리잡습니다. 응용 프로그램은 클라우드 기반 아키텍처로 돌아서며 확장성, 신뢰성, 그리고 데이터 보안을 타사의 손에 맡깁니다. 웹 응용 프로그램 패턴은 범용화된 스타일과 표준에 따릅니다. 프로세서 속도가 현재의 칩 기술에서 이론적 한계에 가까워지고 다중 코어 시스템을 통해 하나의 시스템으로 더 높은 성능을 뽑아내는 새로운 방법이 등장하면서 하드웨어도 변화합니다.

소프트웨어와 소프트웨어 개발자의 요구 사항이 전례 없는 수준으로 높아진 이 환경에 Visual Studio 2010이 출시됩니다. 또한 새로운 기능으로 무장한 Visual Studio 2010은 여러 플랫폼, 코어, 스타일 및 표준에 걸쳐 확장되는 환경에서 점점 더 높아지는 소프트웨어 요구 사항을 충족할 준비가 되어 있습니다. 이 기사에서는 개발자가 현재와 같은 복잡한 업계에서 성공적인 솔루션을 구축할 수 있도록 지원해야 한다는 과제를 Visual Studio 2010이 해결하는 과정을 알아봅니다. 여기서 새로운 기능을 모두 다루지는 않습니다. 이 기사의 목표는 개발자가 일상적인 작업에 즉시 사용할 수 있는 몇 가지 특정 기능을 조명하는 것입니다. 전체 기능 목록은 제품 설명서를 통해 언제든 확인할 수 있습니다.

Visual Studio IDE 개선

소프트웨어 개발에서 다루는 시나리오가 점점 더 복잡해지면서 개발자들은 생산성 향상에 대한 압박을 느끼는 경우가 많습니다. Visual Studio 2010은 생산성에 도움이 되도록 편집기 자체에 여러 새로운 시각적 기능을 추가했습니다. 이 섹션에서는 시각적 기능 중 세 가지를 살펴보겠습니다.

Visual Studio 2010 IDE에서 비교적 간단하게 확인할 수 있는 개선 사항은 자식 창을 IDE 부모 창 외부로 끌어내는 기능입니다. 모니터 값이 저렴해진 덕분에 개발자는 작업에 두 개 이상의 모니터를 사용하곤 하는데, 이 새로운 기능을 통해 코딩 및 디자인 창을 여러 화면에 걸쳐 확장할 수 있습니다.

사용 방법 창의 탭을 클릭한 다음 Visual Studio IDE 창 밖으로 끌어내면 됩니다. 창을 다시 도킹하려면 제목 표시줄을 클릭하고 IDE 영역 안으로 끌어와서 제목 표시줄을 다른 창의 탭과 나란히 두기만 하면 됩니다. 다시 도킹할 때 창이 올바르게 정렬되는 지점이 되면 창이 어둡게 변하는데, 이 상태에서 놓으면 다시 도킹됩니다. 그림 1은 IDE의 부모 창 밖으로 빼낸 코드 창을 보여 줍니다.

그림 1 IDE에서 창 끌어내기

Visual Studio 2010 편집기의 또 다른 유용한 새 기능은 세로 텍스트 블록을 묶음으로 선택해서 편집할 수 있는 기능입니다. 긴 항목 목록을 편집하다 보면 똑같은 키보드 입력을 빠르게, 반복적으로 하곤 합니다(예: "n+아래쪽 방향키+왼쪽 방향키"를 지루하게 반복). 가장 자주 발생하는 문제라고 하긴 어렵지만 종종 일어나곤 하며, 그럴 때 많은 개발자는 세로 블록 전체를 선택한 다음 똑같은 변경 작업을 모든 줄에 한 번에 적용하는 기능이 있으면 좋겠다는 생각을 합니다. Visual Studio 2010은 이러한 블록 편집 기능을 제공합니다.

사용 방법 Alt 키를 누른 채로 편집할 세로 항목을 선택합니다. 강조 표시된 영역은 한 줄을 편집할 때와 똑같이 작동하지만 편집 내용은 그림 2에서 볼 수 있듯이 선택한 모든 줄에 동시에 복제됩니다.

그림 2 묶음 선택

코드의 참조를 위한 유용한 강조 표시 기능도 있습니다. 편집기에서 변수, 개체, 메서드, 속성, 형식 또는 기타 기호를 클릭하면 해당 기호에 대한 코드의 모든 참조가 강조 표시되므로 이 항목이 사용되는 위치를 신속하게 찾을 수 있습니다.

사용 방법 형식/변수/메서드 등을 클릭하면 다른 인스턴스가 강조 표시됩니다. 그림 3은 jumpList라는 변수에 대해 이 기능이 적용된 모습입니다. 마우스로 클릭하자 코드에서 이 변수가 사용된 지점에 모두 회색 음영이 표시된 것을 볼 수 있습니다..

그림 3 강조 표시된 기호

병렬 프로그래밍 지원

새로운 IDE 기능으로 조금 더 깊이 들어가서, 이번에 다룰 중요한 새 기능은 병렬 프로그래밍에 대한 지원입니다. Visual Studio 2010에는 병렬 응용 프로그램의 디버깅과 분석에 유용한 진단 도구가 함께 제공됩니다. 그러나 도구에 들어가기 전에 병렬 프로그래밍이 무엇인지에 대해 간단히 살펴보고, 그 다음 런타임 및 라이브러리가 이 새 기능을 어떻게 구현하는지 보도록 하겠습니다.

요즘은 표준 개발자 시스템이 두 개 이상의 프로세서를 탑재한 다중 코어 시스템인 경우가 많고, 추세도 더 많은 코어를 탑재한 시스템으로 흐르고 있습니다. 다중 코어 시스템 추세에 영향을 미치는 요인으로는 순수한 기술 혁신 외에 전원 절약이나 클록 속도의 현실적인 제약, 전력 소모 및 발열 등도 있습니다. 업계 유력 인사들 일부는 앞으로 몇 년 내에 주류 시스템에 50개 이상의 코어가 탑재될 것으로 예상합니다.

여기에 문제가 있습니다. 다중 코어 혁명이 일어나기 전에는 더 빠른 시스템이 곧 더 빠른 응용 프로그램 실행 속도를 의미했습니다. 그러나 단일 코어에 묶이는 소프트웨어(현재 대부분의 소프트웨어)는 이 새로운 아키텍처를 활용할 수 없습니다. 따라서 앞으로는 다중 코어 아키텍처를 대상으로 하는 것이 중요합니다. Visual Studio 2010과 .NET Framework 4가 나오기 전에는 두 개 이상의 코어를 활용하는 코드를 작성하기가 어려웠습니다. 이 과제를 해결하기 위해 이번 릴리스에는 개발자가 다중 코어 시스템을 이용하는 데 도움이 되도록 런타임에 대한 몇 가지 업데이트와 새로운 형식, 라이브러리 및 도구가 포함되었습니다.

.NET Framework 4에는 병렬 확장이 포함되며, 병렬 확장은 새로운 TPL(Task Parallel 라이브러리), 새로운 PLILQ 실행 엔진, 그리고 몇몇 새로운 CDS(Coordination Data Structure)로 구성됩니다. TPL에는 두 가지 기본 클래스가 포함됩니다. 이 클래스 중 하나인 System.Threading.Tasks.Parallel에는 For 및 ForEach 메서드의 병렬 버전과 같은 병렬 구문이 포함됩니다. PLINQ 실행 엔진은 이름이 암시하듯 LINQ to Objects의 병렬 버전으로, LINQ의 Enumerable 클래스 대신 ParallelEnumerable 클래스를 제공합니다. PLINQ 사용 방법은 LINQ to Objects 사용 방법과 비슷하지만 똑같지는 않습니다. 마지막으로 CDS에는 스레드로부터 안전한 컬렉션 및 동기화 기본형 그룹이 포함되는데, 이들의 역할은 병렬 시나리오를 간소화하는 것입니다. CDS에는 스레드로부터 안전한 컬렉션에 있음직한 익숙한 요소들(예: ConcurrentDictionary, ConcurrentQueue 및 ConcurrentStack)과 동기화 형식(SemaphoreSlim, SpinLock, SpinWait 등)이 포함됩니다.

Visual Studio 2010은 새로운 병렬 스택 창, 병렬 작업 창 및 동시성 시각화 도우미를 통해 병렬 확장을 지원합니다. 이러한 창은 모두 특정 실행 시점에 다양한 작업의 위치를 파악하는 데 유용하도록 고안되었습니다. 병렬 스택 창에는 여러 작업들이 전용 경로를 통해 어떻게 진행되고 있는지와 이러한 작업에 대한 호출 스택이 표시됩니다. 작업 추상화 관점에서 보거나 스레드로 직접 보도록 선택할 수 있습니다. 그림 4는 작업 추상화 뷰 옵션이 표시된 런타임의 병렬 스택 창을 보여 줍니다.

그림 4 Visual Studio 2010의 병렬 스택 창

병렬 작업 창은 새로운 작업 기반 프로그래밍 모델을 지원하기 위한 용도로 추가되었습니다. 응용 프로그램이 중단 모드에 있는 경우 이 창을 사용하여 작업 목록, 각 작업에 대해 현재 실행 중인 메서드, 계열 스레드, 응용 프로그램 도메인, 작업 ID와 같은 항목을 볼 수 있습니다. 이 창은 단순한 정적 뷰 이상의 기능을 제공합니다. 특정 작업을 클릭하면 IDE에서 현재 실행 중인 코드를 전면으로 가져와 이 작업의 상태를 보여 줍니다. 그림 5는 샘플 응용 프로그램에 대한 이 창을 보여 줍니다. 이 창을 병렬 스택 창과 함께 사용하면 실행 중인 코드를 신속하게 살펴볼 수 있습니다.

그림 5 Visual Studio 2010의 병렬 작업 창

마지막으로, Visual Studio 2010에는 병렬 응용 프로그램 분석을 심화하기 위한 새로운 동시성 시각화 도우미가 있습니다. 이 창은 다른 두 창에 비해 훨씬 더 복잡하며 현재 웹 프로젝트는 지원하지 않습니다. 이 창의 목적은 다중 코어 또는 다중 스레드 시나리오에서 응용 프로그램과 환경 간의 상호 작용에 대한 시야를 제공하는 것입니다. 여기에는 세 가지 뷰가 있습니다.

CPU 사용률 뷰에는 프로세서 활동이 표시됩니다.
스레드 뷰에는 응용 프로그램 스레드의 상호 작용이 표시됩니다.
코어 뷰는 스레드가 코어 사이를 어떻게 이동하는지에 대한 시야를 제공합니다.

동시성 시각화 도우미는 Windows용 이벤트 추적에 의존하므로 Windows Vista 이상에서 실행되어야 합니다. 기본적인 텍스트에서 전체적인 그래픽 표현까지 다양한 모습의 이러한 뷰는 고르지 못한 CPU 부하 분산, 실행 병목 지점, 경합 및 기타 잠재적인 성능 저하 요인에 의해 발생하는 코드의 비효율성을 찾아 줍니다. 그림 6은 프로파일링된 응용 프로그램에 대한 스레드 사용량이 표시된 동시성 시각화 도우미를 보여 줍니다.

그림 6 Visual Studio 2010의 동시성 시각화 도우미

웹 업데이트

여기서 설명한 전반적인 업데이트 외에 Visual Studio 2010으로 전환하는 웹 개발자를 위한 몇 가지 중요한 개선 사항도 있습니다. 물론 새로운 MVC(Model-View-Controller) 프로그래밍 모델 도구도 포함되며, 이에 대해서는 다음 섹션에서 다루겠습니다. 또한 클라이언트 및 서버측 웹 기술을 위한 웹 개발 환경도 개선되었으며 새로운 원클릭 웹 배포 모델도 있습니다. 일단 ASP.NET AJAX 및 이와 관련된 IDE의 새로운 기능부터 살펴보겠습니다.

ASP.NET AJAX 도구는 Visual Studio 2008부터 Visual Studio에 포함되었습니다. 그러나 서버 위주의 템플릿으로 인해 일부 개발자는 클라이언트측 개발에는 이 도구의 가치가 크지 않다고 생각하게 되었습니다. 이전부터 클라이언트측 기능도 항상 포함되었지만 Visual Studio 2010에는 ASP.NET AJAX의 클라이언트와 서버측 기능 모두 제대로 활용되도록 추가 지원이 포함되어 있습니다. 클라이언트측 템플릿과 컨트롤은 개선된 클라이언트 데이터 액세스 기능을 활용하는 데 유용하므로 새로운 기능 목록에서 중요한 부분입니다. 그러나 jQuery 통합과 같은 다른 많은 새로운 항목도 살펴볼 가치가 있습니다.

Visual Studio 2010과 .NET Framework 4가 나오기 전에는 소프트웨어 다운로드를 사용하고 Microsoft AJAX Library를 Visual Studio에 통합하는 경우 ScriptManager를 추가할 때 모든 요소가 페이지에 삽입되었습니다. 이번 릴리스에서는 Microsoft AJAX Library와 AJAX Control Toolkit가 결합되었습니다. 또한 Microsoft AJAX 팀이 라이브러리를 리팩터링한 덕분에 전체를 선택하거나 아무것도 선택하지 않는 단순한 두 가지 옵션에서 벗어나 원하는 개별 부분을 요청할 수 있게 되었습니다. 모드를 지정하여 Microsoft AJAX Library 전체를 요청하거나 아무것도 요청하지 않거나 특정 부분만 요청할 수 있습니다.

사용 방법 ScriptManager 태그에 AjaxFrameworkMode 특성만 포함하면 됩니다. 다음과 같이 Disabled, Enabled 또는 Explicit으로 설정할 수 있습니다.

<asp:ScriptManager ... AjaxFrameworkMode="Disabled"/>

Disabled는 Microsoft AJAX 프레임워크를 로드하지 않음을 의미합니다. Enabled는 이전 버전의 동작(전체 라이브러리 로드)을 수행함을 의미합니다. Explicit을 사용하면 로드할 Microsoft AJAX Library 파일을 지정할 수 있습니다. 런타임에 로드된 페이지에서 소스 보기를 사용하여 이를 확인할 수 있습니다.

비슷한 방법으로, 새로운 CDN(콘텐츠 배달 네트워크) 특성은 최신 버전의 스크립트 라이브러리를 사용할 수 있도록 합니다. 이전에는 프로젝트에 jQuery 또는 Microsoft AJAX와 같은 스크립트 라이브러리를 포함하는 경우 해당 릴리스에서는 이 포함한 버전으로만 고정되었습니다. 이제는 솔루션에 고정된 버전을 넣지 않고 웹에서 최신 버전을 다운로드하도록 요청할 수 있습니다.

사용 방법 asp:ScriptManager 태그에 EnableCdn 특성을 포함하고 “true”로 설정하면 됩니다.

<asp:ScriptManager ... EnableCdn="true"/>

ASP.NET AJAX 4.0에서는 순수 클라이언트측 템플릿도 정의할 수 있습니다. 자리 표시자 <ItemTemplate>을 설정한 다음 런타임 값(예: JSON에 바인딩된 개체)에 따라 클라이언트에서 렌더링하도록 두면 됩니다. 런타임이 사용자 대신 인스턴스화를 수행하므로 이를 위한 DOM 코딩이 필요 없습니다.

ASP.NET AJAX 4.0의 가장 유용한 추가 기능 중 하나는 새로운 DataView 컨트롤과 클라이언트 템플릿을 사용하여 클라이언트에 손쉬운 액세스와 2방향 데이터 바인딩을 제공하는 개선된 클라이언트 데이터 액세스입니다. 이 기능은 ASMX 웹 서비스, WCF 서비스, WCF 데이터 서비스, MVC 컨트롤러, 또는 JSON을 반환하는 모든 것을 사용하도록 설계되었으며, 이러한 작업을 온전히 클라이언트측 코드에서 수행합니다.

DataView 컨트롤은 클라이언트 템플릿 지원을 위한 기본 컨트롤입니다. 이 컨트롤은 ListView 컨트롤과 비슷하게 작동하지만 순수하게 클라이언트측에서 구현됩니다. 이 컨트롤을 통해 클라이언트에서 템플릿을 정의하고 런타임에 데이터를 가져온 다음 레코드를 표시할 때 서식을 적용할 수 있습니다.

사용 방법 준비 작업은 다음과 같이 매우 기본적인 단계로 이루어집니다. Northwind SQL 데이터베이스에 엔터티 데이터 모델을 만들고, 이것을 아무 변경 없이 그대로 가져오는 일반적인 WCF 데이터 서비스를 사용합니다. 이는 Employees 테이블을 쿼리에 사용할 수 있음을 의미합니다. 이렇게 했으면 템플릿으로 사용할 컨트롤을 선택한 다음 여기에 ID 특성과 class=“sys-template” 특성을 지정합니다. 데이터 뷰를 만들 때 이 ID가 바인드에서 가져온 데이터의 대상을 나타내는 데 사용됩니다. 수동으로 바인딩할 수 있지만 중괄호를 사용하여 태그에 필드 이름을 직접 포함하는 구문도 있으며, 이는 데이터를 가져와 바인딩할 때 대체됩니다. 이 작업을 수행하는 구문은 여러 개 있지만 이를 실행하기 위한 스크립트 및 태그를 읽기 좋게 작성하는 방법 중 하나는 그림 7과 같이 이중 중괄호를 사용하는 것입니다.

그림 7 DataView 컨트롤로 개선된 데이터 액세스

...
   <script type="text/javascript">
    Sys.require([Sys.components.dataView, 
                 Sys.components.adoNetServiceProxy], function () {
            
       var adoNetDataServiceProxy = 
         new Sys.Data.AdoNetServiceProxy('NWDataService.svc');
         
       Sys.create.dataView("#employeetemplate", {
         dataProvider: adoNetDataServiceProxy,
         fetchOperation: "Employees",
         autoFetch: true
            });
       });
    </script>
</head>
<body>
  <div id="employeetemplate" class="sys-template">
      <span>{{ FirstName }}</span><br/> 
  </div>
</body>

ASP.NET AJAX에서 또 다른 주목할 만한 점은 jQuery와 훨씬 더 밀접하게 통합되도록 설정되었다는 것입니다. jQuery 개발자가 ASP.NET AJAX의 컨트롤을 이용할 수 있도록 하기 위해 이제 모든 AJAX Control Toolkit 컨트롤은 자동으로 jQuery 플러그 인으로 노출됩니다. 이는 jQuery 개발자가 개발 스타일을 변경하지 않고도 컨트롤을 사용할 수 있음을 의미합니다. 쉽게 생각해서 jQuery에 대한 확장으로 보면 됩니다.

ASP.NET AJAX 영역 외에도 ASP.NET 프로그래밍 환경의 여러 부분이 향상되었습니다. Web Forms의 URL 라우팅은 URL에 깔끔하고 논리적인 느낌을 부여하여 SEO(검색 엔진 최적화)에 훨씬 더 유리하고 사람이 읽기에도 더 편하도록 합니다. 요청을 적절한 리소스에 매핑하는 global.asax 파일에 경로를 정의할 수 있습니다. 이는 SEO를 개선하는 데도 도움이 되지만 그림 8에서 볼 수 있듯이 페이지 경로가 예측 가능한 형태를 취할 수 있게 됩니다.

그림 8 Visual Studio 2010의 URL 라우팅 개선

New URL Routing Format:
	/CurrentPosition/Bob/Tester

Old URL Style:
	/CurrentPositions.aspx?name="Bob"&role="Tester"

시작 웹 사이트, 더 깔끔한 HTML 및 작아진 구성 파일 등 웹과 관련된 향상된 부분이 더 많이 있지만 여기서 모두 다 설명할 수는 없으므로 이제 MVC 도구 추가로 넘어가겠습니다.

MVC 통합

MVC 아키텍처 패턴은 잘 정의된 경계와 명확한 기능별 코드 분류를 통해 유지 관리와 테스트에 용이한 웹 응용 프로그램을 구축하는 데 널리 사용되는 방법입니다. MVC는 ASP.NET 프레임워크를 십분 활용하는 ASP.NET 프로그래밍 스타일입니다. Web Forms 대신 사용할 수 있지만 이를 대체하지는 않습니다. 두 가지 모델은 특정 시나리오와 기술 집합에 따라 모두 매우 뛰어난 기능을 제공합니다. 개발자는 이제 모두 ASP.NET을 기반으로 하고 Visual Studio 2010에서 완전히 지원되는 웹 응용 프로그램의 프로그래밍 모델을 선택할 수 있습니다.

MVC 버전 2 및 계열 도구들(각 Visual Studio 릴리스 사이에 제작되는 도구)은 그림 9에서 볼 수 있듯이 두 가지 프로젝트 템플릿과 함께 Visual Studio 2010 IDE에 통합되었습니다.

그림 9 Visual Studio 2010의 MVC 프로젝트 템플릿

Visual Studio 2010 릴리스에서 MVC 프로그래밍 모델은 세 가지 개선 영역에 집중했습니다. 첫 번째는 더 향상된 영역 분리입니다. 이는 비즈니스 논리 분리를 위한 새로운 RenderAction 메서드, 응용 프로그램의 기능을 분할하기 위한 "하위 응용 프로그램"을 만드는 데 사용되는 Areas 등을 통해 코드의 유지 관리가 더 향상된다는 것을 의미합니다. 두 번째 개선 영역은 유효성 검사로, 클라이언트에 대한 개선된 유효성 검사 규칙 수립과 데이터 주석을 통해 더 쉬워졌습니다. 마지막으로 도우미의 개선입니다. 이제 템플릿 기반 도우미와 강력한 형식의 도우미가 있으므로 엔터티에 대한 UI를 자동으로 생성할 수 있습니다.

사용 방법 RenderAction을 사용하면 여러 컨트롤러에 걸쳐 논리의 한 부분을 더 쉽게 공유할 수 있습니다. 뷰 내에서 RenderAction 메서드를 호출하려면 다음 스크립트를 사용하십시오(HRController 내에서 NewEmployee 작업을 호출함).

<%  Html.RenderAction("NewEmployee" "HRController"); %>

SharePoint 통합

Visual Studio 2010의 또 다른 중요한 도구 통합은 SharePoint Foundation(이전의 Windows SharePoint Services)을 위한 템플릿 추가입니다. Visual Studio 2010에는 SharePoint Foundation을 위한 12개의 새로운 템플릿과, Visual Studio 2008의 Visual Studio Tools for Office 추가 기능에 있는 SharePoint 2007 순차 및 상태 시스템 워크플로 템플릿이 포함됩니다. 이러한 템플릿은 생산성 및 유연한 배포를 중심으로 SharePoint 개발 수준을 최상급으로 승격시켜 줍니다.

SharePoint Foundation 자체는 사용자 관리, 기본 목록 인프라 및 사이트 모델과 같은 구성 요소를 통해 기존의 확장을 위한 단순한 포털에서 이제는 처음부터 응용 프로그램을 구축하기 위한 플랫폼으로 주 사용처가 변화되고 있습니다. 이러한 부분들은 데이터 액세스, LOB(기간 업무) 통합 및 워크플로 측면에서 중요한 진전입니다. 또한 더 유연해진 배포 모델도 있습니다. 현재 많은 기업들은 방대한 SharePoint 설치 기반을 보유하고 있으며, 따라서 새로운 SharePoint 응용 프로그램의 애드혹 배포에 대해 더 신중을 기할 수밖에 없습니다. 새로운 유연한 배포 모델을 통해 이제 새 설치 시 전체 SharePoint 환경에 배포할 필요 없이 특정 그룹에 국한시킬 수 있습니다.

Visual Studio 2010에서는 SharePoint 응용 프로그램 구축을 위한 도구 옵션이 대폭 개선되었습니다. 사실 이를 위한 강력한 기능은 이전에도 있었지만 처음 배우기가 상당히 어려웠습니다. 이번 릴리스에서는 SharePoint 지원이 도구에 직접 포함되어 매우 편리합니다. 여기에는 BCS(비즈니스 연결 서비스), 워크플로, 개선된 설계 지원, LINQ to SharePoint 및 시각적 웹 파트에 대한 개선된 설계 지원과 유연한 통합 디버깅 배포 도구가 포함됩니다. 또한 SharePoint Designer 도구에서 Visual Studio 2010으로 항목을 가져오기 위한 브리지도 향상되었습니다.

사용 방법 Visual Studio 2010에서는 새로운 디자인 화면을 통해 시각적 웹 파트를 만들기가 훨씬 더 쉬워졌습니다. 그림 10과 같이 새 프로젝트를 시작하고 SharePoint | 시각적 웹 파트를 선택하면 됩니다.

그림 10 Visual Studio 2010의 SharePoint 시각적 웹 파트 템플릿

이 기능을 위해서는 개발자 시스템에 SharePoint가 설치되어 있어야 하지만 그 과정이 예전만큼 어렵지는 않습니다. Windows Vista SP1 이상 또는 Windows 7을 사용하는 경우 시스템에 직접 SharePoint를 설치하면 되므로 Windows Server를 설치하거나 VM을 설정하는 일에 대해 걱정할 필요가 없습니다.

Visual Studio 2010에서 디버깅을 위한 솔루션을 설치할 위치를 지정하라는 메시지가 표시됩니다. 편집기가 열려 있는 경우 왼쪽 하단의 디자인 탭을 클릭하고 컨트롤을 화면으로 끌어서 놓는 간편한 방법으로 시각적으로 웹 파트를 만들 수 있습니다. 도구 상자가 보이지 않는다면 보기 메뉴 | 도구 상자를 통해 열어야 합니다.

Windows 7 개발

Windows 7의 인기가 높아지고 있으므로 개발자는 새로운 Windows 7 플랫폼에서 제공되는 풍부한 환경을 이용하도록 응용 프로그램에 기능을 추가하기를 원할 수 있습니다. Windows 7 관련 기능을 추가하는 방법은 다양합니다. 인기 있는 새로운 기능 중 하나는 새로운 작업 표시줄입니다. 사용자들의 빠른 도입과 프로그래밍의 용이함을 감안할 때 Windows 7을 대상으로 하는 응용 프로그램에서 이 기능을 사용하는 것은 좋은 생각입니다.

작업 표시줄은 이전 Windows 버전의 빠른 실행 작업 표시줄을 대체합니다. 작업 표시줄은 기본적으로 Windows 7 화면의 하단을 따라 펼쳐져 있으며, 응용 프로그램을 여기에 "꽂아" 놓을 수 있습니다. 또한 이를 통해 응용 프로그램에 점프 목록(도킹된 아이콘을 마우스 오른쪽 단추로 클릭하여 이용할 수 있는 빠른 링크 모음), 작업 표시줄 미리 보기(응용 프로그램이 열린 창을 작게 축소해서 표시)와 같은 요소를 적용할 수 있습니다. 작업 표시줄은 관리 코드(Windows 7 API Code Pack 사용)와 비관리 코드에서 모두 프로그래밍하기 쉽고, Windows 7에서 실행되는 응용 프로그램 구축의 이점을 활용하고자 하는 개발자가 가장 관심을 가져야 할 부분입니다.

사용 방법 사용자는 시작 메뉴, 탐색기 또는 작업 표시줄 자체에서 아이콘을 마우스 오른쪽 단추로 클릭하는 방법으로 간단히 응용 프로그램을 작업 표시줄에 고정하거나 작업 표시줄에서 제거할 수 있습니다. 응용 프로그램을 고정하려면 응용 프로그램(문서가 아니라 응용 프로그램 자체) 아이콘을 마우스 오른쪽 단추로 클릭하고 "작업 표시줄에 고정"을 선택합니다. 작업 표시줄에서 제거하려면 같은 과정 후 "이 프로그램을 작업 표시줄에서 제거"를 선택합니다.

작업 표시줄은 응용 프로그램의 시각적 측면과 기능적 측면을 모두 개선시켜 줍니다. 실행 중인지 여부와 관계없이 모든 프로그램을 작업 표시줄에 고정할 수 있습니다. 고정된 아이콘은 응용 프로그램을 시작하거나 최소화된 창을 나타낼 수 있습니다. 작업 표시줄의 아이콘 위로 커서를 이동하면 응용 프로그램이 실행 중인 경우 핫 트래킹이라고 하는 멋진 시각 효과가 나타납니다. 핫 트래킹은 두드러지는 아이콘 색으로 아이콘을 강조 표시합니다. 물론 고정된 아이콘 바로 위에 실행 중인 응용 프로그램 인스턴스의 미리 보기도 표시됩니다.

작업 표시줄에는 Aero Peek라는 기능도 있습니다. 이 기능을 보려면 커서를 창 미리 보기 위로 이동합니다. 그러면 선택한 미리 보기의 창이 전면으로 나와 표시되며 다른 창들은 어둡게 표시됩니다. 이는 사용자가 포커스를 변경하거나 키를 누를 필요 없이 숨겨진 최소화된 창을 간단히 살펴보는 데 유용한 기능입니다.

응용 프로그램 추적을 위해 실행 중인 응용 프로그램 인스턴스에는 응용 프로그램 ID가 지정되며 작업 표시줄의 해당 응용 프로그램 아이콘에 따라 인스턴스가 정렬됩니다. 개발자는 TaskbarManager 및 JumpList 클래스를 사용하여 응용 프로그램에서 프로그래밍 방식으로 작업 표시줄과 상호 작용할 수 있습니다. 이러한 클래스를 사용하려면 code.msdn.microsoft.com/WindowsAPICodePack의 무료 Windows 7 API Code Pack을 다운로드하여 어셈블리를 참조해야 합니다.

Windows SDK 팀에서 제작한 이 코드 팩을 통해 작업 표시줄을 프로그래밍 방식으로 사용할 수 있습니다. 또한 이 코드 팩에는 Windows 7의 향상된 기능이 적용된 여러 샘플 응용 프로그램이 포함되어 있습니다. 코드 내에서 컴파일된 어셈블리에 대한 참조를 설정하면 됩니다(이 예에서는 Taskbar 프로젝트 탐색).

또한 여러 개의 실행 중인 응용 프로그램 인스턴스에 동일한 응용 프로그램 ID 또는 각기 고유한 응용 프로그램 ID를 지정하여 작업 표시줄에서 이러한 인스턴스를 그룹화하거나 서로 분리할 수 있습니다. 응용 프로그램 인스턴스에 고유한 ID를 지정하려면 Application.Run을 호출하기 전에 응용 프로그램 ID를 설정해야 합니다. 자식 창에 고유한 작업 표시줄 아이콘만 부여하려면 응용 프로그램 ID를 언제든 바꾸면 됩니다.

사용 방법 자식 창에 고유한 작업 표시줄 아이콘을 지정하려면 JumpList 클래스를 사용하여 정적 메서드 CreateJumpListForIndividualWindow를 호출하고 자식 창에 응용 프로그램 ID와 창의 핸들을 전달합니다. 코드는 다음과 같습니다.

childWindowJumpList = JumpList.CreateJumpListForIndividualWindow(
childWindowApplicationId, this.Handle);

Windows Azure 통합

클라우드 컴퓨팅은 기존의 구내 및 웹 호스팅 아키텍처 솔루션에 대한 유력한 대안으로 급부상하고 있습니다. 간단히 말해, 클라우드 컴퓨팅은 소프트웨어 솔루션의 일부 또는 전체를 떼어 내 주문형 확장과 높은 안정성을 갖춘 커다란 데이터 센터에서 모든 것을 호스팅하는 회사를 둔다는 개념입니다. Windows Azure 플랫폼은 Microsoft의 클라우드 컴퓨팅 및 서비스 플랫폼으로, Windows Azure, SQL Azure 및 Windows Azure 플랫폼 AppFabric이라는 세 가지 서비스 집합으로 구성됩니다.

Windows Azure는 응용 프로그램 호스팅을 위한 환경으로, 클라우드의 OS라고 생각하면 됩니다. SQL Azure는 기본적으로 클라우드의 데이터베이스입니다. Windows Azure AppFabric은 클라우드에 호스팅되는 응용 프로그램이 사용하는 공통적인 구성 요소 집합입니다. Windows Azure AppFabric에는 현재 액세스 제어 서비스(페더레이션 인증 및 클레임 기반 권한 부여용)와 서비스 버스(클라우드와 구내 솔루션 간 연결용)의 두 가지 서비스가 포함됩니다.

Visual Studio 2010에는 Windows Azure 플랫폼 솔루션을 구축하기 위한 여러 프로젝트 템플릿이 포함되어 있습니다. VB.NET과 C#에 대해 모두 웹 역할용으로 4개, 작업자 역할용으로 하나의 템플릿이 있습니다. F#을 위한 작업자 역할 프로젝트 템플릿도 있습니다. VB.NET 및 C# 웹 역할 템플릿에는 ASP.NET, MVC with ASP.NET, WCF 서비스 및 CGI용으로 하나씩이 포함되어 있습니다.

Visual Studio 2010의 Windows Azure 플랫폼 프로젝트 작업 측면에서 한 가지 독특한 점은 프로젝트를 만들 때 여러 역할을 선택할 수 있다는 것입니다. 예를 들어 C#의 ASP.NET MVC 웹 역할과 VB.NET의 작업자 역할을 포함하여 새 프로젝트를 만들 수 있습니다. 클라우드 응용 프로그램에 대해 새로 만들기 | 프로젝트 환경이 조금 다른 것은 이것 때문입니다. 즉, 대부분의 다른 프로젝트 템플릿에서 볼 수 있는 단일 선택 패러다임을 통해서가 아니라 대화 상자에서 역할을 선택합니다.

사용 방법 Visual Studio 2010에서 Windows Azure 플랫폼을 대상으로 하는 프로젝트를 만들려면 그림 11과 같이 설치된 템플릿 목록에서 클라우드를 선택합니다.

그림 11 Visual Studio 2010에서 클라우드 프로젝트 형식 선택

이렇게 하면 원하는 역할을 선택할 수 있는 대화 상자가 표시되며 각 역할은 서로 다른 형식 및/또는 언어를 가질 수 있습니다. 그림 12는 ASP.NET MVC 웹 역할 한 개, VB.NET 작업자 역할 두 개 및 F# 작업자 역할 한 개가 포함된 새로운 Windows Azure 클라우드 서비스 프로젝트를 보여 줍니다.

그림 12 여러 역할과 언어로 클라우드 서비스 프로젝트 설정

다중 대상 지정

다중 대상 지정 자체는 사실 Visual Studio 2010에서 새로운 기능은 아니지만 주목할 만한 새로운 확장성 기능을 제공합니다. 많은 사람들이 다중 대상 지정의 이점과 이를 통해 Visual Studio 2010으로 이전 버전의 .NET Framework에서 실행되는 솔루션을 구축하는 방법을 모른다는 사실은 다소 의외입니다. 다중 대상 지정은 고급 디버깅 및 향상된 편집기 기능을 제공하는 최신 도구를 활용하고자 하지만 아직 코드(도는 고객)를 .NET Framework 4로 이동할 준비는 되지 않은 개발 팀을 위한 기능입니다. 다중 대상 지정을 사용하면 .NET Framework 버전 2.0, 3.0, 3.5 또는 4를 대상으로 응용 프로그램을 구축할 수 있습니다.

사용 방법 새 프로젝트를 시작할 때그림 13과 같이 드롭다운 목록에서 대상 프레임워크를 선택하기만 하면 됩니다.

그림 13 다중 대상 지정을 통해 대상 프레임워크 버전 선택

<More Frameworks(추가 프레임워크)…>(그림 13)에서 동그라미로 표시된 드롭다운 상자의 마지막 항목)를 사용하면 지원되는 대상 프레임워크를 확장할 수 있습니다. 이렇게 하면 프레임워크의 이후 버전을 추가할 수 있고, 앞으로 예정된 다른 .NET Framework 프로필까지 추가가 가능합니다. 이러한 추가 항목은 대부분의 경우 MSI를 통해 설치되겠지만 궁극적으로는 XML 설명 파일로 프레임워크 어셈블리를 시스템에 직접 복사하여 수동으로 추가할 수 있습니다.

기타

Visual Studio 2010에는 이 기사에서 다룬 것보다 훨씬 더 많은 새로운 기능이 있습니다. 회사에서 회사 리소스를 연계하는 데 유용한 사용자 지정 가능한 시작 페이지도 살펴보십시오. 또한 C++/ANSI 업데이트, 지속적으로 업데이트되는 도움말, 새로운 F# 프로그래밍 언어, Entity Framework, 프레임워크 향상, 코드 시각화를 비롯해 익힐 만한 새로운 기능이 많습니다. 이러한 기능을 갖춘 Visual Studio 2010은 현재 업계에서 기대하는 종류의 소프트웨어를 제공할 수 있는 매력적인 개발 도구입니다. 이 기사가 Visual Studio 2010이 제공하는 기능을 파악하는 데 도움이 되었기를 바랍니다. 직접 체험하고 싶다면 microsoft.com/vstudio에서 평가판을 다운로드하십시오.

Doug Turnure Microsoft Visual Studio 팀의 프로그램 관리자로 고객 의견 및 도입을 주로 담당합니다. 지금까지 개발자, 저자, 트레이너, 마케팅 담당자 등을 거쳤으며 가끔 회의 발표자를 맡기도 했습니다. 오랫동안 시애틀에서는 살지 않겠다고 다짐했었지만 지금은 시애틀에서의 생활을 즐기고 있습니다.

이 문서를 검토하는 데 많은 도움을 주신 기술 전문가인 Miguel Castro, Mark Dunn, Jim Wooley에게 감사의 말을 전합니다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02
심볼 스토어 생성 (0)	2012.12.23
Debug Diagnostic Tool (0)	2012.12.23

병렬 스택 창 사용

Visual Studio 2010

다른 버전

이 항목은 아직 평가되지 않았습니다.- 이 항목 평가

병렬 스택 창은 다중 스레드 응용 프로그램을 디버깅할 때 유용합니다. 스레드 뷰에는 응용 프로그램의 모든 스레드에 대한 호출 스택 정보가 표시됩니다. 따라서 스레드와 스레드 스택 프레임 간을 탐색할 수 있습니다. 관리되는 코드에서 작업 뷰는System.Threading.Tasks::Task 개체의 호출 스택이 표시됩니다. 네이티브 코드에서 작업 뷰는 작업 그룹, 병렬 알고리즘, 비동기 에이전트 및 간단한 작업의 호출 스택이 표시됩니다.

스레드 뷰

다음 그림에서는 Main에서 A, B 및 외부 코드로 차례로 이동한 하나의 스레드를 보여 줍니다.다른 두 스레드는 외부 코드에서 시작한 후 A로 이동했지만, 그 중 하나는 B로 진행한 후 외부 코드로 진행했고 다른 하나는 C로 진행한 후 AnonymousMethod로 진행했습니다.

그림에서 현재 스레드의 호출 경로는 파란색으로 강조 표시되며, 활성 스택 프레임은 노란색 화살표로 표시됩니다. 병렬 스택 창에서 다른 메서드를 선택하여 현재 스택 프레임을 변경할 수 있습니다.이렇게 하면 선택한 메서드가 현재 스레드의 일부인지 아니면 다른 스레드의 일부인지에 따라 현재 스레드가 전환될 수 있습니다.다음 표에서는 그림에 표시된 병렬 스택 창의 기본 기능에 대해 설명합니다.

설명선 문자	요소 이름	설명
A	호출 스택 세그먼트 또는 노드	하나 이상의 스레드에 대한 일련의 메서드 컨텍스트를 포함합니다.노드에 연결된 화살표 선이 없으면 스레드에 대한 전체 호출 경로를 나타냅니다.
B	파란색 강조 표시	현재 스레드의 호출 경로를 나타냅니다.
C	화살표 선	노드를 연결하여 스레드에 대한 전체 호출 경로를 구성합니다.
D	노드 머리글에 대한 도구 설명	호출 경로가 이 노드를 공유하는 각 스레드의 ID 및 사용자 정의 이름을 표시합니다.
E	메서드 컨텍스트	동일한 메서드에 있는 하나 이상의 스택 프레임을 나타냅니다.
F	메서드 컨텍스트에 대한 도구 설명	메서드 컨텍스트가 나타내는 모든 스택 프레임의 세부 정보를 표시합니다.현재 스레드의 스택 프레임이 굵게 표시됩니다.

또한 그래프가 너무 커서 창에 맞지 않는 경우에는 병렬 스택 창의 주 창에 Bird's Eye View 아이콘이 표시됩니다.전체 그래프를 창에서 보려면 이 아이콘을 클릭하면 됩니다.

메서드 컨텍스트 아이콘

다음 표에서는 활성 및 현재 스택 프레임에 대한 정보를 제공하는 아이콘을 설명합니다.

아이콘	설명
	메서드 컨텍스트에 현재 스레드의 활성 스택 프레임이 포함되어 있음을 나타냅니다.
	메서드 컨텍스트에 현재 스레드가 아닌 스레드의 활성 스택 프레임이 포함되어 있음을 나타냅니다.
	메서드 컨텍스트에 현재 스택 프레임이 포함되어 있음을 나타냅니다.메서드 이름이 나타나는 모든 노드에서 메서드 이름이 굵게 표시됩니다.

도구 모음 컨트롤

다음 그림과 표에서는 병렬 스택 도구 모음에서 사용할 수 있는 컨트롤에 대해 설명합니다.

설명선 문자	컨트롤	설명
A	스레드/작업 콤보 상자	스레드의 호출 스택과 작업의 호출 스택 간에 뷰를 전환합니다.자세한 내용은 작업 뷰와 스레드 뷰를 참조하십시오.
B	플래그 설정된 항목만 표시	스레드 창이나 병렬 작업 창에서 플래그 설정된 스레드 또는 작업에 대해서만 호출 스택을 표시합니다.
C	메서드 뷰 설정/해제	스택 뷰와 메서드 뷰 간을 전환합니다.자세한 내용은 메서드 뷰를 참조하십시오.
D	현재 스택 프레임으로 자동 스크롤	현재 스택 프레임이 뷰에 표시되도록 다이어그램을 자동 스크롤합니다.이 기능은 다른 창에서 현재 스택 프레임을 변경하거나 큰 다이어그램에서 새 중단점을 적중할 때 유용합니다.
E	확대/축소 컨트롤 설정/해제	확대/축소 컨트롤을 표시하거나 숨깁니다.확대/축소 컨트롤의 표시 여부와 관계없이 Ctrl 키를 누른 상태에서 마우스 휠을 돌려서 확대/축소할 수도 있습니다.

상황에 맞는 메뉴 항목

다음 그림과 표에서는 스레드 뷰와 작업 뷰에서 메서드 컨텍스트를 마우스 오른쪽 단추로 클릭할 때 사용할 수 있는 바로 가기 메뉴 항목에 대해 설명합니다.마지막 6개 항목은 호출 스택 창에서 직접 가져온 것으로 새로운 동작을 제공하지 않습니다.

Menu Item	설명
작업으로 이동 또는 스레드로 이동	도구 모음의 콤보 상자와 같은 기능을 수행하지만 동일한 스택 프레임이 강조 표시된 상태로 유지됩니다.
프레임으로 전환	호출 스택 창의 해당 메뉴 명령과 동일합니다.그러나 병렬 스택을 사용하는 경우 여러 프레임이 하나의 메서드 컨텍스트에 해당할 수 있습니다.따라서 메뉴 항목에 하위 메뉴가 있고 각각의 하위 메뉴가 특정 스택 프레임을 나타냅니다.스택 프레임 중 하나가 현재 스레드에 있으면 스택 프레임에 해당하는 메뉴가 선택됩니다.
소스 코드로 이동	사용자가 마우스 오른쪽 단추로 클릭한 스택 프레임에 해당하는 소스 코드의 위치로 이동합니다.
디스어셈블리로 이동	사용자가 마우스 오른쪽 단추로 클릭한 스택 프레임에 해당하는 디스어셈블리 창의 위치로 이동합니다.
외부 코드 표시	외부 코드를 표시하거나 숨깁니다.
16진수 표시	10진수 표시와 16진수 표시 간을 전환합니다.
기호 로드 정보	해당하는 대화 상자를 표시합니다.
기호 설정	해당하는 대화 상자를 표시합니다.

작업 뷰

응용 프로그램에서 System.Threading.Tasks::Task 개체(관리 코드)나 task_handle 개체(네이티브 코드)를 사용하여 병렬화를 표현하는 경우 병렬 스택 창 도구 모음의 콤보 상자를 사용하여 작업 뷰로 전환할 수 있습니다.작업 뷰에는 스레드 대신 작업의 호출 스택이 표시됩니다.작업 뷰는 다음과 같이 스레드 뷰와 다릅니다.

작업을 실행하고 있지 않은 스레드의 호출 스택이 표시되지 않습니다.
작업을 실행 중인 스레드의 호출 스택은 맨 위와 맨 아래에서 시각적으로 잘려 작업과 가장 많이 관련된 프레임을 표시합니다.
여러 작업이 한 스레드에 있으면 이러한 작업의 호출 스택이 개별 노드로 분할됩니다.

다음 그림의 오른쪽에는 병렬 스택 작업 뷰가 표시되고 왼쪽에는 해당 스레드 뷰가 표시됩니다.

전체 호출 스택을 보려면 스택 프레임을 마우스 오른쪽 단추로 클릭하고 스레드로 이동을 클릭하여 스레드 뷰로 전환하면 됩니다.

그림에서 작업 뷰의 노드 머리글은 노드가 표현하는 작업의 상태를 나타냅니다.앞의 표에서 설명했듯이 노드 머리글 또는 메서드 컨텍스트를 가리키면 추가 정보를 볼 수 있습니다.다음 이미지에서는 스레드 뷰와 작업 뷰에 대한 정보를 도구 설명으로 보여 줍니다.

메서드 뷰

스레드 뷰나 작업 뷰에서 도구 모음의 메서드 뷰 아이콘을 클릭하여 현재 메서드를 축으로 그래프를 회전할 수 있습니다.메서드 뷰에서는 현재 메서드를 호출하거나 현재 메서드에 의해 호출되는 모든 스레드에 대한 메서드를 모두 한눈에 볼 수 있습니다.다음 그림에서는 스레드 뷰를 보여 주며, 메서드 뷰에서 동일한 정보가 어떻게 표시되는지도 보여 줍니다.

새 스택 프레임으로 전환하여 해당 메서드를 현재 메서드로 설정하고 창에 새 메서드에 대한 모든 호출자 및 호출 수신자를 표시합니다.이렇게 하면 메서드가 호출 스택에 표시되는지 여부에 따라 일부 스레드가 뷰에 나타나거나 사라집니다.스택 뷰로 돌아가려면 메서드 뷰 도구 모음 단추를 다시 클릭합니다.

http://msdn.microsoft.com/ko-kr/library/dd998398(v=vs.100).aspx

약간 과장을 보태서 전체 스레드를 보는데 있어서만큼은 이 기능이 이렇게 편해도 되나싶을 정도의 기능인듯하다

windbg로 보기엔 귀찮은 일을 한눈에 알 수 있게 해준다

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

C2086, C2084, LNK2005 오류에 대하여 (0)	2013.02.27
WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
비주얼스튜디오 : 스레드디버깅 (2) : 다중 스레드 응용 프로그램 디버깅 (0)	2012.12.27
비주얼스튜디오 : 스레드 디버깅(1) (0)	2012.12.27
비주얼스튜디오 포함디렉토리, 라이브러리디렉토리 경로 포함시 주의점 (0)	2012.12.23

http://3dmpengines.tistory.com/1182 의 글을 먼저 본 후 읽어나가면 되고

스레드창을 활용한 글이라고 보면 된다

연습: 다중 스레드 응용 프로그램 디버깅

Visual Studio 2010

다른 버전

이 항목은 아직 평가되지 않았습니다.- 이 항목 평가

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

Visual Studio Edition	Visual Basic	C#	F#	C++	Web Developer
Express
Pro, Premium 및 Ultimate

Visual Studio 2010은 다중 스레드 응용 프로그램을 쉽게 디버깅할 수 있도록 향상된 스레드 창과 그 밖의 향상된 사용자 인터페이스를 제공합니다. 이 연습은 몇 분 정도 소요되지만 연습을 완료하면 다중 스레드 응용 프로그램 디버깅을 위한 새로운 인터페이스 기능에 익숙해질 수 있습니다.

이 연습을 시작하려면 다중 스레드 응용 프로그램 프로젝트가 필요합니다. 여기에 나열된 단계에 따라 프로젝트를 만드십시오.

연습 프로젝트를 만들려면

파일 메뉴에서 새로 만들기를 선택한 다음 프로젝트를 클릭합니다.
새 프로젝트 대화 상자가 나타납니다.
프로젝트 형식 상자에서 Visual Basic, Visual C#, Visual C++ 등 선택할 언어를 클릭합니다.
템플릿 상자에서 콘솔 응용 프로그램 또는 CLR 콘솔 응용 프로그램을 선택합니다.
이름 상자에 MyThreadWalkthroughApp라는 이름을 입력합니다.
확인을 클릭합니다.
새 콘솔 프로젝트가 나타납니다. 프로젝트가 만들어지면 소스 파일이 나타납니다. 선택한 언어에 따라 소스 파일 이름이 Module1.vb, Program.cs 또는 MyThreadWalkthroughApp.cpp일 수 있습니다.
소스 파일에 나타나는 코드를 삭제하고 스레드 만들기 및 시작할 때 데이터 전달 항목의 "스레드 만들기" 단원에 나타나는 예제 코드로 바꿉니다.
파일 메뉴에서 모두 저장을 클릭합니다.

연습을 시작하려면

소스 창에서 다음 코드를 찾습니다.
VB
Thread.Sleep(3000) Console.WriteLine(

C#

C++

Thread::Sleep(3000);
Console.WriteLine();

디버깅을 시작하려면

Console.WriteLine 문을 마우스 오른쪽 단추로 클릭하고 중단점을 가리킨 다음 중단점 삽입을 클릭합니다.
소스 창 왼쪽의 여백에 빨간 공이 나타납니다. 이 공은 이 위치에 중단점이 설정되었음을 나타냅니다.
디버그 메뉴에서 디버깅 시작을 클릭합니다.
디버깅을 시작하면 콘솔 응용 프로그램이 실행되다가 중단점에서 중지됩니다.
이때 콘솔 응용 프로그램 창에 포커스가 있으면 Visual Studio 창을 클릭하여 Visual Studio로 포커스를 되돌립니다.
소스 창에서 다음 코드가 있는 줄을 찾습니다.
VB
Thread.Sleep(5000)

C#

C++

Thread::Sleep(3000);

스레드 마커를 찾으려면

스레드 창을 마우스 오른쪽 단추로 클릭한 다음 소스의 스레드 표시를 클릭합니다.
창 왼쪽의 여백을 확인합니다. 이 줄에는 실 모양 아이콘 두 개가 있습니다. 하나는 빨간색이고 다른 하나는 파란색입니다. 스레드 마커는 이 위치에서 스레드가 중지되었음을 나타냅니다. 스레드가 이 위치에서 중지되었을 수 있습니다.
스레드 마커에 포인터를 올려 놓습니다. DataTip이 나타납니다. DataTip을 통해 중지된 각 스레드의 이름과 스레드 ID 번호를 알 수 있습니다. 이 경우 이름이 <noname>인 스레드 한 개만 있습니다.
스레드 마커를 마우스 오른쪽 단추로 클릭합니다. 바로 가기 메뉴에서 선택 내용을 확인합니다.

이 아이콘이 스레드 마커입니다.

스레드에 플래그 지정 및 해제

Visual Studio 2008에서는 특히 주의할 스레드에 플래그를 지정할 수 있습니다.스레드에 플래그를 지정하면 중요한 스레드를 추적하고 중요하지 않은 스레드는 무시할 수 있습니다.

스레드에 플래그를 지정하려면

보기 메뉴에서 도구 모음을 가리킵니다.
디버그 위치 도구 모음이 선택되어 있는지 확인합니다.
디버그 위치 도구 모음으로 이동하여 스레드 목록을 클릭합니다.
참고
프로세스, 스레드 및 스택 프레임이라는 세 개의 중요한 목록을 통해 이 도구 모음을 인식할 수 있습니다.
목록에 나타나는 스레드 수를 확인합니다.
소스 창으로 돌아가 스레드 마커를 다시 마우스 오른쪽 단추로 클릭합니다.
바로 가기 메뉴에서 플래그를 가리킨 다음 스레드 이름과 ID 번호를 클릭합니다.
디버그 위치 도구 모음으로 돌아가 스레드 목록을 다시 클릭합니다.
플래그가 지정된 스레드만 목록에 나타납니다. 스레드 목록 바로 오른쪽에 플래그 단추가 있습니다.이전에는 희미하게 표시되던 단추의 플래그 아이콘이지금은 밝은 빨강으로 표시됩니다.
플래그 아이콘에 포인터를 올려 놓습니다.
팝업이 나타납니다.이 팝업을 통해 스레드 목록의 모드가 플래그가 지정된 스레드만 표시임을 알 수 있습니다.
플래그 단추를 클릭하여 모든 스레드 표시 모드로 전환합니다.
스레드 목록을 다시 클릭하고 다시 모든 스레드가 표시되는지 확인합니다.
플래그 단추를 클릭하여 플래그가 지정된 스레드만 표시로 전환합니다.
디버그 메뉴에서 창을 가리킨 다음 스레드를 클릭합니다.
스레드 창이 나타납니다.스레드 한 개에 중요한 플래그 아이콘이 연결되어 있습니다.
소스 창에서 스레드 마커를 다시 마우스 오른쪽 단추로 클릭합니다.
바로 가기 메뉴에서 선택할 수 있는 항목을 확인합니다. 플래그 대신 플래그 해제가 표시됩니다. 플래그 해제를 클릭하지 마십시오.
스레드의 플래그를 해제하기 위한 다음 절차로 이동합니다.

참고
프로세스, 스레드 및 스택 프레임이라는 세 개의 중요한 목록을 통해 이 도구 모음을 인식할 수 있습니다.

스레드의 플래그를 해제하려면

스레드 창에서 플래그가 지정된 스레드에 해당하는 줄을 마우스 오른쪽 단추로 클릭합니다.
바로 가기 메뉴가 표시됩니다.이 메뉴에 플래그 해제 및 모든 스레드 플래그 해제 옵션이 있습니다.
스레드의 플래그를 해제하려면 플래그 해제를 클릭합니다.
빨간색 플래그 아이콘을 클릭합니다.
디버그 위치 도구 모음을 다시 확인합니다.플래그 단추가 다시 희미해집니다.플래그가 지정된 스레드의 플래그만 해제됩니다.플래그가 지정된 스레드가 없으므로 도구 모음은 다시 모든 스레드 표시 모드로 돌아갑니다. 스레드 목록을 클릭하고 모든 스레드가 표시되는지 확인합니다.
스레드 창으로 돌아가 정보 열을 검사합니다.
각 열 맨 위의 단추에는 대부분 열을 식별하는 제목이 있습니다.그러나 왼쪽 첫째 열에는 제목이 없습니다.대신 플래그 윤곽선에 해당하는 아이콘이 있습니다.스레드 목록의 각 행에도 같은 윤곽선이 있습니다.이 윤곽선은 스레드의 플래그가 해제되었음을 나타냅니다.
목록 아래쪽에서 둘째 스레드와 셋째 스레드의 플래그 윤곽선을 클릭합니다.
플래그 아이콘은 빈 윤곽선 대신 빨간색으로 변합니다.
플래그 열 맨 위의 단추를 클릭합니다.
단추를 클릭하면 스레드 목록의 순서가 변경됩니다.스레드 목록은 플래그가 지정된 스레드가 맨 위에 오도록 정렬됩니다.
플래그 열 맨 위의 단추를 다시 클릭합니다.
정렬 순서가 다시 변경됩니다.

스레드 창에 대한 추가 정보

스레드 창에 대해 자세히 알아 보려면

스레드 창에서 왼쪽 셋째 열을 확인합니다.이 열의 맨 위에 있는 단추에 ID라고 표시되어 있습니다.
ID를 클릭합니다.
스레드 목록이 스레드 ID 번호순으로 정렬됩니다.
목록의 스레드를 마우스 오른쪽 단추로 클릭합니다.바로 가기 메뉴에서 16진수 표시를 클릭합니다.
스레드 ID 번호 형식이 변경됩니다.
목록의 스레드에 마우스 포인터를 올려 놓습니다.
잠시 후 DataTip이 나타납니다.여기에 스레드의 부분 호출 스택이 표시됩니다.
범주 레이블이 있는 왼쪽에서 넷째 열을 확인합니다.스레드가 범주로 분류되어 있습니다.
프로세스에서 만든 첫째 스레드를 주 스레드라고 합니다.스레드 목록에서 주 스레드를 찾습니다.
주 스레드를 마우스 오른쪽 단추로 클릭하고 스레드로 전환을 클릭합니다.
경고 대화 상자가 나타납니다.이 대화 상자에서 Visual Studio가 주 스레드의 소스 코드를 표시할 수 없음을 알 수 있습니다.
확인을 클릭합니다.
호출 스택 창과 디버그 위치 도구 모음을 확인합니다.
호출 스택 창의 내용이 변경되었습니다.

활성 스레드 전환

스레드를 전환하려면

스레드 창에서 왼쪽 둘째 열을 확인합니다.이 열의 맨 위에 있는 단추에는 텍스트나 아이콘이 없습니다.이 열은 활성 스레드열입니다.
활성 스레드 열의 스레드 하나에 노랑 화살표가 있습니다.이 화살표는 활성 스레드 표시기입니다.
활성 스레드 표시기가 있는 스레드 ID 번호를 메모합니다.활성 스레드 표시기를 다른 스레드로 이동하겠지만 작업이 끝나면 다시 돌려 놓아야 합니다.
다른 스레드를 마우스 오른쪽 단추로 클릭하고 스레드로 전환을 클릭합니다.
소스 창에서 호출 스택 창을 확인합니다.내용이 변경되었습니다.
디버그 위치 도구 모음을 확인합니다.여기서도 활성 스레드가 변경되었습니다.
디버그 위치 도구 모음으로 이동합니다. 스레드 상자를 클릭하고 드롭다운 목록에서 다른 스레드를 선택합니다.
스레드 창을 확인합니다.활성 스레드 표시기가 변경되었습니다.
소스 창에서 스레드 마커를 마우스 오른쪽 단추로 클릭합니다.바로 가기 메뉴에서 전환을 가리킨 다음 스레드 이름과 ID 번호를 클릭합니다.
스레드 창, 디버그 위치 도구 모음의 스레드 상자, 소스 창의 스레드 표시기를 사용하여 활성 스레드를 변경하는 방법을 살펴 보았습니다.
스레드 표시기를 사용하면 특정 위치에서 중지된 스레드로만 전환할 수 있습니다. 스레드 창 및 디버그 위치 도구 모음을 사용하면 임의의 스레드로 전환할 수 있습니다.

스레드 실행 중지 및 재개

스레드를 중지 및 해제하려면

스레드 창에서 스레드를 마우스 오른쪽 단추로 클릭한 다음 중지를 클릭합니다.
활성 스레드 열을 확인합니다.세로 막대 쌍이 나타납니다.이 두 개의 파란색 막대는 스레드가 중지되었음을 나타냅니다.
일시 중단 열을 확인합니다.스레드의 일시 중단 횟수가 1입니다.
중지된 스레드를 마우스 오른쪽 단추로 클릭한 다음 재개를 클릭합니다.
활성 스레드 열과 일시 중단 열이 변경됩니다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

WinDbg를 이용해서 Critical Section 추적해 보기 (0)	2012.12.27
병렬 스택 창 사용 (0)	2012.12.27
비주얼스튜디오 : 스레드 디버깅(1) (0)	2012.12.27
비주얼스튜디오 포함디렉토리, 라이브러리디렉토리 경로 포함시 주의점 (0)	2012.12.23
비주얼스튜디오에서 쓰래드를 한구문씩 디버깅하기 (0)	2012.12.22

스레드창의 기능을 좀 더 자세하게 알 수 있는 글이지만 대강만 읽어도 사용법을 금방 알 수 있다

출처 : http://msdn.microsoft.com/ko-kr/library/w15yf86f(v=vs.100).aspx

방법: 스레드 창 사용

Visual Studio 2010

다른 버전

이 항목은 아직 평가되지 않았습니다.- 이 항목 평가

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

Edition	Visual Basic	C#	F#	C++	Web Developer
Express
Pro, Premium 및 Ultimate

스레드 창에서 디버깅 중인 응용 프로그램의 스레드를 검사하고 작업할 수 있습니다.

스레드 창에는 각 행이 응용 프로그램의 스레드를 나타내는 테이블이 있습니다. 기본적으로 이 테이블에는 응용 프로그램의 모든 스레드가 나열되지만 목록을 필터링하여 관심 있는 스레드만 표시할 수 있습니다. 열마다 다른 유형의 정보가 있습니다. 일부 열을 숨길 수도 있습니다. 모든 열을 표시하면 왼쪽부터 다음 정보가 나타납니다.

플래그 열 - 주의해야 할 스레드에 표시할 수 있습니다. 스레드에 플래그를 설정하는 방법에 대한 자세한 내용은 방법: 스레드에 플래그 지정 및 스레드의 플래그 해제를 참조하십시오.
활성 스레드 열 - 노란색 화살표는 활성 스레드를 나타냅니다. 화살표의 윤곽선은 실행이 중단되고 디버거가 실행된 스레드를 나타냅니다.
ID 열 - 각 스레드의 식별 번호가 표시됩니다.
관리 ID 열 - 관리되는 스레드의 관리 식별 번호가 표시됩니다.
범주 열 - 사용자 인터페이스 스레드, 원격 프로시저 호출 처리기 또는 작업자 스레드로 스레드가 분류됩니다. 특정 범주는 응용 프로그램의 주 스레드를 식별합니다.
이름 열 - 각 스레드가 이름(있는 경우) 또는 <이름 없음>으로 식별됩니다.
위치 열 - 스레드가 실행 중인 위치가 표시됩니다. 이 위치를 확장하여 스레드의 전체 호출 스택을 표시할 수 있습니다.
우선 순위 열 - 시스템에서 각 스레드에 할당한 우선 순위가 표시됩니다.
선호도 마스크 열 - 일반적으로는 숨겨지는 고급 열입니다. 이 열에는 각 스레드에 대한 프로세서 선호도 마스크가 표시됩니다.다중 프로세서 시스템에서는 선호도 마스크에 따라 스레드가 실행될 수 있는 프로세서가 결정됩니다.
일시 중단됨 열 - 일시 중단 횟수가 표시됩니다. 이 횟수에 따라 스레드를 실행할 수 있는지 여부가 결정됩니다. 일시 중단 횟수에 대한 설명은 이 항목의 뒷부분에 나오는 "스레드 중지 및 재개"를 참조하십시오.
프로세스 이름 열 - 각 스레드가 속하는 프로세스가 표시됩니다. 이 열은 여러 프로세스를 디버깅하는 경우에 유용하지만 일반적으로 숨겨져 있습니다.

중단 모드나 실행 모드에서 스레드 창을 표시하려면

디버그 메뉴에서 창을 가리킨 다음 스레드를 클릭합니다.

열을 표시하거나 숨기려면

스레드 창의 맨 위에 있는 도구 모음에서 열을 클릭하고 표시하거나 숨길 열 이름을 선택하거나 선택 취소합니다.

활성 스레드를 전환하려면

다음 단계 중 하나를 수행합니다.
- 스레드를 두 번 클릭합니다.
- 스레드를 마우스 오른쪽 단추로 클릭하고 스레드로 전환을 클릭합니다.
  노란색 화살표가 새 활성 스레드 옆에 나타납니다. 화살표의 회색 윤곽선은 실행이 중단되고 디버거가 실행된 스레드를 나타냅니다.

스레드 그룹화 및 정렬

스레드를 그룹화하면 테이블에 각 그룹의 제목이 나타납니다.제목에는 "작업자 스레드" 또는 "플래그가 해제된 스레드" 등의 그룹 설명과 트리 컨트롤이 포함됩니다.각 그룹의 멤버 스레드가 그룹 제목 아래에 나타납니다.그룹에 대한 멤버 스레드를 숨기려면 트리 컨트롤을 사용하여 그룹을 축소합니다.

그룹화가 정렬보다 우선하기 때문에 예를 들어 스레드를 범주별로 그룹화한 다음 각 범주 내의 ID로 정렬할 수 있습니다.

스레드를 정렬하려면

스레드 창의 맨 위에 있는 도구 모음에서 열 위에 있는 단추를 클릭합니다.
이제 해당 열의 값으로 스레드가 정렬됩니다.
정렬 순서를 역순으로 바꾸려면 동일한 단추를 다시 클릭합니다.
목록 맨 위에 나타난 스레드가 이제 맨 아래에 나타납니다.

스레드를 그룹화하려면

스레드 창 도구 모음에서 그룹화 방법 목록을 클릭하고 스레드를 그룹화할 조건을 클릭합니다.

그룹 내에서 스레드를 정렬하려면

스레드 창의 맨 위에 있는 도구 모음에서 그룹화 방법 목록을 클릭하고 스레드를 그룹화할 조건을 클릭합니다.
스레드 창에서 열의 맨 위에 있는 단추를 클릭합니다.
이제 해당 열의 값으로 스레드가 정렬됩니다.

모든 그룹을 확장하거나 축소하려면

스레드 창의 맨 위에 있는 도구 모음에서 그룹 확장 또는 그룹 축소를 클릭합니다.

특정 스레드 검색

Visual Studio 2010에서 지정된 문자열과 일치하는 스레드를 검색할 수 있습니다. 스레드 창에서 스레드를 검색하면 창의 열에 검색 문자열과 일치하는 모든 스레드가 표시됩니다.이 정보에는 위치 열의 호출 스택 맨 위에 나타나는 스레드 위치가 포함됩니다.그러나 기본적으로 전체 호출 스택이 검색되지는 않습니다.

특정 스레드를 검색하려면

스레드 창의 맨 위에 있는 도구 모음에서 검색 상자로 이동하고 다음을 수행합니다.
- 검색 문자열을 입력하고 Enter 키를 누릅니다.
  -또는-
- 검색 상자 옆의 드롭다운 목록을 클릭하고 이전 검색에서 검색 문자열을 선택합니다.
(선택 사항) 검색에 전체 호출 스택을 포함하려면 호출 스택 검색을 선택합니다.

스레드 중지 및 재개

스레드를 중지하면 리소스를 사용할 수 있어도 스레드 실행이 시작되지 않습니다.

네이티브 코드에서는 Windows 함수 SuspendThread와 ResumeThread 또는 MFC 함수 CWinThread::SuspendThread와CWinThread::ResumeThread를 호출하여 스레드를 일시 중단하거나 다시 시작할 수 있습니다. SuspendThread나 ResumeThread를 호출하는 경우 스레드 창에 나타나는 일시 중단 횟수를 변경할 수 있습니다.그러나 네이티브 스레드를 중지하거나 재개하는 경우에는 일시 중단된 횟수를 변경하지 않습니다.네이티브 코드에서는 스레드가 재개되고 일시 중단된 횟수가 0인 경우 이외에는 스레드를 실행할 수 없습니다.

관리 코드에서는 스레드를 중지하거나 재개하면 일시 중단된 횟수가 변경됩니다.관리 코드에서는 중지된 스레드의 일시 중단된 횟수가 1입니다.네이티브 코드에서 중지된 스레드의 일시 중단된 횟수는 0입니다. 단, SuspendThread 호출로 인해 스레드가 일시 중단된 경우는 예외입니다.

참고
네이티브 코드에서 관리 코드로의 호출을 디버깅할 때 관리 코드는 이를 호출한 네이티브 코드와 동일한 실제 스레드에서 실행됩니다.네이티브 스레드를 일시 중단하거나 중지하면 관리 코드도 중지됩니다.

스레드 실행을 중지하거나 재개하려면

스레드 창의 맨 위에 있는 도구 모음에서 스레드 중지 또는 스레드 재개를 클릭합니다.
이 동작은 스레드 창에서 선택되는 스레드에만 적용됩니다.

스레드 호출 스택 표시 및 프레임 간 전환

다중 스레드 프로그램에서 각 스레드에는 자신의 고유한 호출 스택이 있습니다. 스레드 창을 사용하여 편리하게 이러한 스택을 볼 수 있습니다.

스레드의 호출 스택을 보려면

위치 열에서 스레드 위치 옆의 역삼각형을 클릭합니다.
위치가 확장되어 스레드의 전체 호출 스택이 표시됩니다.

모든 스레드의 호출 스택을 보거나 축소하려면

스레드 창의 맨 위에 있는 도구 모음에서 호출 스택 확장 또는 호출 스택 축소를 클릭합니다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

병렬 스택 창 사용 (0)	2012.12.27
비주얼스튜디오 : 스레드디버깅 (2) : 다중 스레드 응용 프로그램 디버깅 (0)	2012.12.27
비주얼스튜디오 포함디렉토리, 라이브러리디렉토리 경로 포함시 주의점 (0)	2012.12.23
비주얼스튜디오에서 쓰래드를 한구문씩 디버깅하기 (0)	2012.12.22
비주얼스튜디오 디버깅시 무한루프구문에서 일시정지하기 (0)	2012.12.22

BLOG main image

windbg 에서 !analyze -v 이러한 명령을 치면

*******************************************************************************

* *

* Exception Analysis *

* *

*******************************************************************************

가 나오면서 어디가 에러인지 분석해준다

p.s 헐...

http://rein.kr/blog/archives/2528

WinDbg의 !analyze 가 강력한 이유

당연한 얘기지만, 그 만큼의 수고와 끊임 없는 개선이 따랐기 때문. 이미 10년이 넘은 이 툴은…

WER 팀의 작년 논문(작년 10월의 SOSP09,http://www.sigops.org/sosp/sosp09/papers/glerum-sosp09.pdf)에 따르면,

!analyze is roughly 100,000 lines of code implementing some 500 bucketing heuristics, with roughly one heuristic added per week.
!analyze 명령 (WinDbg)는 대략 십만 줄의 코드로 만들어져 있고, 이는 500 개의 버킷팅 휴리스틱을 구현한다. 그리고 개략적으로 매주 1개의 휴리스틱이 추가된다.

라 한다.^[1]

프로그래머가 직접 실행하기도 하는 부분이지만(windbg !analyze), 이 부분은 WER 서비스의 백엔드 서버들도 수행하는 부분이다. 그리고 이 부분에서 계속적으로 사용되고, 결과를 측정하고(!), 이를 반영해서 새로운 휴리스틱을 적용하는 등의 개선이 있었기에 굉장히 훌륭한 디버깅 툴이 된 것.

PS. 저 논문 굉장히 재밌다. 세부 내용 말고도 WER 서비스의 개략적인 역사와 통계, 측정치만 봐도 개발자들은 매우 재밌게 볼 수 있음.

해당 논문 3.2절의 첫 문단 일부 발췌 [↩]

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > WinDbg 사용법' 카테고리의 다른 글

windbg 워크스페이스 두번째 스타일 (0)	2013.06.06
비주얼스튜디오 스타일로 꾸민 windbg UI (0)	2012.12.14
[WinDbg] 6. 실행과 정지 (0)	2012.12.14
[ 세미나 1탄 ] WinDbg... Part 1. (0)	2012.12.12
WinDbg 명령어들 (0)	2012.12.09

http://cafe.naver.com/totallab/444

addmysym.bat

처음에는 C:\MySymbol에 심볼 파일을 하나씩 복사하고 사용하지만 점점 모듈 수가 많아지고 관리하는 버전이 많아지면 심볼 스토어를 설정해 더 편리하게 사용할 수 있습니다.

심볼 스토어(Symbol Store)란 모든 심볼 파일을 모아 놓고 해당 위치를 심볼 경로로 지정하면 디버깅하는 모듈의 심볼 파일이 저절로 찾아져서 매번 심볼 파일을 찾고 복사하는 작업을 할 필요가 없습니다.

<?xml:namespace prefix = o /><?xml:namespace prefix = o />

C:\MySymbols 에 매번 빌드한 심볼 파일을 심볼 스토어 형식으로 더하면 C:\MySymbols 에는 내가 개발하는 모듈의 모든 버전에 대한 심볼 파일들이 체크섬에 따라 분류되어 쌓이게 됩니다. 새로 빌드한 심볼 파일의 복사가 실패하지도 않고 과거 버전의 심볼 파일들도 유지되므로 과거 버전의 디버깅도 가능해집니다.

책에서 심볼 파일을 더하기 편하게 배치 파일을 만드는 방법을 제시하고 있습니다. 배치 파일 내부에서 symstore.exe를 사용하는데, 이것은 WinDbg 폴더에 있는 심볼 스토어 유틸리티 입니다. WinDbg 경로를 환경 변수에 지정해 놨으므로 배치 파일상에서 그냥 symstore.exe를 실행하면 됩니다.

C:\symstore add /f c:\Exam\Ch2\Src\MyApp\Release\MyApp.pdb /s C:\MySymbols /t Myproduct

/f 뒤에는 복사할 심볼 파일 경로를 지정하고, /s 뒤에는 복사될 위치를 지정합니다. /t는 제품 이름을 넣습니다. 매번 모든 옵션을 타이핑하기는 귀찮으므로 심볼 파일만 파라미터로 받게 ddMySym.bat 배치 파일을 만듭니다.(참고로 배치 파일 만드는 방법은 위에 한 줄 소스를 메모장으로 복사후 확장자를 bat으로 저장하시면 됩니다.)

Symstore add /f %1 /s C:\MySymbols /t MyProduct

이 배치 파일을 C:\Utility에 넣었다면 다음과 같이 사용합니다.

C:\Utility\AddMySym c:\Exam\Ch2\Src\MyApp\Release\MyApp.pdb

편하게 사용하려면 이 배치 파일을 놓고, 심볼 파일을 드래그 앤 드롭하면 됩니다. WinDbg에서 사용할 때는 심볼 경로에 C:\MySymbols를 추가해 놓으면 됩니다.

덧붙이자면 네트워크 폴더를 심볼 스토어로 사용하면 팀 프로젝트의 생산성을 더욱 향상시킬 수 있습니다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02
Visual Studio 2010을 사용한 코딩 개선 (0)	2012.12.27
Debug Diagnostic Tool (0)	2012.12.23

BLOG main image

대부분 외부 라이브러리(Directx 나 boost 같은)것에 대한 경로를 입력할때 폴더 경로 그대로 입력하면 링크에러가 난다

정확히 말하자면 어떨때는 나고 어떨때는 안나기도한다, 하지만 된다고 할지라도 나중에 어떤 문제가 발생할지 모름으로

정확히 해두는 것이 좋다

만약 directx 의 include 경로를 폴더경로 그대로인

C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include

라고 입력하면 링크 문제가 새긴다( F7눌러 현재 보이지 않는다 할지라도 나중을 위해 vs 에서 직접 경로를 선택하는

창을 띄워 선택해

C:\Program Files %28x86%29\Microsoft DirectX SDK %28June 2010%29\Include 과 같은 %로 연결된 형식을

취해야한다

왜냐하면 위에서도 언급했찌만 vs가 제대로 경로를 인식하지 못할 가능성이 있기때문이다

경로 사이사이에 폴더경로처럼 공백이 많은경우 인식을 더더욱 못한다

하지만 이것은 프로젝트가 많아질 수록 100% 귀찮은 작업인데

한가지 트릭은 각 프로젝트마다 공통적으로 포함될 경로를 우선 vs의 원하는 디렉토리 경로에

C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include 처럼 써놓고

바로옆의 경로를 지정하기위한 창을 누르면 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include 이경로에 대한

익스플로러창이뜨면서 그냥 '열기' 버튼을 누르면 자동으로

C:\Program Files %28x86%29\Microsoft DirectX SDK %28June 2010%29\Include

이와같은 경로가 된다

p.s 원리는 간단함으로 pass

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

비주얼스튜디오 : 스레드디버깅 (2) : 다중 스레드 응용 프로그램 디버깅 (0)	2012.12.27
비주얼스튜디오 : 스레드 디버깅(1) (0)	2012.12.27
비주얼스튜디오에서 쓰래드를 한구문씩 디버깅하기 (0)	2012.12.22
비주얼스튜디오 디버깅시 무한루프구문에서 일시정지하기 (0)	2012.12.22
UMDH로 메모리 릭 제거하기. (0)	2012.12.15

http://tudul2box.tistory.com/317

윈도우를 사용하다보면 이유없이 실행창이 꺼지는 현상을 많이 경험해 보았을 것이다.

이때 오류 분석파일(덤프)을 생성할 수 있는 프로그램을 사용하여 오류를 분석하는데,

마이크로 소프트사에서 제공해주는 Debug Diagnostic Tool을 이용하면 된다.

windbg 프로그램과 다른 점은 windbg는 직접 실행하고 프로세스가 끝날때마다 설정을 해주어야 하지만,

이 프로그램을 서비스로 실행되어 충돌(crash)가 발생하면 자동으로 지정 폴더에 저장해준다.

http://www.microsoft.com/en-us/download/details.aspx?id=26798

http://byung.egloos.com/4743470

[Troubleshooting Tool] Debug Diagnostic Tool Windows debugging

by 강세윤
2008/11/21 17:57
byung.egloos.com/4743470
덧글수 : 0

Debug Diagnostics Tool은 AD+ 와 같이 특정한 문제에 대해서 Memory Dump를 수집할 수 있는 기능을 제공한다. 여기서 특정한 문제라는 것은 Hang/Performance 문제/Memory 누수/Virtual Memory 조각화 및 다양한 Crash Issue이다. 뿐만 아니라 Crash나 Memory 관련 문제에 대해서 분석 report를 제공한다는 점에 있어서 유용하다.

먼저, Crash Rule에서 보면, 따로 설정하지 않은 1^st Chance Exception에 대한 설정을 할 수 있다. 아래의 그림과 같이 Action Type으로 Log를 남기거나 Mini Dump 및 Full Dump를 수집할 수 있도록 설정가능하며, dump 생성의 수를 제한할 수 도 있다. (만일, 0라고 설정하면 제한하지 않는 다는 의미이다.) Performance를 고려하여 대부분 None이거나 간혹 Log 정도를 남기게 된다.

그리고, 임의의 1^st Exception에 대한 Dump 수집을 설정할 수 있다. (이 말은 기본적으로 아무 설정을 하지 않았을 때, 2^nd chance exception에 대한 Crash Dump가 기본적으로 수집된다) 이는 상위 그림의 Advances Settings에 Exceptions 버튼을Click하여 설정한다.

상위의 그림은 좌측의 Exception Code에 AV를 Click 하여 1^st Chance AV가 발생했을 때 자료를 어떻게 수집할 지 설정하는 방법이다. 앞서서 설명한 것처럼 Action Type은 Log나 Mini 및 Full User Dump를 수집할 수 있도록 설정할 수 있다. 특이한 경우는 CLR Exception의 경우이다.

보면, .NET Exception Type 이라는 부분이 존재한다. 여기에 Exception 정보를 추가하면, 해당하는 Exception 에 대해서 Full User Dump를 수집하도록 설정된다.

Advanced Settings에 또 한가지는 Break point 를 설정하여 Dump를 수집할 수 있다는 것이다. 다음의 그림을 보자.

기본적으로 list에 Kernel32!ExitProcess나 몇 가지가 추가되어 있다. 일반적으로 2^nd Chance Exception으로 인하여 Process terminated 되는 경우에 Crash Dump를 수집하므로, Kernel32!ExitProcess를 list에서 선택하고 Action Type을 Full user Dump로 설정하여 Crash Rule 을 완성한다. 하지만, 외에 원하는 부분에 BP를 설정하고 Dump를 수집하거나 Log를 남기고 싶을 경우에는 상위의 그림과 같이 Breakpoint Expression 부분에 원하는 address를 설정하여 추가시킬 수도 있다.

그리고, Heap이 Corruption되는 증상에 대해서 일반적으로 Pageheap을 Enabled 하고 Crash Dump를 수집하게 되는 데, Debug Diagnostic Tool에서는 Advanced Settings에 PageHeap Flags… 라는 부분에서 PageHeap을 설정할 수 있다.

Debug Diagnostic Tool은 Process의 Memory Leak 현상을 Detection 하기 위해서 Leaktrack.dll을 injection 시켜서 Leak을 tracking 할 수 있는 기능이 존재한다.

Processes Tab을 확인해 보면, Process ID에 따른 Process list 정보를 알 수 있는 데, Leak으로 의심이 되는 Process를 선택하여 오른쪽 마우스를 Click 하면, Monitor For Leaks 라는 Menu를 확인할 수 있다. 이는 앞서서 설명한 Leaktrack.dll을 해당 Process에 Injection 시키는 역할을 한다. 이후에 Private Bytes의 증가를 유심히 확인하여 충분히 메모리가 지속적으로 증가하는 패턴이 확인되면, Create Full Userdump menu 를 통해 메모리 dump를 수집할 수 있다. 간혹 Memory Leak으로 인하여 Out Of Memory Exception이나 Crash를 동반하는 경우가 있으므로, Crash Rule에 Kernal32!ExitProcess 에 Full user dump와 함께 leaktrack을 걸어 놓는 것도 좋을 듯 하다.

** 메모리 Leak은?

Return 되지 않는 resource 로 인하여 process가 점유하고 있는 메모리가 지속적으로 증가하는 현상을 말한다. Logic에 따라서 Application이 메모리를 보유하고 사용할 수도 있으므로, 이와는 구분 되어야 한다. 이 경우, 시스템 resource가 부족하여 시스템의 전반적인 performance에 영향을 줄 수 있으며, 간혹 Hang 증상이 발생할 수 있다. 메모리 Leak을 판단하기 위해서는 메모리의 증가하는 패턴이 꾸준히 발생하기 때문에 성능로그의 Private Bytes 나 Virtual Bytes 그리고, Working Set의 데이터 패턴을 보고 Leak 여부를 판단해야만 한다.

*******

Debug Diagnostic Tool은 다음과 같은 메모리 할당에 대한 Tracking이 가능하다.

1) NT Heap allocator

1. HeapAlloc

2. LocalAlloc

3. GlobalAlloc

2) Virtual Memory allocator

1. VirtualAlloc

3) C Run time memory allocator

1. malloc

2. calloc

3. operator new

4) BSTR allocator

1. SysAllocString

5) OLE/COM allocator

1. CoTaskMemAlloc, IMalloc interface

Debug Diagnostic Tool이 제공하는 기능 중에 Crash Dump 및 Memory Dump 분석하여 reporting을 출력해주는 기능을 가지고 있다.

그림에서처럼 Advanced Analysis Tab에는 Crash나 memory analysis를 선택할 수 있다. 분석에 앞서서 Symbol을 정확하게 맞춰주는 것이 필요한데, tools menu의 Options and Settings … 를 통해서 설정할 수 있다.

Symbol Search path For analysis 에는 default로 Microsoft Public Symbol이(http://msdl.microsoft.com/download/symbols, 그리고, C:\symcache directory를 local machine의 symbol cache로 사용하도록 ) 설정되어 있다. 그리고, 필요한 symbol path를 Symbol Search Path for Debugging에 위치시켜야만 Symbol이 맞지 않아서 잘못된 reporting이 출력되는 것을 방지할 수 있다.

Debug Diag는 다음과 같은 Memory leak 관련 report 를 출력한다.

보면, Analysis summary에서 눈에 띄게 Memory를 보유하고 있는 Function Call을 Check할 수 있다. 상위 report에서는 asp.dll나 VBScript.dll 과 관련한 Callstack에서 메모리를 보유하고 있음을 보여주고 있는 데, 해당 Function을 Click 하면, 어떤 Callstack에 메모리 할당이 이뤄졌는지 다음과 같이 reporting 하고 있음을 확인할 수 있다. 그림에서는 안 나타나 있지만, sample callstack 정보와 더불어 단위 Allocation size와 Allocation Count에 따른 unfreed memory에 대한 Top 10 list of allocations 정보를 출력해 줌으로써 Allocation pattern을 알 수 있다.

그리고, 다음은 Application에서 사용하고 있는 Virtual Memory에 대한 정보이다. 아래 그림에서도 알 수 있지만, Application 전반적으로 Reserved/Commited 그리고 Free 영역에 대한 사용정도를 알 수 있다. 그리고, Virtual Memory Details에서는 Application 에서 VirtualAlloc이 얼마나 되는 지, Threads가 사용한 Memory 또는 Native Heap으로 사용된 메모리가 많은 지에 대한 정보를 제공한다.

Heap Memory의 경우는 다음과 같이 따로 정보를 제공한다. 각 Heap의 종류에 따라(예를 들어, Application에서 필요에 따라 Heap을 따로 관리하는 경우가 많은 데, default Heap 외에 crt heap이나 odbc나 oledb가 사용하는 mpheap 등이 존재할 수 있다.) 어느정도의 memory가 reserved 되어 있는 지, commit 되어 있는 지 보고해주며, 또한 Heap block에 따른 Address 정보나 세부적으로 memory의 할당여부를 확인할 수 있다. 이러한 Heap block의 정보를 가지고 의심이 나는 Heap 영역에 어떤 Data가 존재하는 지를 Memory Dump에서 Windbg를 통해 확인해 볼 수 있기 때문에 유용하다.

위의 그림에서도 나타나 있지만, Virtual Memory나 Heap Memory에 대한 Allocation 정보에서의 Top 10 List of allocations는 보다 직관적으로 unfree된 pattern을 알 수 있는 유용한 정보이다. 그러므로, 이러한 Heap이나 Virtual Memory에 대한 정보는 Application의 메모리 누수인지 아닌지에 대한 판단 및 누수일 때의 원인을 찾는 데 도움을 줄 수 있다.

그리고, 추가적으로 Handle count에 대한 정보를 출력해줌으로써 Handle leaks에 대한 tracking도 가능하고, IIS Hang과 같은 Issue를 위해 HTTP Ping을 주기적으로 설정하는 기능도 존재한다.

http://www.microsoft.com/en-us/download/details.aspx?id=26798

The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshootingissues such as hangs, slow performance, memory leaks or fragmentation, and crashes in any user-mode process. The tool includes additional debugging scripts focused on Internet Information Services (IIS) applications, web data access components, COM+ and related Microsoft technologies.

Quick details

Version:	1.2	Date published:	7/14/2011
Language:	English

Files in this download

The links in this section correspond to files available for this download. Download the files appropriate for you.

File name	Size
DebugDiagx64.msi	16.1 MB	DOWNLOAD
DebugDiagx86.msi	11.7 MB	DOWNLOAD

Overview

The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or memory fragmentation, and crashes in any user-mode process. The tool includes additional debugging scripts focused on Internet Information Services (IIS) applications, web data access components, COM+ and COM+ related Microsoft technologies, Sharepoint, and .NET framework.

DebugDiag 1.0 was released as part of the IIS Diagnostic Toolkit and as a standalone tool (x86 only).
DebugDiag 1.1 was released as a standalone tool only (x86 and limited x64 support).
DebugDiag 1.2 is currently available as a standalone tool only (x86 and full x64 support).

DebugDiag provides an extensible object model in the form of COM objects and provides a script host with a built-in reporting framework.

It is composed of the following 3 components: a debugging service, a debugger host, and the user interface.

The Debugging Service The debugger service (DbgSvc.exe) performs the following tasks:

Attach/Detach the host to processes
Collect performance monitor data
Implement HTTP ping to detect hangs
Inject leak monitor into running processes
Collect debugging session state information
Shows the state of each rule defined

The Debugger Host The Debugger Host (DbgHost.exe) hosts the Windows Symbolic Debugger Engine (dbgeng.dll) to attach to processes and generate memory dumps. It also hosts the main analyzer module to analyze memory dumps. Dbghost.exe has no dependency on the service “DbgSvc.exe” and can be used separately. The User Interface The user interfaces (DebugDiag.exe and DebugDiagAnalysisOnly.exe) present an interface to analyze memory dumps, automate the creation of control scripts and to show the status of running processes, including services. It is composed of 3 views:

Rules: Creates control script for the debugger host through a wizard. The script is located under the directory \scripts.
Advanced Analysis: Runs a selected “Analysis Script” against one or more memory dumps.
Processes: Shows status of running processes/services.

Note: DebugDiagAnalysisOnly.exe does not require privilege elevation on operating systems beginning with Windows Vista, so it only contains the Advanced Analysis view.

Top of page

System requirements

Supported operating systems: Windows 7

• Windows 2003-Windows XP • Windows 2008-Windows Vista • Windows 2008 R2- Windows7

Top of page

Instructions

Please visit Microsoft KB 2580960 for detailed instruction on how to use Debugdiag 1.2.

Debugdiag 1.2 introduced many new features that proved to be of great value:

Analysis:

.Net 2.0 and higher analysis integrated to the Crash Hang analysis.
SharePoint Analysis Script.
Performance Analysis Script.
.NET memory analysis script (beta).
Native heap analysis for all supported operating systems

Collection:

Generate series of Userdumps.
Performance Rule.
IIS ETW hang detection.
.NET CLR 4.0 support.
Managed Breakpoint Support.
Report Userdump generation to the Event log.

Deployment

Import/Export of rules and configuration, including 'Direct Push' to remote servers.
Enterprise deployment support using XCopy and Register.bat.

Please direct any questions, comments or feedback to dbgdiag@microsoft.com

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 (0)	2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 (0)	2013.05.07
프로파일과 도구들에 대한 ppt (0)	2013.02.02
Visual Studio 2010을 사용한 코딩 개선 (0)	2012.12.27
심볼 스토어 생성 (0)	2012.12.23

BLOG main image

여러 쓰래드들이 있다 가정하고, 각 쓰래드들의 첫 진입점에 각각 브레이크포인트를 걸어놓은 후

실행을 시키면 F10만 눌러보아도 알아서 현재 실행되는 쓰래드로 현재 실행시점이 이동되는것을 볼 수있다

이때 비주얼 스튜디오에 쓰래드창을 보면 각 쓰래드의 상태를 볼 수 있으며, 해당 쓰래드의 위치에 마우스를 가져가면

올려놓은 위치의 쓰래드에대한 call stack 을 보여주며 call stack의 함수를 더블클릭하면 해당 함수로 이동하게 된다

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

비주얼스튜디오 : 스레드 디버깅(1) (0)	2012.12.27
비주얼스튜디오 포함디렉토리, 라이브러리디렉토리 경로 포함시 주의점 (0)	2012.12.23
비주얼스튜디오 디버깅시 무한루프구문에서 일시정지하기 (0)	2012.12.22
UMDH로 메모리 릭 제거하기. (0)	2012.12.15
Process Explorer 사용법 (0)	2012.12.14

windbg 에서보면 현재 실행하는 프로세스에 windbg를 붙여 디버깅할 수 있는데 그때 필요한 것이 일시정지(ctrl+Pause/Break)키 명령이다

비주얼 스튜디오에도 그러한 기능이 있다

'디버그->모두중단' 을 누르거나 또는 ctrl+alt+Pause/Break 를 눌러도 중단이 된다

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

비주얼스튜디오 포함디렉토리, 라이브러리디렉토리 경로 포함시 주의점 (0)	2012.12.23
비주얼스튜디오에서 쓰래드를 한구문씩 디버깅하기 (0)	2012.12.22
UMDH로 메모리 릭 제거하기. (0)	2012.12.15
Process Explorer 사용법 (0)	2012.12.14
성능모니터 로그 적용 [CPU] (0)	2012.12.14

UMDH로 메모리 릭 제거하기.

프로그래밍 2012/02/17 06:00

Posted by 랩.좀비

안녕하세요. 한 타임 게시를 하지 못한 랩좀비입니다. DOD - Data Oriented Design - 에 대해서 열심히 글을 쓰다가, 실무에 직접 적용해 보지 않고 마냥 좋은 거라고 쓰는 것은 어디서나 찾아 볼 수가 있어서, 지금 회사에서 열심히 DOD를 적용하려고 작업중인 일이 끝나면 회고도 하면서 올리겠습니다. ...언제가 될지는 약속 드릴 수가 없네요. 요즘에 이것 저것 하다보니 적용할 시간이 없더군요. 올해 전반기에는 반드시 할 수 있도록 노력하고 있습니다.

그건 그렇고, 여러분의 프로젝트는 메모리 릭이 얼만큼 발생하십니까? 프로그램이 종료되면 릭이 발생하지 않습니까? 제가 하고 있는 프로젝트도 프로그램이 종료될 때에는 모두 해지가 되어서 메모리릭이 발생하지 않습니다. 하지만, 게임에 들어가면 미친듯이 릭이 발생하고 있었어요. 종료할 때는 메모리릭이 표시되지 않지만 게임중에서는 해지 되지 않는 불편한 상태가 진행되고 있었습니다.

지금까지는 늘어나는 양이 눈에 띄지 않아서 무시해도 될만한 수준이었는데, 최근에 이 문제가 표면에 드러나서 - 무려 시스템 메모리를 2기가 이상까지 올려버려 new에서 badalloc Exception을 보내는 상태까지 가더군요.- 이것을 추적하기 위해 UMDH라는 툴을 사용했습니다. 해당 툴에 대해서 알려주신 모님께 감사를. 프로그래머의 실력은 디버깅에 있다는 생각이 문득 들더군요. 뭐 이건 개인적이 견해이니 넘어가구요...

오늘은 UMDH의 맛만 보도록 하겠습니다. 맛만 봐도 어지간한 메모리릭은 잡을 수 있어요.

UMDH는 메모리를 캡쳐하는 기능을 가지고 있습니다. 그리고 캡쳐된 2개의 로그를 비교해서 변화량을 알려주는 기능도 있지요. 그렇다면 이걸로 어떻게 메모리 릭을 잡느냐... 그냥 게임 시작하면 캡쳐(1)를 하고 여기 저기 돌아다니면서 메모리릭이 발생하는 곳을 찾아서 캡쳐(2)를 한 후, 1번과 2번을 비교해서 그 동안 할당된 로그를 뒤져보는 것입니다. 물론 할당되고 해지된 녀석은 나오지 않습니다.

UMDH는 WinDBG가 있는 툴셋에 포함되어 있습니다. WinDBG짱좋아요잘쓰면님은나와다른초보 그럼 어떻게 사용하는지 한 번 봐볼까요?

1. 먼저 어플리케이션을 실행한 다음 UMDH가 적용될 프로그램에 '이놈에게 UMDH를 쓰겠소' 라며 알려줍니다.
저는 개발중인 클라이언트에 적용해 보겠습니다. 파일명만 있으니 보안에 접촉되지 않겠지.우리사장님은대범하시니까.

2. 그리고 캡쳐를 합니다. 캡쳐할 때 프로세스의 ID를 알아와야 하는데 이것은 tlist 명령어를 통해서 알아올 수 있습니다.

이렇게 알아와서

이렇게 캡쳐를 하지요.

심볼이 없다고 하는데, pdb파일이 있다면 무시하셔도 됩니다만, 정확한 체크를 위해서는 심볼 패스를 지정하는 게 더 좋긴 합니다. 심볼이 없으면 안나오는 정보도 있습니다.

3. 비교를 위해 프로그램을 조금 돌리다가 캡쳐를 합니다.

4. 이제 비교한 파일을 뱉어 달라고 UMDH에 요청합니다.

5. 만들어진 log를 열어봅니다. 굉장히 긴 파일이 만들어지는데, 이게 그 동안 할당된 메모리를 나타냅니다.
노란색으로 색칠해진 부분이 16진수로 표현된 바이트입니다.

이 툴을 이용해서 지난 1주일간 꽤 많은 릭을 잡아 냈습니다. 대부분이 스크립트에서 발생한 것이었지만, 프로그램 쪽에서도 해지 않고 있었던 메모리가 있었지요. UMDH 외에 LeakDiag라는 툴도 있습니다. 이쪽도 한번 구글링해서 테스트 해 보는것도 추천합니다. 무려 메모리변화를 그래프로 출력해 주지요. 하지만 사용해 보니 프로그램의 상태를 툴에서 인젝션할 때 자주 다운되더군요.

암튼, 오늘도 가벼운 주제를 긁고 저는 이만 물러가겠습니다. 좋은 하루 되세요.

http://gamedevforever.tistory.com/103

3DMP engines

3D그래픽스 물리 수학, 프로그래밍 GPU Shader 게임엔진 알고리즘 디자인패턴 matlab etc..

UMDH는 릭을 발견한곳이 100% 메모리릭이 발생한곳이 아니고 메모리릭일 가능성이 있음을 알려주는 것임으로

그것이 릭인지는 개발자가 판단해야한다

MFC 에서는 VLD 쓰는게 나을것 같다

cmd 명령창에서 "GFlags -I 응용프로그램이름.exe +ust" 로 유저스택 추적을 설정

시스템의 환경변수는 아래처럼 설정한다

"cmd 에서 Set _NT_SYMBOL_PATH=c:\Window\symbols;응용프로그램심볼경로"

를 설정해주면 되고 아래 소개된글에서는 tlist 로 cmd 에서 프로세스ID를 알아보지만

작업관리자 창에서도 PID열을 추가하면 해당 응용프로그램의 프로세스ID를 알 수 있기때문에

캡쳐하는 수고를 덜 수있다.

사용하는 법은 아래 글을 참고하면 되고 약간 설명을 추가하자면

결과 log파일은

+ 523( 523- 0) 10 allocs BackTraceCFF

+ 10( 10 - 0) BackTraceCFF allocations

처럼 중간에 나오는데 이것은

523바이트의 메모리를 할당한것이며, 10회의 메모리 할당이 있었는데 아직 해제되지 않았다는 뜻이다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

비주얼스튜디오에서 쓰래드를 한구문씩 디버깅하기 (0)	2012.12.22
비주얼스튜디오 디버깅시 무한루프구문에서 일시정지하기 (0)	2012.12.22
Process Explorer 사용법 (0)	2012.12.14
성능모니터 로그 적용 [CPU] (0)	2012.12.14
[WinDbg] 4차 세미나 PPT - 고급 디버깅 (0)	2012.12.14

http://www.reversecore.com/29

Process Explorer

Windows 최고의 프로세스 관리 도구 Process Explorer 입니다.

https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

저 유명한 sysinternals (현재는 MS에 인수되었음) 의 Mark Russinovich 씨가 만든 프로세스 관리 유틸리티입니다.

이분은 Windows 운영체제에 대해서 매우 해박한 지식을 갖고 있으며,
유용한 유틸리티(FileMon, RegMon, TcpView, DbgView, AutoRuns, Rootkit Revealer, etc) 들을 만들어 공개하였습니다.

언젠가 한번은 FileMon 과 RegMon 의 소스 코드를 공개하신적이 있습니다. (지금은 없어졌지요.)
Windows 운영체제 초창기에 (맨땅에 헤딩하던) 시스템 드라이버 개발자들에게 있어서
그 소스들은 그야말로 사막의 오아시스 같은 존재였습니다.

각설하고 Process Explorer 의 실행화면을 보실까요.

< Fig.1 - Process Explorer 실행화면 >

Windows 작업관리자와는 비교 할 수 없는 아주 뛰어난 화면 구성을 보여주고 있습니다.

화면 위의 좌측에는 현재 실행중인 프로세스들을 Parent/Child 의 트리 구조로 표시하고 있습니다. (무려 아이콘 까지!!!)
우측에는 프로세스 각각의 PID, CPU 점유율, 등록정보 등을 보여줍니다. (Option 을 통해 더 추가 가능)

화면 아래(욥션)에는 선택된 프로세스에 매핑된 DLL 정보 또는 해당 프로세스에서 오픈한 object handle 을 표시합니다.

구체적으로 뭐가 좋은거죠?

좋아 보이기는 하는데 구체적으로 뭐가 좋은건지 궁금하시죠?

저는 리버싱 할 때 항상 Process Explorer 를 같이 띄워놓고 합니다.
제가 Process Explorer 를 좋아하는 이유는 이렇습니다.

Parent/Child 프로세스 트리 구조

프로세스 실행/종료시 각각의 색깔(초록/빨강)로 표시

프로세스 suspend 기능 (실행 중지)

프로세스 종료(kill) 기능 (Kill Process Tree 기능 지원)

DLL/Handle 검색 (프로세스에 인젝션된 DLL 검색 또는 특정 파일을 오픈한 프로세스 검색)

이외에도 다양한 기능들이 있습니다만, 위 기능들이 특히 리버싱 할 때 많이 사용되는 기능들입니다.
그리고 꾸준한 업데이트(버그 수정, 기능 추가)도 큰 장점입니다.

sysinternals

sysinternals 홈페이지에 가보시면 Process Explorer 의 미니 콘솔 버전들이 있습니다.
(PsKill, PsSuspend, PsList, etc)

이 유틸들도 받아서 실행해 보세요. Process Explorer 의 기능을 축소시킨 멋진 콘솔 버전 프로그램들입니다.

리버싱을 위해 Windows 내부구조를 공부하시는 분들께서는 간단히 이런 콘솔 프로그램을 따라 만들어 보세요.
프로세스와 DLL 등에 대한 이해를 높일 수 있습니다.
(제 경험상 따라 만드는 방법이 실력 향상을 위한 가장 좋은 방법입니다. ^^)

이상으로 최고의 프로세스 관리 유틸리티 Process Explorer 에 대한 소개를 마칩니다.

http://shinyhappy.tistory.com/25

Process Explorer 사용법

Spyware 2007/06/15 19:56

실행 중인 프로세스를 확인하고 관리하는데 보통 윈도우 작업관리자를 사용합니다.

그러나 작업관리자로는 실행 중인 프로세스에 대한 충분한 정보를 얻을 수 없는 경우가 있습니다.

실행 중인 프로세스에 대한 모든 정보를 알고 싶을 때는 MS의 Process Explorer를 사용합니다.

Process Explorer는 Sysinternals에서 제작 배포하는 도구였으나 MS가 Sysinternals를 인수하여 Sysinternals 홈페이지는 MS Technet 사이트로 연결됩니다.

Sysinternals 에서는 Process Explorer 이외에도 AutoRuns, Regmon, Filemon 같은 유용한 도구를 Free로 다운로드할 수 있습니다.

[Process Explorer 다운로드]

Process Explorer 실행

다운로드 후에 압축을 풀고 "procexp.exe" 파일을 실행한 후 사용권계약서에 동의합니다.

Process Explorer 실행

Process Explorer의 기본화면 입니다.

실행중인 프로세스의 이름, CPU 점유율, 설명, 회사 이름이 기본으로 표시됩니다.
Tree를 이용하여 프로세스 실행의 계층 관계를 확인할 수 있습니다.

Process Explorer

옵션에서 Replace Task Manager 메뉴를 체크하면 윈도우 작업관리자를 대체합니다.

이 경우 유명한 Ctrl+Alt+Delete 키를 누르게 되면 작업관리자 대신에 Process Explorer가 실행됩니다.

작업관리자 대체

View 메뉴에서 Select Column을 선택하면, 추가 정보를 확인할 수 있습니다.

컬럼 선택

여러가지 기능이 있지만 주로 사용하는 것은 Image Path와 Command Line 입니다.

Image Path : 실행 중인 프로세스의 전체 경로를 표시합니다.
Command Line : 실행 중인 프로세스의 명령줄 옵션을 표시합니다.

컬럼 선택 대화상자

선택한 컬럼이 적용되었습니다. Path에는 실행 중인 프로세스의 전체 경로가 표시되고, Command Line에는 옵션 및 스위치 등의 명령줄이 표시됩니다.

컬럼 적용

실행 중인 프로세스를 강제로 종료하고 싶을 때는 프로세스를 선택한 후 마우스 오른쪽 버튼 메뉴에서 Kill Process을 선택합니다.

응답이 없는 프로그램, CPU 점유율이 지나치게 높은 프로세스, 악성코드 및 스파이웨어 제거에 유용하게 사용할 수 있습니다.

Kill Process Tree 메뉴는 종속 관계로 실행된 모든 프로세스를 종료할 수 있습니다. Hooking을 하거나 종속관계로 실행되는 악성코드 제거에 유용하게 사용할 수 있습니다.

프로세스 종료

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

비주얼스튜디오 디버깅시 무한루프구문에서 일시정지하기 (0)	2012.12.22
UMDH로 메모리 릭 제거하기. (0)	2012.12.15
성능모니터 로그 적용 [CPU] (0)	2012.12.14
[WinDbg] 4차 세미나 PPT - 고급 디버깅 (0)	2012.12.14
[WinDbg] 3차 세미나 PPT - 유저모드 디버깅 케이스 (0)	2012.12.14

http://jkmoon.tistory.com/76

성능모니터 로그 적용

특정시간에, 시스템의 성능에 영향을 주는지는 확인하기 위하여 성능모니터 로그를 적용하여, 로그수집

하는 방법을 포스팅 하도록 하겠습니다.

[환경]

Windows Server 2008R2 EE

1. 시작 > 실행 > perfmon 실행하신 후 성능모니터에 적용 할 카운터를 추가 합니다.

2. processor 성능확인을 위해 아래와 같이 카운터를 추가하였습니다.

3. 카운터를 적용한 설정을 다른이름으로 저장 합니다.

4. Cpu성능.htm 으로 저장 합니다.

5. 새로 만들기 > 데이터 수집기 집합 적용합니다.

6. 이름은 임의대로 적용하시면 됩니다. 다음

7. 데이터를 저장할 위치를 선택합니다.

8. 저장 후 닫기 선택 합니다. > 마침

9. CPU성능 > 속성을 선택 합니다.

10. 일정을 확인 하신 후 아래처럼 시작 시간을 적용합니다.

11. 시스템 모니터 로그 > 속성을 열어 필요한 설정을 합니다.

12. 샘플 간격을 15초로 설정 하겠습니다. 15초마다 성능을 취합 합니다.

13. 로그파일의 이름과 형식을 설정합니다.

14. 설정된 시간에 맞게, 성능모니터에서 로그 수집이 진행 됩니다.

15. Explore창을 여러 개 띄운 후 CPU 사용률을 증가 시켜봅니다.

그리고, 성능로그 수집을 종료한 후 로그 분석을 진행 하도록 하겠습니다.

16. 로그파일을 더블 클릭하여, 수집된 로그를 토대로 CPU 성능을 확인 합니다.

[참조사이트]

Windows 성능 모니터

http://technet.microsoft.com/ko-kr/library/cc749249(WS.10).aspx

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

UMDH로 메모리 릭 제거하기. (0)	2012.12.15
Process Explorer 사용법 (0)	2012.12.14
[WinDbg] 4차 세미나 PPT - 고급 디버깅 (0)	2012.12.14
[WinDbg] 3차 세미나 PPT - 유저모드 디버깅 케이스 (0)	2012.12.14
[WinDbg] 14. 덤프 파일 열기 (0)	2012.12.14

블로그 이미지

3DMP engines

3D그래픽스 물리 수학, 프로그래밍 GPU Shader 게임엔진 알고리즘 디자인패턴 matlab etc..

이건 지극히 나의 개인적 visual studio UI 스타일이라 딱히 광범위한 스타일이라곤 하긴 어렵지만

응용프로그램에 대한 유저디버깅을 위주로 하는 사람에게는 유용할것으로 생각한다.

VSstyle_sjh.WEW

다운로드

워크스페이스를 작성했던 windbg 버전은 6. 버전계열이다

저작자표시 비영리 동일조건

'디버깅 & 스킬 > WinDbg 사용법' 카테고리의 다른 글

windbg 워크스페이스 두번째 스타일 (0)	2013.06.06
!analyze -v 명령 (0)	2012.12.23
[WinDbg] 6. 실행과 정지 (0)	2012.12.14
[ 세미나 1탄 ] WinDbg... Part 1. (0)	2012.12.12
WinDbg 명령어들 (0)	2012.12.09

고급 디버깅은 꼭 필요하지는 않지만(기본 디버깅 방법만 알아도 디버깅 할 수 있지만) 알아 두면

디버깅하는데 도움이 되는 것들에 대해 다루었습니다.

집에서 시간이 더 많음에도 불구하고 공부는 더 안되는군요...

세미나 PPT 내용도 예전보다 나아지지는 못할 망정 부실해 지는거 같습니다.

빨리 멤버십 복귀해서 많이 부족하지만 카페북을 빨리 마무리 하고, 스피드하게 크랙미를 끝내도록

노력하겠습니다.

[디버깅][windbg] 4차 세미나 ppt - 고급디버깅_김현철.pptx

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

Process Explorer 사용법 (0)	2012.12.14
성능모니터 로그 적용 [CPU] (0)	2012.12.14
[WinDbg] 3차 세미나 PPT - 유저모드 디버깅 케이스 (0)	2012.12.14
[WinDbg] 14. 덤프 파일 열기 (0)	2012.12.14
`WinDBG로 Deadlock 알아내기 (0)	2012.12.14

강좌글 올린 것 중 가장 많이 발생하는 경우인 잘못된 메모리 사용, 메모리 누수에 대한 상황을 어떻게

해결해야 되는지에 대해 준비했습니다.

시작발표, 갑작스러운 이사 때문에 정신 없어서 시그 활동을 열심히 못한 거 같습니다.

다시 달려야 하는데, 역시 집에서 공부하기 힘드네요...;;

[디버깅][windbg] 3차 세미나 ppt - 유저모드 디버깅 케이스_김현철.pptx

저작자표시 비영리 동일조건

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

성능모니터 로그 적용 [CPU] (0)	2012.12.14
[WinDbg] 4차 세미나 PPT - 고급 디버깅 (0)	2012.12.14
[WinDbg] 14. 덤프 파일 열기 (0)	2012.12.14
`WinDBG로 Deadlock 알아내기 (0)	2012.12.14
WinDbg를 이용해서 Critical Section 추적 (0)	2012.12.14

http://cafe.naver.com/totallab/447

심볼 로드까지 완료하고 준비가 됐으면 프로그램을 실제로 실행합니다. WinDbg에서 멈춰있던 프로그램을 실행하는 세 가지 방법이 있습니다.

① 명령 창에서 g 명령을 수행

② F5 키를 누름

③ 메인 UI의 툴바에서 Go 버튼을 누름

위 세 가지 방법 중 아무거나 사용해도 수행 결과는 아래와 같습니다.

명령줄은 프로그램이 실행 중이므로 ‘*BUSY* Debuggee is running…’을 표시하면서 입력을 받아들이지 않는 상태가 됩니다.

이 상태에서 프로그램을 WinDbg로 제어 하려면 프로그램을 멈춰야 합니다. 멈추기 위해서는 두 가지 방법이 있습니다.

① Ctrl + Break 키를 누름

② 메인 UI의 툴바에서 브레이크(Break) 버튼을 누름

위 두 가지 방법 중 아무거나 사용해도 수행 결과는 아래와 같습니다.

‘Break instruct exception’이 표시되면서 현재 레지스터 상태를 표시하고 멈춥니다. 프로그램은 멈춰있는 상태이고 명령줄이 활성화되어 각종 제어 명령을 사용할 수 있습니다.

저작자표시 비영리 동일조건

'디버깅 & 스킬 > WinDbg 사용법' 카테고리의 다른 글

!analyze -v 명령 (0)	2012.12.23
비주얼스튜디오 스타일로 꾸민 windbg UI (0)	2012.12.14
[ 세미나 1탄 ] WinDbg... Part 1. (0)	2012.12.12
WinDbg 명령어들 (0)	2012.12.09
Unable to verify checksum for ... 워닝 (0)	2012.12.08

디버깅 & 스킬

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

Visual Studio 다운로드

Visual Studio Community 2015 - 무료

Visual Studio 2015 언어 팩

Visual Studio Enterprise 2015

Visual Studio 2015 언어 팩

Visual Studio Professional 2015

Visual Studio 2015 언어 팩

Visual Studio Test Professional 2015

Visual Studio Test Professional 2015 언어 팩

Visual Studio Express 2015 for Windows Desktop

Visual Studio Express 2015 for Web

Visual Studio Express 2015 for Windows 10

Windows용 Visual Studio 코드

Mac OS용 Visual Studio 코드

Linux용 Visual Studio 코드

ReSharper

Visual Studio용 Microsoft Azure HDInsight Tools

업데이트 5용 Web Essentials 2013

Visual Studio 2013용 PowerShell 도구

Visual Studio용 Python 도구

Productivity Power Tools 2013

DevExpress

Xamarin 플랫폼

Visual Studio 2013 Tools for Unity

GitHub Extension for Visual Studio

Visual Studio Team Foundation Server 2015

Team Foundation Server용 Team Explorer Everywhere 2015

Visual Studio Team Foundation Server Express 2015

Project Server 2015용 Visual Studio Team Foundation Server 확장

Microsoft Visual Studio Team Foundation Server 2015용 Feedback Client

Agents for Microsoft Visual Studio 2015

Microsoft Build Tools 2015

Visual Studio 2015용 Visual C++ 재배포 가능 패키지

Visual Studio 2015용 Release Management

Visual Studio 2015용 원격 도구

Visual Studio 2015 SDK

Visual Studio 2015 모델링 SDK

Visual Studio 2013 업데이트 5(Visual Studio 2013.5)

Visual Studio 2012 업데이트 5(Visual Studio 2012.5)

Microsoft .NET Framework 4.6

Microsoft .NET Framework 4.6 언어 팩

Microsoft .NET Framework 4.5.1

Microsoft .NET Framework 4.5.1 언어 팩

Microsoft .NET Framework 4.5.1 개발자 팩

Visual Studio Community 2013 업데이트 5

Visual Studio 2013 언어 팩

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

'디버깅 & 스킬 > 디버깅 & VS Debugging' 카테고리의 다른 글

'디버깅 & 스킬 > WinDbg 사용법' 카테고리의 다른 글

Introduction

Finding memory leaks

Only use exception-handling

Example

Explanation

More options by calling InitAllocCheck

Explanation

Mem-leak-analyse tool

A word on leaks

In detail

Hashtable

Insert an allocation into the Hashtable

Building the leak-list

Ignoring allocations

A word on COM-leaks

MFC usage

Temporarily disable logging (only CRT)

Simple using

Second simple using

Advanced using

Common mistakes

Visual Studio 7 and Win2K / NT

To get it to work you have to do the following

Known issues

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글

'디버깅 & 스킬 > 디버깅 툴&유틸' 카테고리의 다른 글