Точка останова для 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,6 ГБ). Любопытно, что это значение байта показывается во втором и последнем кадре стека в качестве аргумента 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, я думаю, точка останова действительно правильная.

Что касается проблемы с памятью, я связался со службой поддержки Microsoft, и они действительно нашли кусок памяти, но были все нули! Тем не менее, я не нашел конкретной причины для такого поведения.

Поскольку основной темой этого вопроса была точность определения точки останова, сейчас я закрываю эту тему.