디버깅 & 스킬/디버깅 툴&유틸

visual studio 2013 comunity 비주얼 스튜디오 2013 커뮤니티버전 2015.11.01
멀티쓰래드 메모리릭 _CrtSetDbgFlag 2013.10.24
[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace 2013.05.22
디버깅및 메모리 누수 감지 툴들 2013.05.22
바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴 2013.05.07
Rational Purify 메모리 누수정보 얻는 툴킷 2013.05.07
프로파일과 도구들에 대한 ppt 2013.02.02
Visual Studio 2010을 사용한 코딩 개선 2012.12.27
심볼 스토어 생성 2012.12.23
Debug Diagnostic Tool 2012.12.23

visual studio 2013 comunity 비주얼 스튜디오 2013 커뮤니티버전

2015. 11. 1. 03:49

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

Visual Studio 다운로드

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

멀티쓰래드 메모리릭 _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

2013. 10. 24. 15:50

아래 프로그램을 돌려보면 릭이 잡히기도 하고 안잡히기도 한다, 즉 프로그램 내에서 _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

[메로리릭툴] MemLeakAnalyse-Tool (with source), Memory(-Leak) and Exception Trace

2013. 5. 22. 22:13

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

디버깅및 메모리 누수 감지 툴들

2013. 5. 22. 21:22

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

바운즈 체커(bounds checker) 메모리누수 정보 얻는 툴

2013. 5. 7. 02:32

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

Rational Purify 메모리 누수정보 얻는 툴킷

2013. 5. 7. 02: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

프로파일과 도구들에 대한 ppt

2013. 2. 2. 11:42

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

Visual Studio 2010을 사용한 코딩 개선

2012. 12. 27. 17:47

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

심볼 스토어 생성

2012. 12. 23. 20:22

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

Debug Diagnostic Tool

2012. 12. 23. 08:56

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

PREV 1 NEXT

디버깅 & 스킬/디버깅 툴&유틸

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 언어 팩

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

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

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

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

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

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

Rational Purify

Product Editions

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

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