4

我有一个 .Net 应用程序（Windows 服务），它在运行一段时间后消耗大量非托管内存，直到它崩溃OutOfMemoryException。此问题中的更多信息（已删除；仅限 10k 用户）。

我设法创建了一个主管程序来扫描该应用程序的资源消耗，使用 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
4

1 回答 1

0

在@ThomasWeller 评论之后，我猜断点确实是正确的。

关于内存问题，我已经联系了 Microsoft 支持，他们确实找到了一大块内存，但都是零！不过，我还没有找到导致这种行为的具体原因。

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

于 2017-01-19T19:50:41.177 回答