I'm trying to locate source of native bytes leaked from .Net application.
I've succeeded to collect snapshots using nmpCore.exe with /rt, but when comparing the snapshots in .Net Memory Profiler, most of the native bytes difference between the snapshots is under 'Other Data'.
Is there anything I can do differently to locate those native bytes?
The resource tracker is not activated in the profiled process until the .NET runtime is loaded into the process. So if the native bytes are allocated before the runtime is loaded, the profiler will not be able to identify them (this is something we plan to improve in the next version).
The NmpCore tool is not well suited for collecting native resource information, since it is not possible to specify symbol file locations when using NmpCore. Without symbol files information, the call stacks of the resources will be much less detailed.
When looking into this, I noticed that the native resource tracker could cause the profiled process to dead-lock. Apparently the loader-lock synchronization in Windows has been modified, probably in a recent update. The modification could cause the native resource tracker to dead-lock. We have now fixed this and built a new release of .NET Memory Profiler. We will soon release it officially, but you can download it now using the link below:
https://cdn.memprofiler.com/download/Me ... 5_6_30.exe
SciTech Software AB
Indeed I encountered the dead-lock and the process did not start in the previous version of .NET Memory Profiler, that's why I used nmpCore.
With the new version I can see the identified resources.
Users browsing this forum: Bing [Bot] and 10 guests