What′s New in dotMemory

We've reintroduced the Creation Stack Trace view, which had previously been removed during the UI redesign. This view shows the function call stack that led to the creation of an object, helping you identify the root cause of memory issues more easily.

We’ve also reimplemented the Back Traces view for object sets. This inverted call tree in the view shows the call chain starting from the function that created a particular set of objects, moving from the bottom to the top.

The dominator tree can now be displayed as an icicle chart, showing the memory consumption of the dominator and the retained objects. This feature is available on Windows, Linux, and macOS for both the standalone version of dotMemory and dotMemory in JetBrains Rider.

The ability to visualize a Call Tree as a sunburst chart, which was introduced in version 2024.2, is now available on Windows, Linux, and macOS for both the standalone version of dotMemory and dotMemory in JetBrains Rider.

We’ve added new filtering options to the Instancesview:

• Search by string value: Type any string value into the filter field, and dotMemory will highlight matching strings. This makes it easier to find specific string instances based on their content.
• Regex support for string values: Use regular expressions for more advanced searches. For example, ^nAsso.{5,}ID$ matches nAssociatedObjectID.nAssociatedObjectID.
• Search by object address: You can also search for object instances by their memory address. This is useful for tracking specific objects directly.

These features are available in the standalone version of dotMemory and dotMemory in JetBrains Rider.

The dotMemory version for Linux and macOS gets features that were previously available only on Windows:

• Automatic memory inspections: dotMemory for Linux and macOS gets the Inspections view, which shows several automatically detected memory issues.
• Cross-workspace snapshot comparison: Now, you can compare snapshots from different profiling sessions.

These features are available in the standalone version of dotMemory and dotMemory in JetBrains Rider.

The Call Tree can now be displayed as a Sunburst chart, highlighting functions that allocate the most memory. The feature is available in the standalone version of dotMemory (Linux and macOS) and dotMemory in JetBrains Rider (Windows, Linux, and macOS).

Now, you can profile applications based on the MAUI framework.

Currently, dotMemory supports profiling of WinUI applications targeting .NET 7.0+ on Windows.

The support is available for dotMemory standalone and dotMemory integrated into Rider and ReSharper.

• Now, the standalone version of dotMemory lets you specify application bundles (.app) instead of executable files.
• dotMemory in Rider can profile macOS run configurations. The following target frameworks are supported: net7.0-macos, net8.0-macos.

The standalone version of dotMemory on Linux and macOS gets closer to its Windows counterpart, offering:

• The Similar Retention view for analyzing object sets
• The Sunburst diagram for analyzing dominator objects

The information about immutable objects in the Frozen Object Heap is shown on the timeline, the Heap Fragmentation diagram, and the Generations view.

Now, you can run the standalone version of dotMemory on Linux and macOS operating systems.

Before 2023.2, you could only use dotMemory in Rider for memory allocation analysis. In 2023.2, you can collect memory snapshots and analyze them in Rider, just like in the standalone version of dotMemory.

• Snapshot analysis is available on Windows, Linux, and macOS.
• On Windows, you can also import and analyze process dumps.
• Some features and views are not available, e.g., automatic snapshot inspections and creation stack trace views.

In addition to Windows, dotMemory is now available for JetBrains Rider on Linux and macOS. Two new profiling modes are available in the Run widget and in the Run | Switch profiler configuration menu – Memory (sampled allocations) and Memory (full allocations). You can learn more about the differences between these in dotMemory’s Help.

You can attach the profiler to a running process from the Run menu and watch the Timeline Graph unroll in real time. Select an interval to open the Memory Allocations view, which is the same as in dotMemory Standalone. It lets you analyze allocated objects and the allocation call tree for a specific time frame.

Unfortunately, it is not yet possible to collect memory snapshots in this version.

dotMemory is now available right in JetBrains Rider:

• Two new profiling modes are available in the Run widget and Run | Switch profiler configurations in the main menu – Memory (sampled allocations) and Memory (full allocations). You can learn more about the difference between these in the dotMemory Help.
• You can attach the profiler to a running process from the Run menu.
• Watch the Timeline Graph unfold in real-time by selecting an interval and opening the Memory Allocation view. It is equivalent to the same view in dotMemory Standalone and allows you to dig deeper into the analysis of a specific time frame.

The dotMemory plugin doesn’t allow collecting snapshots and only works on Windows in the 2022.2 release.

You can now attach the profiler to an already running application by simply dragging the special icon onto the application window.

dotMemory can now get sampled data about memory allocation based on ETW events. Compared to the traditional (statistical) way of collecting allocation data, sampling is less accurate but provides a number of advantages:

• The sampled allocation data is collected without performance penalties.
• You don’t need to enable this data collection explicitly; it is always active.
• Sampled allocation data can also be collected when you attach the profiler to an application that is already running.

Note that this feature is available only on Windows.

You can now use the Subsystems view to analyze memory allocation data. A subsystem groups all methods belonging to the same type, namespace, or assembly. The resulting view displays objects created by the subsystems and a merged call tree for each subsystem.

In this release, we have continued to improve the way you analyze memory allocation. Two new tabs have been added to the Memory Allocation view:

• The Methods tab lets you analyze a plain list of methods that have allocated memory.
• The Call Tree tab lets you analyze the allocation call tree. Each node in the tree shows not only the called method but also the objects allocated by the call.

The search bar at the top of dotMemory views is now more flexible and easier to use:

• The filters have additional options for narrowing the search scope: #struct (search only in value types), #c (only in types), #m (only in methods), #ns (only in namespaces).
• You can get help for all filters possible in a given context.

It’s now possible to:

• Specify the traversal depth when exporting object data.
• Select one or more types and export their data to a single file.
• Export object data from the Instances, Outgoing References, and Unreachable Objects views.

We’ve completely reworked the dotMemory Home screen – it is much easier to configure and start new profiling sessions, work with snapshots, and perform other basic operations.

Now, you can analyze dumps of .NET Core applications collected on the Linux systems using gcore.

Now, dotMemory lets you analyze memory allocation on an arbitrary time interval. Just select the interval on the timeline and the Memory Allocation view will show you the objects allocated on this interval, as well as the stack trace that allocated them.