Home/ Questions/Q 7163109
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T13:50:49+00:00

My WPF .net application seems to leak memory (I also use native and 3rd

  • 0

My WPF .net application seems to leak memory (I also use native and 3rd party components). I took some memory dumps and analyzed those with DebugDiag, WinDBG and VMMap. I’ve seen that the managed heap as well as native heaps and threads are quite stable (on a low level). Then I did an analysis with DebugDiag. It shows that by far the most part is allocated by “Virtual Allocation” (2.5GB: 1.2GB commited and 1.2GB reserved).

VMMap shows me the most of my memory is either “Private Data” or in one dump even “Page Table”… How can I figure out who’s responsible for that??? (I would have expected managed or native heap to grow)

Edit (let me add some additional counters): 

.NET CLR Memory | # Total committed Bytes        357945K  
.NET CLR Memory | # Total reserved Bytes         402554K  
.NET CLR Memory | Large Object Heap size          79182K  
Process | Private Bytes                         1299080K  
Process | Virtual Bytes                         2876524K


-------------------- Usage SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots) Pct(Busy)   Usage
   92d50000 ( 2405696) : 57.36%    83.79%    : RegionUsageIsVAD
   50c11000 ( 1323076) : 31.55%    00.00%    : RegionUsageFree
   12c6c000 (  307632) : 07.33%    10.71%    : RegionUsageImage
    79fe000 (  124920) : 02.98%    04.35%    : RegionUsageStack
          0 (       0) : 00.00%    00.00%    : RegionUsageTeb
     540000 (    5376) : 00.13%    00.19%    : RegionUsageHeap
    1ae5000 (   27540) : 00.66%    00.96%    : RegionUsagePageHeap
          0 (       0) : 00.00%    00.00%    : RegionUsagePeb
          0 (       0) : 00.00%    00.00%    : RegionUsageProcessParametrs
          0 (       0) : 00.00%    00.00%    : RegionUsageEnvironmentBlock
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A few points…

    You have both native and managed code in your app, so try to find out which half is the problem child. Run perfmon with managed and native memory counters to see where the problem is. If both the managed and native counters increase over time, then you have a potential leak. If just the native increases over time, then the native code is to blame.

    I always use these 5 counters:

    • .NET CLR Memory | # Total committed Bytes
    • .NET CLR Memory | # Total reserved Bytes
    • .NET CLR Memory | Large Object Heap size
    • Process | Private Bytes
    • Process | Virtual Bytes

    Also, take note of the Large Object Heap size as well. You can view the contents of those heap(s) in WinDbg also. Finally, while objects on the LOH will get garbage collected over time, the LOH is never compacted, so the LOH is subject to fragmentation over time, which becomes noticeable if you accidentally allocate in the LOH too often.

    EDIT: I’ve never had much luck with VMMap, instead I use perfmon and WinDbg mostly, and DebugDiag sometimes.

    • 0