断点的VirtualAlloc取决于分配大小

我有消耗得多非托管内存运行一段时间后，直到它崩溃由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

来源

2017-01-09 Vinícius Oliveira

是什么让你觉得VirtualAlloc（）是一个非托管的内存分配？ –

大小是[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） –

你可以尝试ETW跟踪的VirtualAlloc：HTTPS：/ /channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-154-Memory-Footprint-and-Leaks在16:57观看视频。这应该比Windbg堆栈更容易分析。 –

@ThomasWeller发表评论后，我猜测断点确实是正确的。

关于内存的问题，我已经和微软支持接触，他们真的找到的内存块，但全部为零！尽管如此，我还没有找到这种行为的具体原因。

由于这一问题的主要议题是关于断点的准确性，我现在结束这个话题。

来源

2017-01-19 19:50:41

断点的VirtualAlloc取决于分配大小

回答

相关问题