Microsoft MVP성태의 닷넷 이야기
.NET Framework: 728. windbg - 눈으로 확인하는 Workstation GC / Server GC [링크 복사], [링크+제목 복사]
조회: 2834
글쓴 사람
홈페이지
첨부 파일
 

windbg - 눈으로 확인하는 Workstation GC / Server GC

예전 글에서,

.NET Garbage Collection에 대한 정리
; https://www.sysnet.pe.kr/2/0/1862

ASP.NET을 제외하고 대부분의 닷넷 응용 프로그램이 Workstation GC를 사용한다고 했습니다. 실제로 일반 콘솔 프로그램을 만들어 실행한 후 windbg로 확인해 보면,

0:006> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x04e01018
generation 1 starts at 0x04e0100c
generation 2 starts at 0x04e01000
ephemeral segment allocation context: none
 segment     begin  allocated      size
04e00000  04e01000  04e05ff4  0x4ff4(20468)
Large object heap starts at 0x05e01000
 segment     begin  allocated      size
05e00000  05e01000  05e05500  0x4500(17664)
Total Size:              Size: 0x94f4 (38132) bytes.
------------------------------
GC Heap Size:    Size: 0x94f4 (38132) bytes.

위와 같이 GC Heap이 1개만 생성된 것을 볼 수 있습니다. 이 상태에서 app.config에 gcServer 설정을 추가하면,

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7" />
    </startup>

    <runtime>
       <gcServer enabled="true"/>  
    </runtime>

</configuration>

논리 CPU 4개인 PC에서 다음과 같은 결과를 얻을 수 있습니다.

0:011> !eeheap -gc
Number of GC Heaps: 4
------------------------------
Heap 0 (030e3f08)
generation 0 starts at 0x04fc1018
generation 1 starts at 0x04fc100c
generation 2 starts at 0x04fc1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
04fc0000  04fc1000  04fc1024  0x24(36)
Large object heap starts at 0x14fc1000
 segment     begin  allocated      size
14fc0000  14fc1000  14fc5500  0x4500(17664)
Heap Size:       Size: 0x4524 (17700) bytes.
------------------------------
Heap 1 (030e9120)
generation 0 starts at 0x08fc1018
generation 1 starts at 0x08fc100c
generation 2 starts at 0x08fc1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
08fc0000  08fc1000  08fc1024  0x24(36)
Large object heap starts at 0x16fc1000
 segment     begin  allocated      size
16fc0000  16fc1000  16fc1010  0x10(16)
Heap Size:       Size: 0x34 (52) bytes.
------------------------------
Heap 2 (030ee338)
generation 0 starts at 0x0cfc1018
generation 1 starts at 0x0cfc100c
generation 2 starts at 0x0cfc1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
0cfc0000  0cfc1000  0cfc1024  0x24(36)
Large object heap starts at 0x18fc1000
 segment     begin  allocated      size
18fc0000  18fc1000  18fc1010  0x10(16)
Heap Size:       Size: 0x34 (52) bytes.
------------------------------
Heap 3 (030f3550)
generation 0 starts at 0x10fc1018
generation 1 starts at 0x10fc100c
generation 2 starts at 0x10fc1000
ephemeral segment allocation context: none
 segment     begin  allocated      size
10fc0000  10fc1000  10fc5ff4  0x4ff4(20468)
Large object heap starts at 0x1afc1000
 segment     begin  allocated      size
1afc0000  1afc1000  1afc1010  0x10(16)
Heap Size:       Size: 0x5004 (20484) bytes.
------------------------------
GC Heap Size:    Size: 0x9590 (38288) bytes.

보다시피 Heap 0, Heap 1, Heap 2, Heap 3까지 4개의 GC Heap이 생성되었습니다.




하는 김에 스레드 수도 확인해 보겠습니다.

Workstation GC의 경우,

0:006> ~*k

   0  Id: 3da4.1828 Suspend: 1 Teb: 00b06000 Unfrozen
 # ChildEBP RetAddr  
00 00d5ee00 77a7e1f2 ntdll!NtReadFile+0xc
01 00d5ee64 72205947 KERNELBASE!ReadFile+0xe2
02 00d5eed4 72939a13 mscorlib_ni+0x475947
...[생략]...
18 00d5fa8c 00000000 ntdll!_RtlUserThreadStart+0x1b

   1  Id: 3da4.2c8c Suspend: 1 Teb: 00b09000 Unfrozen
 # ChildEBP RetAddr  
00 02fffb60 77c33b16 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 02fffd58 74658654 ntdll!TppWorkerThread+0x296
02 02fffd6c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 02fffdb4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 02fffdc4 00000000 ntdll!_RtlUserThreadStart+0x1b

   2  Id: 3da4.2508 Suspend: 1 Teb: 00b0c000 Unfrozen
...[생략: 1번과 동일]...

   3  Id: 3da4.2d70 Suspend: 1 Teb: 00b0f000 Unfrozen
...[생략: 1번과 동일]...

   4  Id: 3da4.3b0c Suspend: 1 Teb: 00b12000 Unfrozen
 # ChildEBP RetAddr  
00 04dff5bc 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 04dff750 73e2ed0b KERNELBASE!WaitForMultipleObjectsEx+0x103
02 04dff7bc 73e2ec60 clr!DebuggerRCThread::MainLoop+0x99
03 04dff7ec 73e2eb8d clr!DebuggerRCThread::ThreadProc+0xd0
04 04dff818 74658654 clr!DebuggerRCThread::ThreadProcStatic+0xc4
05 04dff82c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
06 04dff874 77c64a47 ntdll!__RtlUserThreadStart+0x2f
07 04dff884 00000000 ntdll!_RtlUserThreadStart+0x1b

   5  Id: 3da4.1d58 Suspend: 1 Teb: 00b15000 Unfrozen
 # ChildEBP RetAddr  
00 06eff378 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 06eff50c 73e881c7 KERNELBASE!WaitForMultipleObjectsEx+0x103
02 06eff53c 73df56ce clr!FinalizerThread::WaitForFinalizerEvent+0x8a
03 06eff56c 73eefdca clr!FinalizerThread::FinalizerThreadWorker+0x5f
04 06eff580 73eefe34 clr!ManagedThreadBase_DispatchInner+0x71
05 06eff624 73eeff01 clr!ManagedThreadBase_DispatchMiddle+0x7e
06 06eff680 73e0ced8 clr!ManagedThreadBase_DispatchOuter+0x5b
07 06eff6a8 73e0cf9f clr!ManagedThreadBase::FinalizerBase+0x33
08 06eff6e4 73d9b601 clr!FinalizerThread::FinalizerThreadStart+0xd4
09 06eff788 74658654 clr!Thread::intermediateThreadProc+0x55
0a 06eff79c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0b 06eff7e4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0c 06eff7f4 00000000 ntdll!_RtlUserThreadStart+0x1b

#  6  Id: 3da4.21dc Suspend: 1 Teb: 00b18000 Unfrozen
 # ChildEBP RetAddr  
00 073cfc38 77caa6c9 ntdll!DbgBreakPoint
01 073cfc68 74658654 ntdll!DbgUiRemoteBreakin+0x39
02 073cfc7c 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 073cfcc4 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 073cfcd4 00000000 ntdll!_RtlUserThreadStart+0x1b

위의 콜 스택 결과로 유추해 다음의 결과를 얻을 수 있습니다.

0번: Main Thread
1번: Thread Pools - Worker Thread
2번: Thread Pools - Worker Thread
3번: Thread Pools - Worker Thread
4번: (windbg로 인한) 디버거 스레드 
5번: Finalizer Thread
6번: (windbg로 인한) 디버거 스레드 

=== 총 7개

Server GC를 사용한 결과도 보면,

0:011> ~*k

   0  Id: 3774.1a9c Suspend: 1 Teb: 00f3c000 Unfrozen
 # ChildEBP RetAddr  
00 00dcf2a0 77a7e1f2 ntdll!NtReadFile+0xc
01 00dcf304 72205947 KERNELBASE!ReadFile+0xe2
...[생략]...
15 00dcfeb8 74658654 MSCOREE!_CorExeMain_Exported+0x8
16 00dcfecc 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
17 00dcff14 77c64a47 ntdll!__RtlUserThreadStart+0x2f
18 00dcff24 00000000 ntdll!_RtlUserThreadStart+0x1b

   1  Id: 3774.4998 Suspend: 1 Teb: 00f3f000 Unfrozen
 # ChildEBP RetAddr  
00 0337f9dc 77c33b16 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 0337fbd4 74658654 ntdll!TppWorkerThread+0x296
02 0337fbe8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 0337fc30 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 0337fc40 00000000 ntdll!_RtlUserThreadStart+0x1b

   2  Id: 3774.1620 Suspend: 1 Teb: 00f42000 Unfrozen
...[생략: 1번과 동일]...

   3  Id: 3774.4484 Suspend: 1 Teb: 00f45000 Unfrozen
 # ChildEBP RetAddr  
...[생략: 1번과 동일]...

   4  Id: 3774.4960 Suspend: 1 Teb: 00f48000 Unfrozen
 # ChildEBP RetAddr  
00 04f8fb84 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 04f8fd18 73e2ed0b KERNELBASE!WaitForMultipleObjectsEx+0x103
02 04f8fd84 73e2ec60 clr!DebuggerRCThread::MainLoop+0x99
03 04f8fdb4 73e2eb8d clr!DebuggerRCThread::ThreadProc+0xd0
04 04f8fde0 74658654 clr!DebuggerRCThread::ThreadProcStatic+0xc4
05 04f8fdf4 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
06 04f8fe3c 77c64a47 ntdll!__RtlUserThreadStart+0x2f
07 04f8fe4c 00000000 ntdll!_RtlUserThreadStart+0x1b

   5  Id: 3774.1db4 Suspend: 1 Teb: 00f4b000 Unfrozen
 # ChildEBP RetAddr  
00 1daafc40 77a7ebe9 ntdll!NtWaitForSingleObject+0xc
01 1daafcb4 73e7008b KERNELBASE!WaitForSingleObjectEx+0x99
02 1daafce4 73e700d2 clr!CLREventWaitHelper2+0x33
03 1daafd34 73e70057 clr!CLREventWaitHelper+0x2a
04 1daafd6c 73e70152 clr!CLREventBase::WaitEx+0x152
05 1daafd84 73df9acf clr!CLREventBase::Wait+0x1a
06 1daafda8 73e3c69e clr!SVR::gc_heap::gc_thread_function+0x4d
07 1daafdc0 73e3c62f clr!SVR::gc_heap::gc_thread_stub+0x72
08 1daafdd4 74658654 clr!GCThreadStub+0x1f
09 1daafde8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0a 1daafe30 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0b 1daafe40 00000000 ntdll!_RtlUserThreadStart+0x1b

   6  Id: 3774.14f8 Suspend: 1 Teb: 00f4e000 Unfrozen
...[생략: 5번과 동일]...

   7  Id: 3774.27a8 Suspend: 1 Teb: 00f51000 Unfrozen
...[생략: 5번과 동일]...

   8  Id: 3774.26f4 Suspend: 1 Teb: 00f54000 Unfrozen
...[생략: 5번과 동일]...

   9  Id: 3774.4830 Suspend: 1 Teb: 00f57000 Unfrozen
 # ChildEBP RetAddr  
00 1de2f728 77a91293 ntdll!NtWaitForMultipleObjects+0xc
01 1de2f8bc 73e881c7 KERNELBASE!WaitForMultipleObjectsEx+0x103
02 1de2f8ec 73df56ce clr!FinalizerThread::WaitForFinalizerEvent+0x8a
03 1de2f91c 73eefdca clr!FinalizerThread::FinalizerThreadWorker+0x5f
04 1de2f930 73eefe34 clr!ManagedThreadBase_DispatchInner+0x71
05 1de2f9d4 73eeff01 clr!ManagedThreadBase_DispatchMiddle+0x7e
06 1de2fa30 73e0ced8 clr!ManagedThreadBase_DispatchOuter+0x5b
07 1de2fa58 73e0cf9f clr!ManagedThreadBase::FinalizerBase+0x33
08 1de2fa94 73d9b601 clr!FinalizerThread::FinalizerThreadStart+0xd4
09 1de2fb2c 74658654 clr!Thread::intermediateThreadProc+0x55
0a 1de2fb40 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0b 1de2fb88 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0c 1de2fb98 00000000 ntdll!_RtlUserThreadStart+0x1b

  10  Id: 3774.3a28 Suspend: 1 Teb: 00f5a000 Unfrozen
 # ChildEBP RetAddr  
00 1df6f5fc 77a7ebe9 ntdll!NtWaitForSingleObject+0xc
01 1df6f670 77a7eb42 KERNELBASE!WaitForSingleObjectEx+0x99
02 1df6f684 73e3d2bc KERNELBASE!WaitForSingleObject+0x12
03 1df6f69c 73e3d282 clr!ProfilingAPIAttachDetach::OverlappedResultHolder::Wait+0x13
04 1df6f6d8 73e3d15c clr!ProfilingAPIAttachServer::ConnectToClient+0x81
05 1df6f70c 73e3d0eb clr!ProfilingAPIAttachServer::ServiceOneClient+0x31
06 1df6f72c 73e3b77c clr!ProfilingAPIAttachServer::ExecutePipeRequests+0x3f
07 1df6f7b0 74658654 clr!ProfilingAPIAttachDetach::ProfilingAPIAttachThreadStart+0x6c
08 1df6f7c4 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
09 1df6f80c 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0a 1df6f81c 00000000 ntdll!_RtlUserThreadStart+0x1b

# 11  Id: 3774.21a8 Suspend: 1 Teb: 00f5d000 Unfrozen
 # ChildEBP RetAddr  
00 1e43fb40 77caa6c9 ntdll!DbgBreakPoint
01 1e43fb70 74658654 ntdll!DbgUiRemoteBreakin+0x39
02 1e43fb84 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
03 1e43fbcc 77c64a47 ntdll!__RtlUserThreadStart+0x2f
04 1e43fbdc 00000000 ntdll!_RtlUserThreadStart+0x1b

결과가 다음과 같이 정리됩니다.

0번: Main Thread
1번: Thread Pools - Worker Thread
2번: Thread Pools - Worker Thread
3번: Thread Pools - Worker Thread
4번: (windbg로 인한) 디버거 스레드 
5번: GC Thread
6번: GC Thread
7번: GC Thread
8번: GC Thread
9번: Finalizer Thread
10번: (이유는 알 수 없지만 아마도 이것도 windbg로 인한 스레드인 듯!)
11번: (windbg로 인한) 디버거 스레드 

=== 총 12개

여기서 재미있는 점이 하나 있는데요, Server GC의 경우 정확하게 4개의 GC dedicated thread가 나왔지만, Workstation GC의 경우 Concurrent GC이므로 역시 전용 GC Thread 하나가 있어야 하는데 없다는 것입니다. 혹시 GC가 발생하는 시점에만 활성화되는 걸까요? 그래서 소스 코드를 다음과 같이 바꿔봤습니다.

using System;
using System.Threading;

namespace ConsoleApp1
{
    class Program
    {
        static volatile bool _loop = true;
        static void Main(string[] args)
        {
            Thread t = new Thread(signalFunc);
            t.Start();

            byte[] buf = null;

            while (_loop == true)
            {
                buf = new byte[1024 * 1024];
            }

            Console.WriteLine("Press ENTER key to exit...");
            Console.ReadLine();
        }

        private static void signalFunc()
        {
            Console.ReadLine();
            _loop = false;
        }
    }
}

할당 루프를 도는 동안 windbg로 붙여 다음의 전용 GC 스레드를 확인할 수 있었습니다.

   6  Id: 49a8.37b0 Suspend: 1 Teb: 004bf000 Unfrozen
 # ChildEBP RetAddr  
00 06dceeb8 73e71544 clr!DecodeGCHdrInfo+0x1d7
01 06dceee4 73e71a1c clr!EECodeManager::GetGSCookieAddr+0x44
02 06dcef00 73e706df clr!StackFrameIterator::PreProcessingForManagedFrames+0x2d
03 06dcef20 73e71734 clr!StackFrameIterator::ProcessCurrentFrame+0x202
04 06dcef60 73e7033f clr!StackFrameIterator::NextRaw+0x4cc
05 06dcf224 73e70411 clr!Thread::StackWalkFramesEx+0xc2
06 06dcf558 73e74d85 clr!Thread::StackWalkFrames+0x9d
07 06dcf590 73ef274f clr!GCToEEInterface::GcScanRoots+0x108
08 06dcf5d0 73ef28b9 clr!WKS::gc_heap::background_mark_phase+0x42d
09 06dcf5f0 73ef20f8 clr!WKS::gc_heap::gc1+0x92
0a 06dcf610 73ef21a8 clr!WKS::gc_heap::bgc_thread_function+0x140
0b 06dcf614 73d9b601 clr!WKS::gc_heap::bgc_thread_stub+0x3c
0c 06dcf7b4 74658654 clr!Thread::intermediateThreadProc+0x55
0d 06dcf7c8 77c64a77 KERNEL32!BaseThreadInitThunk+0x24
0e 06dcf810 77c64a47 ntdll!__RtlUserThreadStart+0x2f
0f 06dcf820 00000000 ntdll!_RtlUserThreadStart+0x1b

하지만 Enter 키를 한번 눌러 할당 루프를 빠져나온 다음 약간의 시간이 지나서 다시 windbg로 확인을 하니 위의 WKS::gc_heap 스레드가 사라졌습니다. 아마도 전용 GC 스레드는 필요할 때만 활성화되고 timeout 시간이 있는 듯합니다.

하나 더 실험을 해서 gcConcurrent 옵션을 false로 설정하면,

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7" />
    </startup>

    <runtime>
        <gcConcurrent enabled="false" />
    </runtime>
        
</configuration>

할당 루프를 도는 동안에도 WKS::gc_heap 콜 스택은 볼 수 없습니다.




참고로 다음의 영상을 보면,

How to identify CLR threads in a dump - 08
; https://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment/How-to-Identify-CLR-threads-in-a-dump-08

.NET 응용 프로그램의 콜 스택에서 다음과 같은 유형의 스레드를 확인할 수 있으며,

  • Worker
  • I/O Completion Port
  • Gate
  • Managed Debugger
  • Timer
  • Finalizer
  • GC (Server GC)

콜 스택에 있는 함수 호출에 따라 다음과 같이 구분할 수 있다고 합니다.

ThreadpoolMgr::CompletionPortThreadStart ==> I/O Completion Port
DebuggerRCThread::ThreadProcStatic ==> Managed Debugger
SVR::gc_heap::gc_thread_function ==> GC Thread
SVR::GCHeap::FinalizerThreadStart ==> Finalizer
ThreadpoolMgr::TimerThreadStart ==> Timer
ThreadpoolMgr::WorkerThreadStart ==> Worker




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]





[최초 등록일: ]
[최종 수정일: 1/20/2018 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 




... 16  17  18  19  20  21  22  23  24  25  26  [27]  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
11512정성태5/3/20182062개발 환경 구성: 375. Azure runbook 실행 시 "Errors", "All Logs"에 오류 메시지가 출력되는 경우
11511정성태5/2/20182254개발 환경 구성: 374. Azure - Runbook 기능 소개
11510정성태4/30/20183911.NET Framework: 742. windbg로 확인하는 Finalizer를 가진 객체의 GC 과정파일 다운로드1
11509정성태4/28/20183421.NET Framework: 741. windbg로 확인하는 객체의 GC 여부
11508정성태4/23/20182627개발 환경 구성: 373. MSBuild를 이용해 프로젝트 배포 후 결과물을 zip 파일로 압축하는 방법파일 다운로드1
11507정성태9/29/20182791개발 환경 구성: 372. MSBuild - 빌드 전/후, 배포 전/후 실행하고 싶은 Task 정의
11506정성태6/27/20185419.NET Framework: 740. C#에서 enum을 boxing 없이 int로 변환하기 - 두 번째 이야기 [7]파일 다운로드1
11505정성태4/19/20182315개발 환경 구성: 371. Azure Web App 확장 예제 - Simple WebSite Extension
11504정성태4/19/20182449오류 유형: 465. Azure Web App 확장 - Extplorer File manager 적용 시 오류
11503정성태4/19/20182416오류 유형: 464. PowerShell - Start-Service 명령 오류 (Service 'xxx' cannot be started)
11502정성태5/12/20183317개발 환경 구성: 370. Azure VM/App Services(Web Apps)에 Let's Encrypt 무료 인증서 적용 방법 [2]
11501정성태4/17/20182261개발 환경 구성: 369. New-AzureRmADServicePrincipal로 생성한 계정의 clientSecret, key 값을 구하는 방법파일 다운로드1
11500정성태4/17/20182535개발 환경 구성: 368. PowerShell로 접근하는 Azure의 Access control 보안과 Azure Active Directory의 계정 관리 서비스
11499정성태4/17/20182102개발 환경 구성: 367. Azure - New-AzureRmADServicePrincipal / New-AzureRmRoleAssignment 명령어
11498정성태4/17/20182135개발 환경 구성: 366. Actvie Azure Directory의 사용자 유형 구분 - Guest/Member
11497정성태4/17/20182323개발 환경 구성: 365. Azure 리소스의 액세스 제어(Access control) 별로 사용자에게 권한을 할당하는 방법 [2]
11496정성태4/17/20181871개발 환경 구성: 364. Azure Portal에서 구독(Subscriptions) 메뉴가 보이지 않는 경우
11495정성태4/18/20182454개발 환경 구성: 363. Azure의 Access control 보안과 Azure Active Directory의 계정 관리 서비스
11494정성태4/16/20182254개발 환경 구성: 362. Azure Web Apps(App Services)에 사용자 DNS를 지정하는 방법
11493정성태4/16/20182250개발 환경 구성: 361. Azure Web App(App Service)의 HTTP/2 프로토콜 지원
11492정성태4/13/20182190개발 환경 구성: 360. Azure Active Directory의 사용자 도메인 지정 방법
11491정성태9/30/20192467개발 환경 구성: 359. Azure 가상 머신에 Web Application을 배포하는 방법
11490정성태4/12/20183092.NET Framework: 739. .NET Framework 4.7.1의 새 기능 - Configuration builders [1]파일 다운로드1
11489정성태4/12/20182289오류 유형: 463. 윈도우 백업 오류 - a Volume Shadow Copy Service operation failed.
11488정성태4/12/20182185오류 유형: 462. Unhandled Exception in Managed Code Snap-in - FX:{811FD892-5EB4-4E73-A147-F1E079E36C4E}
11487정성태4/12/20182344디버깅 기술: 115. windbg - 닷넷 메모리 덤프에서 정적(static) 필드 값을 조사하는 방법
... 16  17  18  19  20  21  22  23  24  25  26  [27]  28  29  30  ...