This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 6%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EP%3C/text%3E%3C/svg%3E)
I'm analyzing memory overhead of my C++ application. I collected a Memory Usage snapshot using Visual Studio 2019 Performance Profiler. However the snapshots contain only ~20% of memory of what is reported as Private Bytes in Diagnostics tab (or Process Explorer app).
I suspect some of the unaccounted memory is stack based memory which the heap captures wouldn't cover but I'd expect its size to be miniscule amount in comparison to heap right? The system has plenty of free RAM left (100+ GB), so I don't expect 80% of Private Bytes being in pagefile, in case the Memory Usage snapshot wouldn't capture that? Any suggestions how to understand where all the memory is (i.e. how much of it is stack based memory, etc) and or how to get a capture of it all with corresponding stacks?
For example I collected two snapshot of my app with two different memory usage amounts:
Left (1), Right (2)
Windows Performance Recorder trace with Heap + VirtualAlloc option gives a trace with stacks for all the memory and solves my issue. I haven't found an explanation why VS Performance Profiler Memory Usage is missing 80% of data, but maybe something to fix in VS traces or at least give an option to do the same as WPR provides?
Snapshot of etl trace from WPR with all the memory associated with a stack
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(140.8, 78%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETS%3C/text%3E%3C/svg%3E)
Hi @Peter ,
Welcome to Microsoft Q&A forum.
Please kindly refer to this similar thread: Snapshot memory vs process memory.
The Process Memory is the memory consumption of your entire project. When the project start debugging, besides the code, it also invoke other tools in VS. All of them will consume memory.
The Snapshot memory used to help us check the specific objects that consume a large number of memory … It could help us filter the view to see what changed between the two in terms of objects and heap size. In other words, Snapshot memory only collect the Object that used in your code objects.
Other related documents for you to refer to:
Best Regards,
Tianyu
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 33%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDW%3C/text%3E%3C/svg%3E)
I'm having similar issues, but that article didn't help.
In my case, the application is C#. When I run my program under the memory profiler, the Process memory steadily increases. There's an event that fires off every 5 seconds and I can tell that something about that event is causing the increase. Definitely not Visual Studio overhead.
But I take shapshots at the beginning and again about 10 minutes later and the snapshots claim managed heap has actually decreased a bit in size and number of objects.
I suspect something unmanaged not getting disposed but I don't know what.
I had found a problem earlier where a Bitmap and a Font weren't getting disposed.
Those showed up in the object lists of the snapshots, and made it easy to find what was getting missed and put using statements around them.
But whatever this is isn't showing up.
We need some way to track unmanaged heap. Of course, the very fact that it's unmanaged is probably why that's hard to do.
Thank you for sharing the links. However, it doesn't explain the missing memory in the snapshot in my case. I see similar Private Bytes numbers for the application even through Process Explorer (as pointed out in my original post) and running the app from a cmdline and not under VS debugger, so the memory not captured is not VS overhead. Well at least not the major part of it (i.e. unnacounted 9 GB in the 2 GB snapshot vs 11 GB Private Bytes of the app).
Here's a process explorer view for the 11 GB scenario captured above
Looking at properties of the process in Process Explorer the Working Set Private numbers are closer to what the snapshot captured, but still quite a bit far off. 4.3GB vs 2 GB
Disabling page-file gets WS Private #s jump to Private Bytes #s during capture, but the capture itself is still as it was before. That is good it doesn't affect the capture.
