VirtualAlloc的斷點取決於分配大小

Question

我有一個.Net應用程序（Windows服務），在運行一段時間后會消耗很多非托管內存，直到它被OutOfMemoryException崩潰。 此問題中的更多信息（已刪除;僅限10k用戶）。

我設法創建了一個Supervisor程序來掃描該應用程序的資源消耗，使用VMMap獲取內存常規內存快照，還使用以下命令（格式化為可讀性）在VirtualAlloc()函數中設置斷點：

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

但是WinDBG輸出顯示了一些奇怪的值，我無法跟蹤VMMap顯示的相同分配，因此我認為RDX （ 源 ）是條件斷點上的一個錯誤寄存器。

我需要設置一個正確的斷點來跟蹤非托管內存分配和堆棧跟蹤，最后找到有罪的代碼。

更新：這是具有本機堆棧的斷點的示例輸出。 我認為此處顯示的字節不准確，因為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

Answer 1

在@ThomasWeller評論之后，我猜斷點確實是正確的。

關於內存問題，我已經與微軟的支持聯系，他們確實發現了一大塊內存，但全都是零！ 盡管如此，我還沒有找到這種行為的具體原因。

由於這個問題的主題是關於斷點的准確性，我現在關閉這個話題。