Memory Leaks In .NET Application Using Dump File

I will be demonstrating this in multiple steps which include identification of memory leaks and then moving into the details of how to find those references which are not released by using the dump file.

In step 1, I will create a .NET console application to have logic which has memory leaks and then will identify via 'performance monitor' a default Windows tool to detect and finally, I'll use a dump file to find out all the unrelased references.

Here is a code snippet of the application "memoryleakdemo' which has memory leaks. It opens 10K instances of file stream but none is disposed of.

class Program
{
static void Main(string[] args)
{
IList<Company<Employee>> companies = new List<Company<Employee>>();
var location = new Uri(Assembly.GetEntryAssembly().CodeBase).LocalPath;
var path = Path.GetDirectoryName(location);
var filePath = args.Any() ? args[0] : Path.Combine(path, "Resource\\Companydata.txt");
var mainStream = new StreamWriter(filePath);
var i = 0;
// 1. memory leak : Create steam for each company but not disposed.
// 2. event subscribed not released.
while (i++ <= 10000)
{
foreach (var item in new List<string> { "DX Generation", "Nxt", "Dudley Boyz" })
{
var company = new Company<Employee>(item);
company.OnNewJoinne += e =>
{
CompanyOnNewJoinne(e, mainStream);
};
foreach (var item1 in new List<string> { "employe1", "employe2" })
{
company.AddNewEmployee(item1);
}
companies.Add(company);
}
}
mainStream.Dispose();
Console.ReadKey();
}
private static void CompanyOnNewJoinne(EmployeeJoinedEventArgs e, StreamWriter stream)
{
Console.WriteLine($"{e.EmployeeName} employee Joined {e.EmployerName}");
stream.WriteLine($"{e.EmployeeName} employee Joined {e.EmployerName}");
}
}
public class Company<T> where T : Employee
{
public delegate void EmployeJoined(EmployeeJoinedEventArgs name);
public event EmployeJoined OnNewJoinne;
public string Name { get; private set; }
public StreamWriter FileStream { get; private set; }
private readonly IList<T> employee = new List<T>();
public Company(string name)
{
this.Name = name;
var location = new Uri(Assembly.GetEntryAssembly().CodeBase).LocalPath;
var path = Path.GetDirectoryName(location);
// each object have fileStream but no dispose.
// you can fix it via Idispose implementation to dispose FileStream
this.FileStream = File.CreateText(Path.Combine(path, Path.GetRandomFileName() + ".txt"));
}
public bool AddNewEmployee(string name)
{
if(employee.FirstOrDefault(s => s.Name == name) != null)
{
return false;
}
employee.Add((T)Activator.CreateInstance(typeof(T), name));
// Write in local stream.
FileStream.WriteLine($"{name} employee Joined {this.Name}");
// write in main stream.
OnNewJoinne?.Invoke(new EmployeeJoinedEventArgs(this.Name, name));
return true;
}
}
public class Employee
{
public string Name { get; private set; }
public Employee(string name)
{
this.Name = name;
}
}
public class EmployeeJoinedEventArgs : EventArgs
{
public EmployeeJoinedEventArgs(string companyName, string employeeName)
{
EmployerName = companyName;
EmployeeName = employeeName;
}
public string EmployerName { get; private set; }
public string EmployeeName { get; private set; }
}

You could notice that each company object has filestream object but it's not disposed of, that is, one produces a memory leak.

Let's move to the second step to confirm whether this application really has any memory leaks or not using the default 'performance monitor' tool that comes free with Windows. There are many tools available in the market to analyze memory leaks, you can also use the VS performance profiler which also gives to memory allocation, CPU sampling, etc.

Type 'performance monitor' on Windows search and open this tool. Select performance monitor and add a new counter for this application to analyze gen0, gen1, & gen2 object and once the execution is over, check if the memory/object in different generations is reduced or not.

If you notice Gen1 or Gen2 size increasing consistently or Gen0 and gen1 are not reduced even after the execution is over, as shown in the picture, this is self-explanatory that the application has memory leaks. GC automatically does the job for collecting managed object automatically and disposing of it if it is not referenced by any root.

Let's move to the final and main step of this article, i.e., finding out references that are not released; and with their roots using dump file and opening that dump file in Visual Studio to debug it.

Go to your task manager and find this application via the name and right-click on it to select 'Create dump file'. Your dump file will be created in a temp folder. Copy that path and open in Visual Studio.

Open VS and select 'Open file' and use the same dump file path to open the file. As this application is only managing managed memory, hence we can select the option 'debug Managed memory'. If you are using any third party DLLs etc., then you can use the symbol option to add those symbols to load during debug time. Verify your application path and process the name and finally, click on 'debug managed memory' to check all object types which are not released with their roots.

You should see a screen like below which shows all the object type references with a number of hits with their roots. Using this approach, you can find all objects whose references are still not released using the VS IDE.

You could see the streamwriter's reference count which is holed by Company root object under Path to Root tab. You could find this approach a very easy and fast way to detect memory leak in a .NET application.

To fix this memory leak for stream writer objects, you can implement the IDisposable pattern to dispose of all unmanaged objects. Do not forget another instance of leak i.e. unsubscribe event company.OnNewJoinne -=........ it was also mentioned in a code comment.

public class Company<T> : IDisposable where T : Employee
{
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (disposed)
{
return;
}
if (disposing)
{
FileStream?.Dispose();
}
disposed = true;
}
}

Ideally, we should never have a memory leak in our application but sometimes you never know how these third party APIs behave. Or sometimes, we do not know how to consume those APIs in the right way which ends up in memory leak.

I hope you liked this blog which can be useful for your .net application to find out memory leak if any.

6 Comments

Join the conversation! Your thoughts help the community grow.

Abhay Deshpande7y ago
Nice article
Mahesh Chand7y ago
Thank you, Ashutosh. Appreciate your detailed work.
- Ashutosh Gupta7y ago
  Thanks manish
- Mahesh Chand7y ago
  Sorry about that. Can you try resetting your password? Our IP address was blocked and now it should be working just fine.
- Blocked Account7y ago
  Hi Ashutosh, We have unlocked your account and sent you an email in your registered email Id. Thanks.
Sourav Kumar Das7y ago
Nice Article.