Breakpoint for VirtualAlloc that depends on allocation size

Question

I have a .Net application (Windows Service) that consumes to much unmanaged memory after some time running until it crashes by an OutOfMemoryException. More info in this question (deleted; 10k users only).

I've managed to create a Supervisor program to scan that application's resource consumption, take memory regular memory snapshots with VMMap, and also sets a breakpoint at the VirtualAlloc() function by using the following command (formatted for readability):

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

But the WinDBG output shows some weird values and I'm not able to track the same allocations shown by VMMap, so I think RDX (source) is one wrong register on the conditional breakpoint.

I need to set a correct breakpoint to track that unmanaged memory allocation and the stacktrace and finally find the guilty code.

UPDATE: This an example output of the breakpoint with the native stack. I consider the bytes shown here inaccurate because VMMap does not show any allocation of that size (3.6GB). One curious thing is that, that byte value is shown on the second to last stack frame, as argument to clr!CExecutionEngine::ClrVirtualAlloc (see the d8040000 value).

============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

After @ThomasWeller comment, I guess the breakpoint is indeed correct.

About the memory problem, I've made contact with Microsoft support and they do find a chunk of memory, but was all zeros! Still, I haven't found the specific cause for that behavior.

Since the main subject of this question was about the breakpoint accuracy, I'm now closing this topic.