.NET Memory Profiler is a powerful tool for finding memory leaks and optimizing the memory usage in programs written in C#, VB.NET or any other .NET Language. With the help of the profiling guides, the automatic memory analyzer, and specialized trackers, you can make sure that your program has no memory or resource leaks, and that the memory usage is as optimal as possible.
Find memory leaks
Easily identify memory leaks by collecting and comparing snapshots of .NET memory usage. A profiling guide is available to give you tips on how to detect memory leaks.
Reduce resource usage
Native resources are used in a managed .NET program as well. .NET Memory Profiler will help you make sure that there are no resource leaks and that resources are released as quickly as possible.
Excessive memory and resource usage, excessive allocations, and bad allocation patterns, will negatively affect the performance of your program. .NET Memory Profiler will provide you with the information you need to optimize memory and resource usage.
Investigate memory problems in production code
Investigate memory issues in production code with the free NmpCore tool or by importing memory dumps. The NmpCore tool allows you to profile remote processes and attach to processes on a production machine.
Automate memory testing
Use the .NET Memory Profiler API to automatically detect memory leaks and control the profiler from within the profiled program.
Jun 16, 2017
When we converted the user interface of .NET Memory Profiler from Windows Forms to WPF (for the v5.0 release), we needed to replace the charting component we used for the real-time presentation. [more]
When investigating memory problems reported by a user of .NET Memory Profiler (in our support forum), a resource leak was discovered. [more]
One profiling scenario that is currently not supported by .NET Memory Profiler is SQL Server profiling. If your SQL Server database contains any .NET stored procedures or any other .NET code it can be important to validate the memory usage of the .NET code, especially if any state is kept by the .NET code. [more]
A common question we get about the profiler is how the number presented under the “Other data-><Other>” node in the Native memory tree should be interpreted. This number can often be significant compared to the total memory used by the application. [more]