2017-01-09 8 views
0

OutOfMemoryException에 의해 충돌 할 때까지 관리되지 않는 메모리를 많이 소비하는 .Net 응용 프로그램 (Windows 서비스)이 있습니다. this question (삭제, 10k 사용자 전용)에 대한 자세한 정보.할당 크기에 따라 달라지는 VirtualAlloc의 중단 점

내가, 해당 응용 프로그램의 자원 소비를 스캔 감독자 프로그램을 만들 VMMap와 메모리를 정기적으로 메모리 스냅 샷을 관리하고, 또한 다음 명령을 사용하여 VirtualAlloc() 기능에 중단 점을 설정 한 (읽기 쉽도록 포맷) :

bp KERNELBASE!VirtualAlloc ".if (@rdx>=0x2FAF080) { 
    .printf \"============Allocating %lu bytes ================\n\", @rdx; 
    kb 8; !clrstack; gc 
} .else{gc}" 

는 그러나 WinDBG에서 출력은 몇 가지 이상한 값을 보여줍니다 나는 VMMap로 표시 같은 할당을 추적 할 수없는, 그래서 나는 RDX (source가) 조건부 중단 점 하나 개 잘못 레지스터 생각합니다.

올바른 중단 점을 설정하여 관리되지 않는 메모리 할당과 스택 추적을 추적하고 최종적으로 유죄 코드를 찾아야합니다.

업데이트 : 다음은 네이티브 스택과 함께 중단 점의 출력 예입니다. VMMap에서 해당 크기 (3.6GB) 할당을 표시하지 않기 때문에 여기에 표시된 바이트가 부정확하다고 생각합니다. 흥미로운 점은, 두 번째에서 마지막 스택 프레임에 바이트 값이 clr!CExecutionEngine::ClrVirtualAlloc의 인수로 표시된다는 것입니다 (d8040000 값 참조).

============Allocating 3624140800 bytes ================ 
RetAddr   : Args to Child               : Call Site 
00007ffe`5844395a : 00000001`111bf000 00000000`d2cb8000 00000000`00a229da 00000000`5ff17000 : KERNELBASE!VirtualAlloc 
00007ffe`584adf14 : 00000000`00000004 00000000`00000000 00000000`d8040000 00000051`000fcbf0 : clr!CExecutionEngine::ClrVirtualAlloc+0x4a 
00007ffe`589da6c7 : 00000000`00000000 00000000`00100000 00000051`80490000 00000051`000fcbf0 : clr!ClrVirtualAlloc+0x3c 
00007ffe`589da270 : 00000000`00000000 00000051`000fcdc8 00000051`80490000 00000000`0006e120 : clr!WKS::gc_heap::grow_brick_card_tables+0x177 
00007ffe`589d9ee4 : 00000000`08000000 00000000`00000023 00000000`00000000 ffffffff`fffffff8 : clr!WKS::gc_heap::get_segment+0x140 
00007ffe`589dae9e : 00000000`08000000 00000000`00000000 00000051`000fcde0 00000051`000fcdb0 : clr!WKS::gc_heap::get_large_segment+0x204 
00007ffe`58829226 : 00000000`0000000c 00000000`00000000 00000000`00000000 00000000`00000000 : clr!WKS::gc_heap::loh_get_new_seg+0x5e 
00007ffe`585313b1 : 0000fffc`00000003 00000000`00000003 00000000`00000003 00000000`0006e138 : clr!WKS::gc_heap::allocate_large+0x2f8156 
+0

VirtualAlloc()이 관리되지 않는 메모리 할당이라고 생각합니까? –

+1

크기는 [VirtualAlloc] (https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887 (v ​​= vs.85) .aspx)의 두 번째 매개 변수이므로 RDX가 올바르게 표시됩니다. "이상한"가치 란 무엇입니까? 참고 : [VirtualAllocEx] (https://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx) –

+0

ETW VirtualAlloc 추적을 시도 할 수도 있습니다. https ://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-154-Memory-Footprint-and-Leaks 16:57의 비디오를 참조하십시오. Windbg 스택보다 분석이 훨씬 쉬워야합니다. –

답변

0

@ThomasWeller 의견 뒤에, 나는 중단 점이 실제로 맞았다 고 생각합니다.

메모리 문제에 대해서는 Microsoft 지원 팀에 문의했으며 메모리 조각을 찾았지만 모두 0입니다! 그래도 그 행동에 대한 구체적인 원인을 찾지 못했습니다.

이 질문의 주된 주제는 중단 점 정확도에 관한 것이므로이 주제를 닫습니다.