• Instance graph
  Get a visual overview of how a managed instance is being used,
  how it is related to other instances, and, maybe most importantly,
  how roots are preventing it from being garbage collected.
• Instance and allocation filters
  The new filters provide you with information about instances and allocations that share a common
  characteristic, e.g. all allocations and instances that are derived from a specific type, all
  instances that are directly referenced by a root, all boxed instances,
  or all allocations performed by a specific method.
• Guided profiling
  The profiler guides provide interactive step-by-step instructions that will help you with common memory profiling tasks, such as memory leak investigations.

This is just a few of the new features and improvements. For more information, please visit the .NET Memory Profiler website.

If you are using or evaluating .NET Memory Profiler, I highly recommend that you download this beta; it has been pretty thoroughly tested and there are no significant known problems. If you have a current license of .NET Memory Profiler 3.x, you can use your registration key for the  4.0 beta as well. If you purchase .NET Memory Profiler 3.5 today (or if you have purchased v3.5 on or after September 27th, 2010), you will get a free upgrade to version 4.0 as soon as it is released.

We’re currently updating the documentation and finalizing the new licensing system. As soon as this is finished and, of course, when we have fixed any reported errors, we will release the final version of .NET Memory Profiler 4.0. Hopefully it will not take too long. It has taken much longer to develop the new version than we originally planned, but on the other hand, there are also  many new features and improvements that were  not included in our original plan. I hope you will like this new version an find the new features useful.

Even though version 4.0 is still missing a few major features, this preview has been pretty thouroughly tested and is probably stable enough for most users.  If you are evaluating .NET Memory Profiler, I highly recommend that you try the new version instead of the official 3.5 version. There are several reasons for trying the new version:

• The new instance graph makes it much easier to investigate how an instance is being used and what’s preventing it from being garbage collected.
• The instance tracker (which, for instance, keeps track of the allocation call stacks of specific instances), has a new implementation. This has reduced the memory usage and improved the performance of the profiler. The new profiling levels also makes it easier to strike a balance between performance/memory usage and the amount of information presented.
• Support for Silverlight profiling has been improved, making it much easier to profiler Silverlight application (version 3.5 doesn’t actually include a “Profile Silverlight” option, even though it is possible to manually profile Silverlight applications).
• DependencyProperty evaluation makes it much easier to see relationships between DependencyObjects in a WPF application (Silverlight DependencyProperty evaluation is coming soon).
• Attaching the profiler to a running process is much faster and more stable, by using the new API provided by .NET Framework 4.0.
• The upgrade to version 4.0 is free of charge for anyone who has purchased .NET Memory Profiler 3.5 on or after September 27th, 2010.

As the SQL Server is running as a Windows service, the Profile service command should be used, as described below:

1. Start .NET Memory Profiler as an adminstrator (e.g. right click and select “Run as administrator”)
2. Select Profile Service
3. Find the correct SQL Server service
4. Start profiling
5. The SQL Server service will be restarted and you will see the message “Waiting for profiled process to start”.
6. Make sure that the .NET runtime is loaded into the process, e.g. by executing a stored procedure. This should cause the message to disappear and the profiling to start.

Unfortunately, this will not work! You will soon receive an error message stating:

System.IO.FileNotFoundException: Could not load file or assembly ‘SciTech.NetMemProfiler.InstrumentationHelper2, Version=3.1.0.0, Culture=neutral, PublicKeyToken=2dc3dfad160eda83′ or one of its dependencies. The system cannot find the file specified. 

The problem is that the dispose tracker (which is usually enabled) requires a helper assembly. This assembly is installed in the GAC, but SQL Server will not load this assembly. The solution is to add the helper assembly to the database. But there’s one more gotcha. The helper assembly performs native functions calls, and thus requires unrestricted permissions, i.e. it must be added with PERMISSION_SET = UNSAFE. In order to do this, the database needs to be marked as “Trustworthy” (which is not recommended), or a database login with UNSAFE ASSEMBLY rights must be created for the helper assembly. The login can be created using the following SQL script:

USE master
GO
IF NOT EXISTS (SELECT name FROM master.sys.asymmetric_keys WHERE name = 'MemProfilerInstrumentationKey')
begin
  CREATE ASYMMETRIC KEY MemProfilerInstrumentationKey
    FROM EXECUTABLE FILE = 'C:Program filesSciTechNetMemProfiler3AssembliesSciTech.NetMemProfiler.InstrumentationHelper2.dll'
  CREATE LOGIN MemProfilerInstrumentationLogin
    FROM ASYMMETRIC KEY MemProfilerInstrumentationKey
  GRANT UNSAFE ASSEMBLY TO MemProfilerInstrumentationLogin
end 

After the login has been created, the assembly can be added with unrestricted permissions. It must be added to each database that includes .NET code that will be profiled, using the SQL script below.

USE [<Database name>]
CREATE ASSEMBLY [SciTech.NetMemProfiler.InstrumentationHelper2]
  FROM 'C:Program filesSciTechNetMemProfiler3AssembliesSciTech.NetMemProfiler.InstrumentationHelper2.dll'
  WITH PERMISSION_SET = UNSAFE;

 Now it should be possible to profile .NET code hosted by SQL Server. Just follow the steps from the beginning of this post.

Once you have finished profiling, the permissions granted to the profiler can be removed by dropping the assembly, login, and asymmetric key:

USE [<Database name>]
DROP ASSEMBLY [SciTech.NetMemProfiler.InstrumentationHelper2]
GO
USE master
DROP LOGIN MemProfilerInstrumentationLogin
DROP ASYMMETRIC KEY MemProfilerInstrumentationKey

Admittedly these requirements make it a bit cumbersome to profile SQL Server hosted .NET code. The next version of the profiler will include an option to “Profile SQL Server”, which will automatically prepare the database for profiling.

Thanks to Gerhard Obenaus at Blackbaud, Inc. for pointing out how to create a login for the helper assembly, instead of using the “Trustworthy” alternative.

The latest release can be downloaded from the Download page, and more information about the release is available in the release notes.

I discovered this leak almost a year ago as I investigated memory problems reported by a user (in our support forum). To illustrate the leak, I have created a very simple Windows Forms application, with a form that contains a single button. In the Click handler of the button,  a number of TreeViews are created and the Checkboxes are enabled. They are added to the form, just to make sure that they will be fully initialized and then immediately disposed.

private void button1_Click( object sender, EventArgs e )
{
   for( int i = 0; i < 100; i++ )
   {
      using( TreeView treeView = new TreeView() )
      {
         this.Controls.Add( treeView );
         treeView.CheckBoxes = true;
      }
   }
}

This should not cause any left over instances; neither managed memory instances nor unmanaged resource instances. But when testing this under the profiler, the following results can be seen (after collecting a snapshot before and after a button click).

There are 200 new HBITMAPs and HDCs, and 100 new HIMAGELISTs! Considering that we created 100 TreeViews, it seems very likely that the new resource instances are related to them. Let’s investigate one of the resource further, for example the HBITMAPs. The allocation call stacks of the bitmaps provide the following information:

Thanks to the improved native stacks in .NET Memory Profiler 3.5, you can easily see that the HBITMAP is created as part of an ImageList, when initializing the checkboxes in the native TreeView (TV_InitCheckBoxes). So setting the CheckBoxes property to true, caused the HBITMAP to be created, but why is it not released? At first I suspected that there was actually a resource leak in the native Win32 TreeView implementation, but when checking the documentation, I found this:

Once a tree-view control is created with this style, the style cannot be removed. Instead, you must destroy the control and create a new one in its place. Destroying the tree-view control does not destroy the check box state image list. You must destroy it explicitly. Get the handle to the state image list by sending the tree-view control a TVM_GETIMAGELIST message. Then destroy the image list with ImageList_Destroy.

Apparantly, it’s the responsibility of the user of the native TreeView (e.g. the .NET TreeView control) to release the image list. I find this a bit odd since this image list is created as a side-effect of the internal implementation of the check boxes. Anyway, it seems like the .NET TreeView control fails to release the image list. To fix this leak, the image-list must be explicility released. The ReleaseCheckBoxImageList method below shows an example on how this can be done.

static class TreeViewHelper
{
   ///
   /// Releases the checkbox image list in the
   /// specified TreeView.
   ///
   internal static void ReleaseCheckBoxImageList(TreeView treeView)
   {
      if( treeView.IsHandleCreated )
      {
         int style = GetWindowLong( treeView.Handle, GWL_STYLE );

         if( (style & TVS_CHECKBOXES) != 0 )
         {
            // Checkboxes were enabled in the
            // tree view. Let's destroy the
            // image list.
            IntPtr hStateImageList = SendMessage(
               treeView.Handle,
               TVM_GETIMAGELIST,
               (IntPtr)TVSIL_STATE,
               IntPtr.Zero );

            if( hStateImageList != IntPtr.Zero )
            {
               ImageList_Destroy( hStateImageList );
            }
         }
      }
   }

   #region Windows interop

   const int TV_FIRST = 0x1100;
   const int TVM_GETIMAGELIST = (TV_FIRST + 8);
   const int TVSIL_STATE = 2;
   const int TVS_CHECKBOXES = 0x0100;

   const int GWL_STYLE = (-16);

   [DllImport( "User32" )]
   static extern IntPtr SendMessage(
      IntPtr hWnd, int Msg,
      IntPtr wParam, IntPtr lParam);

   [DllImport( "User32" )]
   static extern int GetWindowLong(
      IntPtr hWnd, int nIndex);

   [DllImport( "comctl32" )]
   [return: MarshalAs( UnmanagedType.Bool )]
   static extern bool ImageList_Destroy(IntPtr himl);

   #endregion
}

This method should be called when the image list will no longer be needed, for instance when the window handle is destroyed. The FixedTreeView class below shows how this can be implemented:

///
/// A TreeView that properly releases
/// native Win32 resources.
///
class FixedTreeView : TreeView
{
   ///
   /// Overridden to make sure that the native
   /// checkbox image list is properly released.
   ///
   protected override void OnHandleDestroyed(EventArgs e)
   {
      TreeViewHelper.ReleaseCheckBoxImageList( this );

      base.OnHandleDestroyed( e );
   }
}

By using the FixedTreeView instead of the standard TreeView, the test program no longer has a resource leak (or memory leak).

As you can see, this fixed the resource leak of HBITMAPs, HIMAGELISTs, HDCs, and even the HeapAlloced memory.

An additional bonus is that this fix will also handle the case where the CheckBoxes property is toggled.  When the CheckBoxes property is set to false, the image list should also be released. Thanks to the fact that the native TreeView must be recreated whenever the checkbox style is updated, the handle will be destroyed when the CheckBoxes property is changed and the fix will executed (“Once a tree-view control is created with this style, the style cannot be removed. Instead, you must destroy the control and create a new one in its place”).

The code in the forum post mentioned in the beginning didn’t handle this correctly, since it used the CheckBoxes property to decide if the image list should be released. This property don’t reflect the whether checkboxes were included in the control being destroyed. Therefore the TVS_CHECKBOXES style is checked instead, as that will handle setting CheckBoxes to false as well.

A beta of .NET Memory Profiler 3.5 will soon be released, but in the meantime you can test the improved native call stacks by downloading the .NET Memory Profiler 3.5 preview.